REST API, отслеживание изменений в нескольких ресурсах, внешняя синхронизация

Question

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

Back-end поддерживает все ресурсы и отношения между ними, это очевидно. И front-end извлекает эти ресурсы и сохраняет их локально, чтобы сделать интерфейс более чувствительным для пользователя и избежать сбора данных по каждому запросу. И это потрясающе.

На стороне сервера есть много операций, которые затрагивают сразу несколько ресурсов. Это означает, что добавление/удаление/редактирование одного ресурса (через REST api) может изменять множество других ресурсов.

Я хочу, чтобы данные приложения front-end всегда были полностью синхронизированы с исходными данными. Это позволяет мне сохранять целостность данных и не допускать ошибок в моем приложении. Любой вид десинхронизации - это большой «нет», он вводит сотни мест, где неопределенное поведение может происходить в моем внешнем приложении.

Вопрос в том, что это лучший способ достичь этого? Мои идеи/идеи:

1. Бизнес-логика (модифицирующие/редактирование/удаление ресурсов, управление отношения, сохранение целостности данных) должны быть выполнены только один раз. Удвоение бизнес-логики (одна в интерфейсе и одна в фоновом режиме) приводит к множеству потенциальных ошибок и предполагает дублирование кода, что, очевидно, плохо. Если бы бизнес-логика была реализована в интерфейсе, back-end все равно пришлось бы проверять данные и сохранять целостность - дублирование бизнес-логики. Таким образом, бизнес-логика ДОЛЖНА быть в фоновом режиме.

2. Я использую API REST. Когда мой front-end обновляет один ресурс (или много ресурсов по методу PATCH), на стороне сервера возникает множество побочных эффектов, другие ресурсы также модифицируются. Я хочу, чтобы мое внешнее угловое приложение узнало, какие ресурсы были изменены и обновлены (чтобы сохранить полную синхронизацию). REST возвращает только тот ресурс, который изначально запрашивался для обновления, без других уязвимых ресурсов.

Я знаю, что я мог бы использовать некоторую форму связывания ресурсов и отправлять исходный обновленный ресурс со ссылками на другие затронутые ресурсы. Но что, если их 100? Выполнение 100 запросов на сервер - это полное снижение производительности.

3. Я не очень привязан к REST, потому что мой API не является общедоступным, это может быть что угодно. Я думаю, что лучшим решением будет обратная отправка всех измененных ресурсов. Это позволит моему интерфейсу всегда синхронизировать с бэкэнд, будет быстрым и будет атомарным (недействительное промежуточное состояние между несколькими запросами на сервер). Я думаю, что эта архитектура была бы потрясающей. Вопрос в том, является ли это общим подходом? Существуют ли какие-либо протоколы/стандарты/библиотеки, позволяющие мне это делать? Мы могли бы написать это с нуля, но мы не хотим изобретать велосипед.

4. На самом деле, я считаю, что наличие бизнес-логики в интерфейсе и в обратном направлении было бы хорошим, но ТОЛЬКО, если бы оно было реализовано один раз. Это означает, что приложение Javascript работает в фоновом режиме. К сожалению, в настоящее время это невозможно для меня.

Любое понимание будет приветствоваться!

Добавлен позвоночник.js tag, потому что вопрос гораздо больше касается архитектуры, чем любой конкретной технологии.

Answer 1

Вы на правильном пути, и это общая проблема, с которой вы сталкиваетесь прямо сейчас. Как вы сказали, в мире REST ваш API возвращает запрашиваемый/измененный ресурс. Простой пример вашей проблемы:

Вы - как пользователь X - хотите следовать за другим пользователем Y. На передней панели отображается ваш собственный счетчик (X) и счетчик следящего устройства другого пользователя (Y). Http-вызов будет примерно таким:

PUT /users/X/subscribe/Y 

API будет возвращать ресурс пользователя Y, но X отсутствует, или наоборот.

Чтобы справиться с этим дела, которые я использую расширенную структуру моей стандартной структуры ответа API, моя стандартная структура:

• мета объект - включает в себя код состояния HTTP и объяснение, почему привык этот код, который приложение сервер обрабатывал ответ и больше объект
• уведомления - включает в себя информацию об ошибках во время обработки (если таковые имеются), специальные сообщения для разработчиков и более

• ресурс - ресурс, который получил запрошенную/модифицированную, имя этого атрибута является тип ресурса в единственном числе для singl e ресурсов (например, пользователя) или во множественном числе для коллекций ресурсов (например, пользователи)

  { мета: { статус: 200, сообщение: 'OK', Appserver: app3 }, уведомление: { ошибок: [] }, пользователь: { ID: 3123212, абонентов: 123, подписок: 3234 }}

Для того, т o вернуть также другие затронутые ресурсы и сохранить способ REST + мою статическую стандартную структуру ответа. Я присоединяю еще один объект к ответу под названием «affectedResources», который является массивом всех других затронутых ресурсов. В этом очень простом примере массив будет включать только объект ресурса пользователя X. Передняя часть выполняет итерацию массива и позаботится обо всех необходимых изменениях.