В этой статье мы рассмотрим все тонкости создания Proof of Concept (PoC) мобильного приложения, построенного с помощью фреймворка SwiftUI и бэкенда с использованием FastAPI. Дополнительно я продемонстрирую эффективные архитектурные паттерны для SwiftUI-приложений, в частности MVVMP в сочетании с принципами SOLID и Dependency Injection (DI). Для android код можно легко перевести на Kotlin с помощью Jetpack Compose Framework.
Зачем нам нужен бэкенд
Кто-то может сказать, что можно просто запихнуть всю логику в приложение, напрямую отправлять запросы в chatgpt и сделать приложение без бэкенда. И я согласен, это действительно возможно, но бэкенд дает несколько важных преимуществ.
Бэкенд служит основой для любого сложного приложения, особенно для тех, которые требуют безопасного управления данными, обработки бизнес-логики и интеграции сервисов. Вот почему надежный бэкэнд имеет решающее значение:
- Безопасность: Бэкэнд помогает защитить конфиденциальные данные и токены аутентификации пользователей от атак типа MITM (Man-in-the-Middle). Он выступает в качестве защищенного шлюза между пользовательским устройством и базой данных или внешними службами, обеспечивая шифрование и аутентификацию всех данных.
- Контроль над использованием сервисов: Управляя API и взаимодействием с пользователями через бэкэнд, вы можете отслеживать и контролировать использование приложения. Это включает в себя дросселирование для управления нагрузкой, предотвращение злоупотреблений и обеспечение эффективного использования ресурсов.
- Интеграция с базой данных: Бэкэнд обеспечивает бесшовную интеграцию с базами данных, позволяя динамически хранить, извлекать и обновлять данные в режиме реального времени. Это важно для приложений, которые требуют учетных записей пользователей, хранят их предпочтения или нуждаются в быстром и безопасном получении больших объемов данных.
- Модели подписки и Freemium: Реализация услуг по подписке или модели freemium требует наличия бэкенда для выставления счетов, отслеживания использования и управления уровнями пользователей. Бэкэнд может безопасно обрабатывать платежи и подписки, обеспечивая бесперебойную работу пользователей и соблюдая требования по защите данных.
- Масштабируемость и обслуживание: Бэкэнд позволяет более эффективно масштабировать приложение. Логику на стороне сервера можно обновлять без необходимости передавать обновления клиенту, что упрощает обслуживание и ускоряет внедрение новых функций.
По сути, бэкенд — это не только функциональность, но и создание безопасной, масштабируемой и устойчивой среды для процветания вашего приложения.
Объяснение технического стека
- SwiftUI: Лучший вариант для нативных приложений для iOS после выхода UIKit. Он декларативен и упорядочен, а XCode является незаменимым редактором благодаря эпл. Для android код можно легко перевести на Kotlin с помощью Jetpack Compose.
- FastAPI: Выбран для бэкенда за его скорость, минимальное количество шаблонов и декларативность, редактируется с помощью превосходного Zed.dev.
- ChatGPT API: Используется в качестве большой языковой модели (LLM); выбор может меняться в зависимости от необходимости кастомизации.
- Ngrok: Реализует туннелирование с помощью простой команды CLI для выхода локального сервера в интернет.
Создание приложения для iOS
Теория: Архитектурные паттерны
1. MVVMP (Model View ViewModel Presenter):
- Model: Представляет собой структуры данных, используемые в приложении, такие как Question, Answer, Questionary и FilledQuestionary. Эти модели просты и содержат только данные, следуя принципу KISS.
- View: Отвечают только за представление пользовательского интерфейса и делегируют все данные и логику презентерам. Они не содержат никакой бизнес-логики и спроектированы так, чтобы быть простыми и сосредоточенными на рендере UI.
- ViewModel: В SwiftUI ViewModel представлена объектом ObservableObject, который служит моделью наблюдения за изменяемыми данными. Здесь нет методов и логики.
- Presenter: Presenter управляет всей логикой, связанной с модулем (экраном или представлением), но не бизнес-логикой. Он взаимодействует с доменным слоем для выполнения операций бизнес-логики, таких как взаимодействие с API или управление сохранением данных.
- Domain Layer: Этот слой содержит бизнес-логику приложения и взаимодействует с внешними ресурсами, такими как базы данных, API или другие сервисы. Он состоит из нескольких компонентов, таких как сервисы, провайдеры, менеджеры, репозитории, мапперы, фабрики и т. д.
- На самом деле, MP в MVVMP является инициалами Марка Паркера, а полная форма — «Model View ViewModel by Mark Parker».
2. Принципы SOLID:
- Принцип единой ответственности: У каждого класса должна быть только одна причина для изменений.
- Принцип открытость-закрытость: Компоненты должны быть открыты для расширения, но закрыты для модификации.
- Принцип замещения Лискова: Объекты суперкласса должны быть заменяемы объектами подклассов.
- Принцип разделения интерфейсов: Ни один клиент не должен быть вынужден зависеть от интерфейсов, которые он не использует.
- Принцип инверсии зависимостей: Зависимость от абстракций, а не от конкретики, чему способствует DI.
3. Инъекция зависимостей (DI):
- При использовании паттерна Dependency Injection зависимости предоставляются извне класса, а не инстанцируются внутри него. Это способствует развязке и позволяет упростить поддержку и тестирование кода.
Разработка бэкенда
Код бэкенда довольно прост. Эндпоинты (main.py):
"onboarding" предоставляет список вопросов анамнеза, которые необходимо заполнить при первом запуске приложения. Ответы будут сохранены на устройстве и использованы для персонализированной диагностики в будущем. "doctor" — основной эндпоинт: он генерирует вопросы на основе предыдущих ответов и карты пользователя, либо возвращает результат диагностики.
Модели:
Промпты:
Модуль промптов использует GPT-3.5 от OpenAI для генерации ответов на основе пользовательского ввода, анамнеза и заполненных анкет. Он возвращает пользователю соответствующие вопросы и советы по диагностике здоровья. Как видите, ничего сложного здесь нет. Код элементарен, а промпты – просто набор четких инструкций для LLM.
Настройте окружение и запустите сервер с помощью fastapi dev main.py
.
Подробности:
- fastapi.tiangolo.com/tutorial/first-steps
- pypi.org/project/openai/
Открытие доступа к локальному хосту через Интернет
- Зарегистрируйтесь на сайте ngrok.com и получите токен доступа.
- Установите ngrok с сайта ngrok.com/download.
- Выполните команду
ngrok config add-authtoken <TOKEN>
. - Запустите с помощью команды
ngrok http http://localhost:8080
(при необходимости измените порт).
Подробные инструкции по настройке можно найти в документации ngrok.
Кодим приложение
Я не буду показывать здесь весь исходный код, для этого есть GitHub. Найти его можно по адресу: HouseMDAI iOS App. Вместо этого я остановлюсь только на важных (IMO) моментах.
Начнем с краткого описания задачи: нам нужно приложение с текстовым полем на главном экране, возможностью задавать набор динамических вопросов и показывать ответ. Также нам нужен одноразовый онбординг. Итак, приступим к коду.
Первым делом нам нужны модели, и они довольно просты (принцип KISS).
Теперь давайте сделаем онбординг. Продолжаем следовать KISS и SRP (Single Responsibility Principle), никакой бизнес-логики в представлениях, только UI. В данном случае – только список вопросов с прокруткой. Все данные и логика делегированы презентеру. Единственное, что здесь интересно, это небольшой вспомогательный метод bindingForQuestion
, который, вероятно, должен быть в презентере, но сейчас это не имеет значения.
Вы будете удивлены, но в презентере также нет никакой бизнес-логики!
Все по-прежнему simple, stupid и имеет только одну ответственность. Presenter должен содержать только логику своего представления. Бизнес-логика уровня приложения находится вне его юрисдикции, поэтому презентер просто делегирует ее наверх по стэку вызова.
Также можно заметить, что и View, и Presenter не инстанцируют ни одну из зависимостей, а получают их в качестве параметров при инициализации. Это соответствует принципу инверсии зависимостей, согласно которому модули высокого уровня не должны зависеть от модулей низкого уровня, но оба должны зависеть от абстракций. Это обеспечивает гибкость и упрощает тестирование, а также позволяет легко заменять зависимости или внедрять макеты для целей тестирования.
При использовании паттерна Dependency Injection зависимости предоставляются извне класса, а не инстанцируются внутри него. Это способствует развязке и позволяет упростить поддержку и тестирование кода.
Хотя в данном примере протоколы не используются явно, стоит отметить, что протоколы могут играть важную роль в коде, особенно для абстрагирования и облегчения тестирования. Определив протоколы для представлений, презентаторов и зависимостей, становится проще заменять реализации или предоставлять моки во время тестирования.
Итак, если презентер не содержит бизнес-логику, то где же она? Это задача для доменного слоя, который обычно содержит сервисы, провайдеры и менеджеры. У них всех очень схожее применение, и разница между ними до сих пор является предметом дискуссий. Давайте создадим OnboardingProvider
, который будет содержать всю бизнес-логику процесса онбординга.
Опять же, он выполняет только одну задачу: управление бизнес-логикой процесса onboarding. Такая инкапсуляция позволяет другим классам взаимодействовать с ним без необходимости беспокоиться о деталях его внутренней реализации, что способствует созданию более чистой и удобной кодовой базы.
Теперь давайте соберем все вместе в корне приложения.
Это приложение SwiftUI устанавливает свое начальное состояние с помощью оберток полей StateObject
. Оно инициализирует OnboardingProvider
, OnboardingPresenter
и HomePresenter
в своем методе init. Провайдер OnboardingProvider
отвечает за управление данными, связанными с онбордингом, а OnboardingPresenter
управляет логикой представления онбординга. HomePresenter
управляет главным домашним представлением.
В теле сцены приложения проверяется, нужна ли регистрация на сайте. Если да, то она представляет OnboardingView
с OnboardingPresenter
. В противном случае она представляет TabView
, содержащий HomeView
с HomePresenter
и, если доступно, ProfileView
.
Теперь настало время для домашнего представления. Логика проста:
- Получаем сообщение от пользователя.
- Используя сообщение, запрашиваем список вопросов из бэкенда.
- Показываем вопросы по одному, используя встроенную push-навигацию.
- Добавляем ответы к запросу и повторяем 2-4, пока бэкенд-доктор не вернет окончательный результат.
- Показываем финальный результат.
Похоже, я пропустил 4-й пункт... или нет? Поскольку представление не может содержать никакой логики, эту часть выполняет его презентер.
Он управляет вводом сообщения пользователем и обновляет путь навигации на основе ответов от бэкенда.
При отправке сообщения метод onSend()
отправляет его на бэкенд с помощью DoctorProvider
и ожидает ответа. В зависимости от типа ответа он обновляет навигационный путь, отображая либо набор вопросов, либо окончательный ответ.
Аналогично, когда заполняется вопросник, метод onQuestionaryFilled()
отправляет заполненный вопросник на бэкенд и соответствующим образом обновляет путь навигации.
Здесь есть небольшое дублирование кода между методами onSend()
и onQuestionaryFilled()
, которое можно было бы отрефакторизовать в один метод для обработки обоих случаев. Однако оставим это как упражнение для дальнейшей доработки.
Модуль Questionary (View+Presenter) почти является копией Onboarding и просто делегирует логику до HomePresenter
, поэтому я не вижу необходимости показывать код. Опять же, для этого есть github.
Последнее, что я хочу показать, это две реализации DoctorProvider
, единственной обязанностью которых является вызов API и возврат DoctorResponse
. Первая использует наш бэкенд.
Вторая вызывает openai api напрямую (подход backendless) и является практически копией модуля подсказок из бэкенда.
Другой пример
Посмотреть пример этой архитектуры в реальном приложении можно в моем проекте TwiTreads на github.com/MarkParker5/TwiTreads
Что делать дальше
- Интегрируйте аутентификацию и базу данных пользователей в бэкенд. Можете использовать официальный шаблон FastAPI из FastAPI Project Generation.
- Реализуйте логику аутентификации в приложении.
- Сосредоточьтесь на улучшении дизайна приложения, чтобы повысить удобство работы с ним. Давайте создавать красивые приложения!
Заключение
Приведенные проекты и ссылки на код служат реальными примерами, чтобы дать толчок вашей собственной разработке. Помните, что красота технологии заключается в итерациях. Начните с простого: создайте прототип и постоянно совершенствуйте его. Каждый шаг вперед приближает вас к овладению искусством разработки программного обеспечения и, возможно, к следующему большому прорыву в технологиях. Счастливого кодинга!
Автор: Марк Паркер
Телеграм-канал: t.me/parker_is_typing
Комментарии