[Python Intermediate] Урок 1. Конфигурация приложения
Алоха!
Задуманная мною серия статей-уроков будет полезна прежде всего тем, кто уже знает основы Python, но находится в начале пути и не может структурировать обрывки знаний. Если ты уже отучился на одном из бесчисленных курсов или близок к его завершению, то это для тебя! Автору знакомы твои сомнения и терзания, поскольку ему довелось побывать по обе стороны баррикад — и в качестве студента такого курса, и в качестве преподавателя много лет спустя.
Впервые устроившись на работу python-разработчиком, я вдруг обнаружил, что совершенно не понимаю, как мне подступиться к кодовой базе, которую необходимо было дорабатывать и поддерживать. «Как оно вообще запускается?» — атаковал меня панический вопрос. Знания, полученные на онлайн-курсе, оказались, к сожалению, почти бесполезны. По крайней мере, на начальном этапе. Именно поэтому в рамках первой статьи предлагаю поговорить о двух вещах: распространённой ныне бизнес-задаче и конфигурации приложения.
Описание задачи
Представим проблему, с которой современному разработчику приходится сталкиваться всё чаще. Пусть имеется некая старинная система, которая перестала устраивать владельца, из-за чего тот решает нанять или самостоятельно собрать IT-команду для создания более совершенного продукта. С заделом на будущее, разумеется.
Задача — объёмная, с кучей неизвестных, но выполнимая. Обычно при подобной постановке вопроса новая команда первым делом встраивается в существующую бизнес-логику и начинает потихоньку подменять её, постепенно вытесняя легаси. Есть такая набившая оскомину истина, что слона нужно есть по кусочкам. Это очень меткое и мудрое высказывание, однако в нашей профессии всегда следует помнить, что слон во время поедания чаще всего оборачивается китом и постепенно эволюционирует в Моби Дика.
Для простоты понимания возьмём типичное веб-приложение и на его примере разберём нашу ситуацию. При этом в целях всё того же упрощения договоримся сразу: в рамках данной иллюстрации фронтенд мы будем рассматривать как нечто неизменное. Мы бэкендеры, а значит — не хотим лишний раз трогать фронтенд, чтобы не заразиться любовью к фуфловым задачам.
Итак, поехали!
Так выглядит система изначально
Как система работает сейчас:
Фронтенд (или приложение на смартфоне) передаёт запрос на бэкенд.
Бэкенд работает с хранилищем: сохраняет или забирает данные.
Бэкенд возвращает ответ о результате операции фронтенду (или приложению на смартфоне).
Допустим, в инфраструктуре гипотетического сервиса в качестве хранилища данных используется реляционная СУБД MySQL. В новой версии мы, конечно же, захотим переехать на более прогрессивную и удобную PostgreSQL. К тому же пожелания заказчика и его планы на будущее вынуждают нас это сделать. Но помимо самого переезда, нам следует ещё заложить фундамент для грядущих изменений, то есть оптимизировать структуру хранения данных или, если совсем грубо, переработать таблицы, с которыми предстоит взаимодействовать.
Соответственно, просто подменить одну БД другой мы не сможем, так как старое приложение попросту не умеет работать с новым форматом.
Подменить одну БД другой не получится из-за разницы в форматах и структуре хранения данных
Хочешь не хочешь, а придётся безотлагательно испекать свеженький бэкенд. Только остаётся вопрос: каким образом мы будем сообщать ему о добавлении, изменении или удалении данных в MySQL, ничего при этом не поломав в текущей схеме? Один бэкенд другим вот так сразу не заменишь, значит, сколько-то им придётся работать параллельно, пока дряхлый слон, наконец, не окажется полностью съеденным.
Параллельное существование двух бэкендов: старого и нового
Решение такой распространённой проблемы заключается в организации связи между двумя приложениями посредством оповещений. Пусть старый бэкенд отправляет сообщение с информацией о событии всякий раз, когда с фронтенда поступает запрос, подразумевающий мутацию данных. А новый бэкенд будет обрабатывать их и запускать нужную операцию. То есть в легаси нам потребуются минимальные правки типа: «Когда поступит запрос, отправь объект оговорённого формата в RabbitMQ (он же «кролик»), а потом работай как работал».
RabbitMQ — программный брокер сообщений на основе стандарта AMQP; связующее программное обеспечение, ориентированное на обработку сообщений (Википедия).
Добавляем промежуточное звено между бэкендами — брокер сообщений
Для решения подобной задачи совсем необязательно использовать RabbitMQ, на рынке имеются аналоги. Однако вероятность того, что при таком сценарии вы повстречаете именно кролика, очень высока, поэтому рекомендую с ним познакомиться, если ещё не.
Надеюсь, с постановкой всё более-менее ясно. Если что, не стесняйся задавать вопросы в комментариях. После прочтения статьи, разумеется.
