Создание функциональности веб-приложения за Api

Question

Я должен подготовить спецификацию, чтобы предоставить дорожную карту разработчикам для создания собственного проекта.Проект будет состоять из веб-приложения и мобильного приложения.Мобильное приложение будет использоваться для сбора отзывов пользователей. Обычно мобильное приложение должно отображать пару вопросов, на которые пользователь должен ответить.

Примеры вопросов приведены ниже;

1. Использовали ли вы средство для чистки обуви для чистки обуви?
2. Вы смотрели новости ночью?

Собранные данные будут отправлены на сервер sql.

Веб-приложение должно использоваться для публикации вопросов в мобильном приложении, веб-приложение также должно использоваться для просмотра отчетов.Веб-приложение должно иметь следующие функции;1. Опубликуйте опросы в мобильном приложении, это можно сделать с помощью MQTT, AMQP или аналогичного протокола.2. Просмотр данных в форме диаграммы. 3. Управление устройствами, такими как регистрация новых мобильных устройств и т. Д.

Что необходимо Этот проект будет сплит и назначен на 3 команды, команду бэкэнда (команда Api), команду frontEnd иКоманда мобильных разработчиков.Предполагается, что функциональные возможности бэкэнда входят в Api, внешний интерфейс всегда должен обращаться к бэкэнду для получения данных, в основном, бизнес-логике не разрешается входить в интерфейсную часть.Внешний интерфейс будет писать только css / html / js для разметки и презентации, остальные функциональные возможности должны использоваться через API.

Мне нужно написать подробную спецификацию того, как проект должен быть реализован,Бэкэнд будет реализован на PHP с симфонией.Внешний интерфейс может быть любым фреймворком JavaScript, мобильное приложение будет реализовано в Android.

Можете ли вы, как я должен моделировать бэкэнд (Api), чтобы он содержал все функциональные возможности, необходимые в Интернетеприложение?Кроме того, создание функциональности поверх API - хорошая стратегия для этого проекта?Должен ли я идти монолитным путем, соединяя вместе передний и внутренний интерфейсы (это затруднит работу одного разработчика на внешнем интерфейсе, а другого - на внутреннем / api)?

Answer 1

Это идеальное приложение для серверной части CQRS, питаемой очередью.В CQRS сторона записи и сторона чтения серверной части разделены на отдельные API, что особенно выгодно при разделении проекта между несколькими командами.

Основная идея CQRS заключается в том, что существует один API для создания любогоизменения в данных, и изменения вносятся в данные с помощью команды, а затем сохраняются в нормализованной базе данных командой.Существуют также физические таблицы, специально разработанные для хранения всех данных, необходимых для одного представления (эти таблицы денормализованы).Каждый раз, когда данные записываются в агрегат, соответствующие модели просмотра также обновляются.Это приводит к структуре, в которой сторона записи является сложной, но имеет всю бизнес-логику и правила, тогда как сторона чтения очень проста и в основном просто выполняет запрос «select *» из соответствующей таблицы модели представления.Пока модель чтения (также называемая проекцией) поддерживается в актуальном состоянии, операции чтения выполняются намного быстрее, и поскольку большая часть доступа к БД читается, весь сайт работает быстрее.

В вашем случае я бы создал 3 API - один для модели чтения для мобильного интерфейса, один для модели чтения для веб-интерфейса и один для командной стороны.Таким образом, мобильные ребята могут гибко строить то, что им нужно, и они могут изменять дизайн таблицы считываемой модели по мере необходимости во время разработки, чтобы удовлетворить требования.Веб-ребята могут сделать то же самое, и команда Backend реализует сложные вещи - команды, бизнес-правила, нормализованные структуры таблиц и т. Д. Объединение трех проектов повлечет за собой создание одной из команд запросов для обновления таблиц модели представления изтаблицы сущностей.

Все это становится еще проще, если вы вводите архитектуру связи на основе событий, то есть архитектуру, управляемую событиями.Это еще больше разъединит 3 различные проблемы и сделает их еще легче объединить позже, так как каждый микросервис будет подписываться на соответствующие сообщения для получения обновлений и новой информации кеша.