Всем известно, что мобильные приложения люди используют больше и чаще, чем веб-приложения. Они заранее адаптированы дизайном под мобильные устройства (что логично) и заведомо предоставят весь нужный функционал.

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

*Данная статья является обзором пути длиной 4 месяца - не рекламой продукта. Наше приложение нельзя нигде скачать, оно не приносит дохода. Цель данной статьи: описать весь процесс разработки и работы в команде, в комментариях получить советы, рекомендации более опытных разработчиков. Все упоминания хостингов не являются рекламой, я рассказываю про свой опыт, в том числе, учитывая используемые сервисы. Это учебный проект, его цель - научиться новому. Мне как тимлиду и бэкендеру, сокомандникам своим сферам.

**Здесь не будет везде примеров кода и примеров реализации конкретных вещей. Я описываю процесс создания приложения, а не один из этапов - кодинг.

Концепция

У нас как у людей нетворческих было не очень много идей. Собственно, идея - и была самая сложная часть поначалу. Попросили помочь искусственный интеллект: он выдал ряд предложений. Одним из них и было то, что мы взяли на вооружение и с чем имели дело 4 месяца - приложение с рецептами.

Но таких десятки. Я сел за техническое задание, в процессе написания которого мы командой придумывали, какая же киллерфича должна быть. Мы решили встроить ИИ, который бы генерировал интересные рецепты* (*за возможные последствия приготовления сгенерированных рецептов не ручаемся).

Параллельно с написанием техзадания, после того, как были продуманы функциональные требования, наша дизайнер сделала в Figma вид результата работы. Я, ни разу ранее не пользовавшись Adobe Illustrator, открыл его и по какой-то обучалке сделал простое лого. Его добавили в дизайн в Фигме и мы получили внешний вид того, к чему мы должны прийти в течение следующих 3 месяцев труда.

*Ремарка: в процессе придумывания названия для приложения мы остановились на вариантах "Вкуснолаб" и "Вкусолаб". Так как отличие лишь в одну букву, а репозитории уже были созданы, название может быть где-то одним, где-то другим.

В техзадании прописывается также и стек технологий. Нами был Flutter ради кроссплатформенности (спойлер на будущее: она не была использована, я не успел сделать порт на iOS) и Python Django на бэкенде. Конечно, приложение не приложение без серверной части. Иначе как юзерам смотреть рецепты не только свои сохранённые локально, но и рецепты других пользователей?

Немного про архитектуру приложения

Коротко архитектуру приложения можно обрисовать схемой.

Есть часть, которую я назвал основной, Main, - собственно, мобильное приложение и backend с базой данных, которые обмениваются данными. По запросу мобильного приложения бэкенд отсылает картинки на отдельно стоящий сервер S3, записывая в базу данных путь к файлу. Сам сервер S3 публичный, там не хранится критически важная информация пользователей, поэтому мобильное приложение может без авторизации получать доступ к картинкам на S3 по публичным ссылкам.

В Elasticsearch записываются только логи через Filebeat и Logstash. Тут всё просто. На самом деле для таких целей можно было найти сильно более легковесный сервис для красивого просмотра логов, но я захотел и решил поэкспериментировать с Эластиком на отдельном сервере и с отправкой логов с Nginx'а в него.

Разработка

При наличии готового дизайна фронтендеры приступили к созданию приложения. Необходимо было перенести дизайн из Фигмы по Флаттер, временно без логики нажатия на кнопки.

Моя коллега, бэкендер, нарисовала схему базы данных. У нас не было цели строить сначала концептуальную модель, затем логическую и от неё физическую, она нарисовала условную схему базы данных (её сложно назвать UML-диаграммой).

Мы приступили к написанию самого бэкенда. Для этого выбрали django rest framework, который позволяет нам быстро писать эндпоинты целыми пачками. В процессе возникали сложности, например, связанные с тем, что моя коллега использовала ИИ DeepSeek при выполнении задач, но во-первых, сама не вникла в суть задачи, из-за чего в коде были логические ошибки, во-вторых, неправильно формулировала задачу ИИ, - эта проблема вытекает из пункта 1. В итоге часть "мусорной", "неправильной" логики отсеялась во время моего ревью, а часть из того, что я посчитал нормальным, но таковым не являлось, проникло в master ветку и оттуда на сервер.

Я добавил в приложение на бэкенд с помощью библиотеки yasg визуальный красивый swagger, чтобы можно было сразу тестировать написанные эндпоинты.

