What is the role of falcor in a microservice architecture?

Question

Say we have following taxi-hailing application that is composed of loosely coupled microservices:

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

Each services has its own rest api and all services are combined in a single api gateway. The client does not talk to a single service but to the gateway. The gateway requests information from several services and combines them to a single response. For the client it looks like it is talking to a monolithic application.

I am trying to understand: where could we incorporate falcor into this application?

One Model Everywhere from http://netflix.github.io/falcor/

Falcor lets you represent all your remote data sources as a single domain model via a virtual JSON graph. You code the same way no matter where the data is, whether in memory on the client or over the network on the server.

In this taxi-hailing application each microservice represents a single domain model already. Can you think of any benefit we could thrive by wrapping each microservice with falcor? I cannot.

However I think it is very convenient to incorporate falcor into the api gateway because we can abstract away the different domain models created by the microservices into one single or at least a few models.

What is your opinion?

Answer 1

You are right. This is how Netflix uses Falcor and what the Falcor router is designed for.

From the documentation:

The Router is appropriate as an abstraction over a service layer or REST API. Using a Router over these types of APIs provides just enough flexibility to avoid client round-trips without introducing heavy-weight abstractions. Service-oriented architectures are common in systems that are designed for scalability. These systems typically store data in different data sources and expose them through a variety of different services. For example, Netflix uses a Router in front of its Microservice architecture.

It is rarely ideal to use a Router to directly access a single SQL Database. Applications that use a single SQL store often attempt to build one SQL Query for every server request. Routers work by splitting up requests for different sections of the JSON Graph into separate handlers and sending individual requests to services to retrieve the requested data. As a consequence, individual Router handlers rarely have sufficient context to produce a single optimized SQL query. We are currently exploring different options for supporting this type of data access pattern with Falcor in future.

Answer 2

Falcor is really a great api if it is used in the correct way for very relevant use cases, like :

• If your page has to make multiple REST end point calls
• These calls don't depend on each other
• All the REST calls happens on initial page load
• Performance : If you want to cache the REST responses (for example, the microservice uses gemfire caching, you may not need falcor cache. You could still use falcor caching if you want to reduce the network latency)
• Server requests batching : When running Falcor in node environment, you may want to cut down the amount of calls to node server from the client side.
• Easier response parsing : If you don't want the client code to worry about extracting the data-points from REST response (Including error handling) and so on ..

However, there are plenty of situations where falcor does not serve the purpose as much and feel that it is better off calling the end point directly :

• If REST calls are dependent on one another
• If you want to pass lot of parameters for calling the end point
• If you don't intend to cache the response(s)
• If you want to share some secure cookies (ex:XSRF tokens) with the REST web service