Бегун заканчивает тренировку в туннеле. Телефон теряет соединение, время загрузки истекает, и приложение повторяет попытку позже. Между тем, вчерашнее количество шагов меняется, потому что носимое устройство наконец-то синхронизируется. Это нормальные условия для...
Бегун заканчивает тренировку в туннеле. Телефон теряет соединение, время загрузки истекает, и приложение повторяет попытку позже. Между тем, вчерашнее количество шагов меняется, потому что носимое устройство наконец-то синхронизируется.
Это нормальные условия для фитнес-приложения. Его архитектура должна сохранять тренировки, предотвращать дублирование записей и обновлять прогресс, не требуя от пользователей устранения неполадок в системе.
Надежная архитектура фитнес-приложений отделяет непосредственное взаимодействие с устройством от синхронизации сервера и асинхронной обработки. Отслеживание в реальном времени требует гибкого местного поведения. Отчеты о ходе работы требуют долгосрочных записей. Фоновые задания требуют безопасных повторных попыток.
В этом руководстве объясняется, как связать эти обязанности между мобильным клиентом, API, фоновыми работниками и базой данных.
Обзор архитектуры фитнес-приложения
Для MVP начните с модульного бэкэнда, PostgreSQL, устойчивых фоновых заданий и мобильного клиента с локальным постоянством.
Четко разделяйте модули для идентификации, тренировок, импорта данных о состоянии здоровья, отчетности и уведомлений. Внедряйте независимые сервисы, когда их оправдывают требования масштабирования или развертывания.
Как данные перемещаются через систему
Этап
Поток данных
Ответственность
Захват
Датчики