По сути, этот UI-swagger - основной способ коммуникации с фронтендерами. Я описывал им эндпоинты отдельно в нашем чате, при необходимости, но тестировать они всегда могли тут. Буквально один раз я выгрузил .json и .yaml форматы сваггера, но из-за недостаточной опытности коллег читать описание API в таком формате было сложно, да и ко всему прочему, как я уже писал, в web-ui можно сразу тестировать эндпоинты, а не только видеть их описание.

Нашей киллерфичей я уже называл встроенный AI - его интеграция оказалось простой задачей. Я просто подключил AI от Сбера, и он генерировал ответ на запрос пользователя учитывая "техническую инструкцию" - всегда генерировать только рецепты. Ниже реализация этого в коде и итоговый результат генерации:

messages = [
  SystemMessage(
    content="Ты бот, который придумывает рецепты. На любой запрос придумай рецепт"
  ),
  HumanMessage(
    content=serializer.data["text"]
  )
]

response = self.ai_client.invoke(messages)

DevOps

На определённом этапе разработки я понял, что пора кидать бэкенд на сервер. Я арендовал VPS на Aeza. Настроил nginx на нём. Захотел настроить CI/CD. Посмотрел-почитал про Ansible, настроил его в GH Workflow. В процессе разработки были добавлены тесты в бэкенде - CI/CD настраивал с учётом их. При пуше в master ветку вызывается workflow, который сначала прогоняет все тесты, а потом по SSH отправляет файлы на сервер, делает миграции и перезапускает gunicorn.

В качестве СУБД я выбрал MySQL.

Следующим шагом является настройка S3. Я арендовал его на Timeweb, настроил в Django. Теперь картинки отправляются из бэкенда в облачное S3 хранилище, в базу данных сохраняется ссылка, которую получает фронтенд и фронтенд подгружает картинку напрямую из S3.

Elasticsearch

Небольшое ответвление в разделе девопса. Elasticsearch я решил использовать для сбора логов с nginx. Чтобы поднять Эластик, я арендовал отдельный для этого сервер на Timeweb, нашел репозиторий на GitHub с настроенным стеком ELK: "Elasticsearch, logstash, kibana". Донастроил пользователей под себя - и Kibana запустилась.

Необходимо было настроить конфигурацию nginx на сервере с бэкендом и формат получаемых логов в самом Elasticsearch (logstash pipeline):

input {
  beats {
    port => 5044
  }
  tcp {
    port => 50000
  }
}

filter {
  grok {
    match => { "message" => '"%{WORD:method} %{URIPATH:request} HTTP/%{NUMBER:http_version}" %{NUMBER:status} %{NUMBER:bytes_sent} "%{DATA:referrer}" "%{DATA:user_agent}"' }
  }
  mutate {
    convert => {
      "status" => "integer"
      "bytes_sent" => "integer"
    }
    remove_field => ["message"]
  }
}

output {
  elasticsearch {
    hosts => "elasticsearch:9200"
    user => "logstash_internal"
    password => "${LOGSTASH_INTERNAL_PASSWORD}"
    index => "weblogs-%{+YYYY.MM.dd}"
  }
}

После применения этих настроек логи пошли в систему:

Далее для большего интереса и большей наглядности я настроил один дэшборд:

Я понимаю, что для моей цели: получение и анализ логов, их нормализация - можно было взять другой инструмент, сильно более легковесный (например, VictoriaLogs или Loki, как мне подсказали во время редакции статьи).

Но я решил посмотреть Эластик, как с ним работать в Kibana, как настроить получение логов в нём с удалённого сервера из Nginx. Данный пункт основан исключительно на моём интересе и не требуется в проекте (по крайней мере, в такой реализации).

Результат

Приближался конец семестра, наша работа подходила к концу. Оставались мелкие правки, немного дополнений и работа была успешно сдана. В самом конце вскрылась небольшая проблема - кэширование. Django почему-то решил полностью кэшировать все запросы, из-за чего после создания, например, нового элемента в корзине, он там появлялся только спустя время, если исполнять запрос на одном клиенте. Как только я полностью выключил всё кэширование на стороне Django - всё заработало как надо.

Как итог мы получили работающее приложение: с возможностью выкладывать рецепты, добавлять ингредиенты в корзину, с AI, который сгенерирует рецепты, с профилями пользователей.

Спасибо за работу бэкендеру Евгении, дизайнеру-фронтендеру Алисе и фронтендеру Вячеславу. Я получил кайф от данного проекта. И спасибо за прочтение, уважаемый читатель!