What is the role of falcor in microservice architecture?

Question

Let's say we have a taxing application consisting of loosely coupled microservices:

An example is taken from https://www.nginx.com/blog/introduction-to-microservices/

Each service has its own a priori, and all services are combined into one Api-gateway. The client does not talk with one service, but with a gateway. The gateway requests information from several services and combines them with a single response. For the client, it is like talking to a monolithic application.

I am trying to understand: where could we include falcor in this application?

One model everywhere from http://netflix.imtqy.com/falcor/

Falcor allows you to represent all your remote data sources as a single domain model through a virtual JSON graph. You also encode where the data is located, whether in memory on the client or over the network on the server.

In this taxi application, each microservice is a single domain model. Can you come up with any benefit that we could succeed by packaging every microservice with falcor? I cant.

However, I find it very convenient to include falcor in the api gateway, because we can abstract the various domain models created by microservices into one or at least several models.

What is your opinion?

Answer 1

You're right. This is how Netflix uses Falcor and what the Falcor router is for.

From the documentation :

A router is suitable as an abstraction on top of a service layer or REST API. Using a router over these types of APIs provides enough flexibility to avoid cross-client travel without introducing heavy abstractions. Service-oriented architectures are common in systems designed for scalability. These systems usually store data in different data sources and expose them through various services. For example, Netflix uses Router in front of its Microservice architecture.

It is rarely ideal to use a router for direct access to a single SQL database. Applications that use the same SQL repository often try to create one SQL query for each server request. Routers work by breaking requests into different sections of the JSON diagram into separate handlers and sending separate requests to services to receive the requested data . As a result, individual router handlers rarely have enough context to create a single optimized SQL query. We are currently exploring various options for supporting this type of data access pattern with Falcor in the future.

Answer 2

Falcor is really a great api if used correctly for very relevant use cases, for example:

• If your page needs to make multiple REST endpoint calls
• These challenges are independent of each other.
• All REST calls occur when the start page loads.
• Performance. If you want to cache REST responses (for example, the microservice uses gemfire caching, you may not need the falcor cache. You can still use falcor caching if you want to reduce network latency).
• Server-side package loading: when running Falcor in a node environment, you can reduce the number of calls to the node server from the client side.
• Simple answer analysis: if you do not want the client code to worry about extracting data points from the REST response (including error handling), etc.

However, there are many situations where falcor does not meet the goal and feels that it is better not to directly contact the endpoint:

• If REST calls are interdependent
• If you want to pass a lot of parameters to call the endpoint
• If you are not going to cache the answer (s)
• If you want to share some secure cookies (for example: XSRF tokens) with the REST web service