Блог

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

Пример взят из https://www.nginx.com/blog/introduction-to-microservices /

У каждой службы есть свой собственный rest api, и все службы объединены в один API-шлюз. Клиент взаимодействует не с одной службой, а со шлюзом. Шлюз запрашивает информацию у нескольких служб и объединяет их в единый ответ. Для клиента это выглядит так, как будто он разговаривает с монолитным приложением.

Я пытаюсь понять: где мы могли бы включить falcor в это приложение?

Одна модель везде из http://netflix.github.io/falcor /

Falcor позволяет вам представлять все ваши удаленные источники данных в виде единой модели предметной области с помощью виртуального графа JSON. Вы кодируете одинаково независимо от того, где находятся данные, в памяти на клиенте или по сети на сервере.

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

Однако я думаю, что очень удобно включить falcor в api gateway, потому что мы можем абстрагироваться от различных моделей предметной области, созданных микросервисами, в одну или, по крайней мере, несколько моделей.

Каково ваше мнение?

Вы правы. Вот как Netflix использует Falcor и для чего предназначен маршрутизатор Falcor.

Из документации:

Маршрутизатор подходит в качестве абстракции поверх сервисного уровня или REST API. Использование маршрутизатора через эти типы API обеспечивает достаточную гибкость, чтобы избежать обходов клиента без введения тяжеловесных абстракций. Сервис-ориентированные архитектуры распространены в системах, которые предназначены для масштабируемости. Эти системы обычно хранят данные в разных источниках данных и предоставляют их через множество различных сервисов. Например, Netflix использует маршрутизатор перед своей микросервисной архитектурой.

Редко бывает идеальным использовать маршрутизатор для прямого доступа к одной базе данных SQL. Приложения, использующие одно хранилище SQL, часто пытаются создать один SQL-запрос для каждого запроса сервера. Маршрутизаторы работают, разделяя запросы для разных разделов графа JSON на отдельные обработчики и отправляя отдельные запросы службам для извлечения запрошенных данных. Как следствие, отдельные обработчики маршрутизатора редко имеют достаточный контекст для создания одного оптимизированного SQL-запроса. В настоящее время мы изучаем различные варианты поддержки этого типа шаблона доступа к данным с помощью Falcor в будущем.

Falcor действительно отличный API, если он используется правильным образом для очень важных случаев использования, таких как :

• Если ваша страница должна выполнять несколько вызовов конечной точки REST
• Эти вызовы не зависят друг от друга
• Все ОСТАЛЬНЫЕ вызовы выполняются при начальной загрузке страницы
• Производительность : Если вы хотите кэшировать ответы REST (например, микросервис использует кэширование gemfire, вам может не понадобиться кэш falcor. Вы все равно можете использовать кэширование falcor, если хотите уменьшить задержку в сети)
• Пакетная обработка запросов сервера : при запуске Falcor в среде node вы можете захотеть сократить количество обращений к серверу узла со стороны клиента.
• Упрощенный синтаксический анализ ответа: если вы не хотите, чтобы клиентский код беспокоился об извлечении точек данных из ответа REST (включая обработку ошибок) и так далее..

Однако существует множество ситуаций, когда falcor не так хорошо подходит для этой цели, и вы чувствуете, что лучше напрямую вызывать конечную точку :

• Если вызовы REST зависят друг от друга
• Если вы хотите передать множество параметров для вызова конечной точки
• Если вы не собираетесь кэшировать ответы
• Если вы хотите поделиться некоторыми защищенными файлами cookie (например, токенами XSRF) с веб-сервисом REST