Лучшая практика для синхронизации нескольких избыточных магазинов - PullRequest
0 голосов
/ 18 ноября 2018

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

некоторые приложениямы используем одни и те же данные, мы хотели бы уменьшить количество дублирующихся данных, извлекаемых с сервера.

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

Какой и как должен быть наилучший способ синхронизации данных между магазинами?

Несколько баллов:

  • Все данные были получены из нашегоbackend services
  • Структура данных одинакова, но не все приложения используют одни и те же данные, некоторые используют подмножество данных
  • Inorder, чтобы уменьшить дублирование вызовов API, нам бы хотелось, чтобы этот «маленький»магазины "смогут синхронизировать данные из" основного "магазина

1 Ответ

0 голосов
/ 18 ноября 2018

Как заметил @estus

Структура данных одинакова, но не все приложения используют одни и те же данные, некоторые используют подмножество данных - да, это похоже на хороший вариант использования для одного магазина .

... но для меня это идеальный случай для graphQL / Apollo .

Вы можете переместить / делегировать выборку данных (или даже все локальное состояние приложения) одному «движку», и он будет работать одинаково для всех частей приложения (одна и та же конечная точка API).

Есть много хороших вещей с этим подходом:

  • отделение данных от состояния приложения (-ов);
  • кэширование и пакетирование запросов (не только удаление дубликатов, но и «склеивание» множества запросов в одном);
  • политики кэширования (только сеть, только кеш);
  • API сшивание (будущие расширения, упаковка внешних служб) ...

Есть хороший стартер для Apollo (содержит избыточные части).

PS. Apollo может работать с REST API

...