anetto1502

Стрим FastAPI+Docker породил бурное обсуждение, а нужен ли докер в таком небольшом проекте. Наш ответ — обязательно! В современном мире разработки docker является такой же неотъемлемой частью разработки, как и git. Есть некоторые области без докера, например, разработка GUI, операционных систем или микроконтроллеров. Но весь backend, frontend и data science без докера вообще не живут. Давайте посмотрим, какие прямые выгоды даёт докер:

1. Всегда понятно, как запустить код. Dockerfile является однозначной инструкцией по сборке проекта. Bus-factor не мешает жить.

2. Легко включать новых людей в разработку. Инструкция в ридми сводится к docker build & docker run, что понятно даже junior-разработчикам.

3. Деплой можно производить где угодно. В пару команд можно запуститься на компе разработчика, на test или prod сервере, у заказчика на ноутбуке – и везде всё будет одинаково, нужен только сам Docker.

4. Проект одинаково себя ведёт везде. Это упрощает воспроизведение проблемы и сокращает время на багфикс.

5. Нет проблем с конфликтом зависимостей-библиотек. Вы можете на одной машине запустить проекты с условным django 3 и django 4, они никак друг другу не помешают.

6. Легко поднимать зависимости-компоненты. Для любой базы данных берётся готовый докер-образ, меняется конфиг и в одну команду запускается. С выходом на docker compose можно одной командой поднимать сборную солянку из backend, frontend, базы данных, nginx и Let's Encrypt.

В небольшом городке, затерянном среди бескрайних лесов, жил программист по имени Алексей. Он был человеком скромным, но с большими амбициями. Его жизнь была посвящена коду, алгоритмам и бесконечному поиску идеальных решений. Но была одна вещь, которая занимала его мысли больше, чем любой проект, — это минусы на Пикабу.

Когда-то давно, в золотые времена, на популярной площадке Пикабу существовала система минусов. Это была магия, которая позволяла сообществу саморегулироваться, выносить справедливые вердикты и поддерживать баланс добра и зла в мире интернет-дискуссий. Алексей, тогда ещё джун-программист, обожал эту систему. Он видел в ней не просто инструмент, а философию, воплощение справедливости в цифровом мире.

Но однажды минусы исчезли. Администрация площадки решила, что плюсов достаточно, а минусы лишь создают токсичность. Алексей был в отчаянии. Он писал длинные посты, спорил в комментариях, даже пытался создать петицию, но всё было тщетно. Минусы не вернулись.

Тем временем карьера Алексея шла в гору. Он прошёл путь от джуна до миддла, затем стал сениором, а потом и техлидом. Его код работал в крупнейших компаниях мира, его решения меняли жизни миллионов людей. Он стал программистом всего мира, как он сам шутил. Но в глубине души он всегда помнил о минусах. Каждый раз, когда он сталкивался с несправедливостью в сети, он вздыхал и думал: "Если бы только минусы вернулись..."

В прошлом посте описана задача, которую мы предлагали на собеседовании для разработчиков. Сама задача взята из практики, то есть это прямо то, чем в будущем предстояло заниматься собеседуемому, разве что с упрощением предметной области. Задача была такая: спроектировать фильтрацию результатов поиска товаров с учётом ограничений.

В задачах на проектирование чего-либо интервьюера интересует не столько сам ответ, сколько ход ваших мыслей. Вы можете не дойти до правильного ответа, или дойти с подсказкой. Рассмотрим потенциальные решения задачи и покритикуем их:
💡 Давайте присылать все данные на фронт и фильтровать там.
🚫 1кк записей передавать нецелесообразно. Более того, даже хранить фильтры на фронте не выйдет, так как они динамические и определяются конкретной выборкой. В любом случае, фильтровать должен бекенд.

💡В postgres можно спроектировать схему для хранения фильтров в связке со списком товаров, к которым эти фильтры можно применять.
🚫 Здесь не стали приводить конкретики, но отметим, что при таком подходе будут проблемы с динамическим обновлением счетчиков. А ещё такое решение несёт сложную ментальную нагрузку на разработчика.

💡Сведём задачу фильтрации к фасетному поиску. Для этого каждую единицу товара мы характеризуем набором конкретных признаков.
✅ В базе данных нам нужно завести отдельную колонку, где для каждого товара явно хранить набор его признаков и их значений. Для агрегации, подсчета количества и быстрого поиска по выбранным фильтрам можно использовать мощный механизм полнотекстового поиска.