Всем привет! Это моя первая статья на Хабре и я надеюсь и рассчитываю на вашу критику, дельные замечания, внимание и апплодисменты. Сим я начинаю серию статей посвящённых тому как создавать SaaS продукты, как подбирать нишу, как его собственно программировать и отлаживать, как выводить на рынок и всё в таком духе. Поделюсь своим опытом, так сказать.
Эта статья (и несколько последующих) будет посвящена сугубо технической части вопроса. Я расскажу о своём шаблоне для разработки и тестирования MVP, который ускоряет дело. Он у меня появился потому, что я любитель экспериментов и много раз делал разные микропроекты - боты, игры, сайты, парсеры и т.п. В какой-то момент я заметил что таскаю между проектами один и тот же кусок кода, который здорово ко всему подходит и с которого начинается каждый мой новый проект.
Итак, вашему внимаю представляю МЕГА ШАБЛОН УДОБНОГО БЫСТРОГО ПРОГРАММИРОВАНИЯ.
«Чем же он так хорош?», спросите вы. И правильно сделаете что спросите! А я вам отвечу:
Во первых, друзья мои, этот шаблон значительно ускоряет время разработки. Вернее время на разработку первой стабильной версии продукта, то бишь, MVP. Здесь сразу готовая основа приложения, которую не нужно больше писать. Никогда. Всё, она есть уже, вот.
Во вторых, он сразу в докере, а это значит, что запустится на любой машине где есть докер. Больше никаких мануалов по запуску и установке! Всё что вам нужно - открыть терминал, зайти в папочку и
make up!В третьих, возможно найдутся ценители кто меня поддержит - здесь окружение и бизнес логика по разным папкам! Вы даже можете их рассовать по отдельным репозиториям, если вам угодно. Вы можете поручить работу с окружением одному человеку, а бизнес логику другому. Всё ограничено лишь вашей фантазией :-)
Стоит ещё упомянуть Makefile, который я очень люблю и структуру слоёв приложения, которая всегда одна и та же (ну или отличается совсем чуть-чуть).
Итак, давайте к сути.
Мы имеем вот такую структуру:
/ ├── app/ # Чистый код │ ├── config.py # Хелпер для работы с конфигурацией │ ├── interfaces/ # Интерфейсы приложения │ │ └── telegram/ # У меня тут часто телеграм, иногда + web │ ├── main.py # <- Точка входа │ ├── models/ # Модельки │ ├── repos/ # Репозитории для работы с БД │ ├── services/ # Сервисы бизнес логики │ ├── storage/ # Описание хранилищ данных │ ├── tests/ # Тесты конечно же │ └── worker.py # <- Точка входа для асинхронного воркера ├── env/ # Окружение │ ├── app/ # Описание контейнера для app │ ├── docker-compose.yml # Общее целостное описание │ ├── logs/ # Папочка с логами │ ├── migrations/ # Миграции │ ├── rabbitmq/ # Рэбит, иногда нужен иногда нет │ ├── redis/ # Редис, мой любимый │ ├── requirements.txt # Python-зависимости | ├── .env # Переменные окружения │ └── worker/ # Описание контейнера для воркера ├── Makefile # Главный управляющий файл └── README.md # Документашка
Всё что не относится к бизнес логике я вынес отдельно. Они реально редко нужны - один раз настроил и всё, дальше сиди пиши архитектуру и реализацию.
/app/config.py - это наш мостик к данным окружения. А вернее к .env файлу.
/app/main.py и /app/worker.py - наши точки входа, откуда начинает жизненный цикл приложение.
В целом, /app у меня построен на идее "чистой архитектуры", но об этом поговорим подробнее и хорошенько всё разберём в следующих статьях.
В /env у нас и докер, и pip-зависимости, и даже миграции! Это своего рода декорации нашей сцены продукта.
Теперь давайте немного отступим от превозношения величия сего шаблона и попробуем быть реалистами. Действительно ли всё это "хорошо"? Или есть минусы такого подхода.
Конечно минусы есть. Вот вам к примеру:
Новички скажут, что это сложно. И я с ними буду отчасти согласен. Опытные скажут, что докер - это оверхед для MVP. И с этим тоже можно согласиться.
По сравнению с простым python main.py тут надо и контейнеры сбилдить, и подождать немного, и если что перебилдить, и всякое такое.
Дебажить тоже непросто. Сейчас, на момент написания этой статьи, у меня даже нет пошагового дебагера, типо, debugpy. О том как его добавить и настроить мы, кстати, тоже поговорим в будущих статьях.
И всё в таком духе. Больше кейсов можете предложить в комментариях, буду крайне признателен.
Теперь давайте поговорим о плюсах. Таких плюсах, которые на мой взгляд перекрывают многие минусы.
Во первых, самодокументированное, уверенное в себе окружение, которое будет работать одинаково везде где существует святой дух докера. Это сильнейший поинт, я думаю.
Можно без особых усилий настроить контейнеры по разному. Например, мне часто нужно чтобы воркер был круче чем основное приложение, ведь он часто делает больше работы. Тут будет легко выделить ему свой отдельный requirements.txt и прописать в нём всё что нужно.
С первого же дня (ну или когда всё хотя бы раз нормально запустится) вы будете готовы к деплою. Это суперскорость! (кчау!) Если вы, как и я, хотите быстро получить результат, протестировать гипотезу, вывести что-то а рынок и посмотреть кому это надо - то вот вам ковровая дорожка.
Этот пункт тоже для вас, друзья, если есть мысли можете описать дополнительные плюсы в комментах.
Теперь самое важное. Как применить этот шаблон у себя.
Тут я вкратце расскажу про архитектуру самого шаблонного приложения.
Начнём с того, что мой шаблон заточен на создание телеграм ботов. Я выбрал этот путь поскольку боты нынче очень многофункциональные ребята, с толикой фантазии их можно применить почти в любой сфере жизни. Плюс поддержка mini app расширяет паттерн их использования до невообразимых пределов. Однако, я не заострял внимание на работе через телеграм ботов а оставил пространство для манёвра. Лично я использую этот каркас не только для ботов, недавно вот делал расширение для браузера с апи сервисом.
Главное - это слоистая архитектура, которая подходит для чего угодно. Давайте вкратце пройдёмся по слоям:
main.py ↓ Handler ↓ Service ↓ Repository ↓ Database
Точка входа приводит нас к хендлерам.
Хендлеры - это те крючки за которые дёргает пользователь, через них приложение узнаёт о его желании.
Когда пользователь задействовал какой-то хендлер, например, нажал в боте кнопку "Оставить отзыв" приложение передаёт управление глубже - к сервисам, где инкапсулирована бизнес логика того как пользователь получит желаемое.
Если сервису нужны какие-то данные из БД или сервису нужно сохранить данные, то упавление передаётся ещё глубже - к репозиториям.
Репозитории умеют только работать с базой данных и возвращать результат обратно.
Собственно и всё, первый и самый главный цикл таков.
Есть и другой - работа с асинхронным воркером. Однако в рамках этой статьи касаться его нет смысла. Разве что вкину схемку, а дальше думойте сами :))
Handler ↓ JobQueueService ↓ Redis
На этом я пожалуй буду закругляться. В этой статье я осветил всё что хотел. В последующих я глубже разберу все затронутые темы. Свои темы и предложения можете оставить в комментариях, я обязательно их все прочту и сделаю выводы.
Если вам понравилось, то переходите в мой DEV-блог
В нём я рассказываю по шагам как я строю свой текущий SaaS проект, разбираю с какими трудностями сталкиваюсь и как их решаю.
Ждите следующих статей и до скорых встреч на просторах интернета! Всех благ!