Hybrid Federated Ocelot Gateway

Ocelot: 

People who have experienced with .net core distributed microservices architecture will be very familiar with an ocelot. It's an API gateway to forward the request based on the routes. It supports the HTTP for rest services and WebSocket protocol for signalR services. It's providing a lot of features like authentication, Authorization, adding custom headers, and a lot. All are configurable. We can easily orchestrate multiple services using ocelot. It's a single point of contact to the outside world. It acts as a reverse proxy.

As part of microservices architecture, each service will have a single responsibility. Sometimes service needs some data from other services or needs to complete some action from other services as part of business workflow.

As part of distributed microservices architecture, there are many ways to enable communication between the services. 

1) Service to Service communication via HTTP or Grpc.

2) Event-Driven via pub/sub model

Service to service communication by API call or publish the message, but it will increase the microservices complexity. Because microservices are loosely coupled systems. If we make an API call or publish the message to other services, then-current service will depend on the other services. Apart from this, we can enable service to service communication in different ways also.

Wrapper Service:

1) We can create some wrapper service and move the business logic there. So wrapper will behave like logical apps. it will have series of actions. Each step will call the corresponding services. Each service will behave like a function app. Adding a wrapper again will increase application complexity.

Gateway orchestration:

2) Move the logic to the gateway specially for reading operation. Gateway will fetch information from multiple services, aggregate it and return the response. It's very simple and straight forward. we can get all the information we required from multiple services. Consider a complex approach like We need to configure some additional properties like pagination. I need some paginated data from two services. In this case, I need to add some custom logic in the gateway because the paginated input can be passed via headers or queries, or body. Gateway needs to parse the input and forward it to the corresponding service. So gateway complexity is getting increased. the gateway should be lightweight it just needs to be a reverse proxy to forward the request and aggregate the results.

We can't add business logic in the gateway. We can't add additional wrapper service also. So We need a solution to communicate to multiple services with a single request with customized inputs. Federated gateway serves this purpose.

Federated Gateway:

Apollo provided this feature as part of graphql development. Each microservices they will have their corresponding entity. If the service needs data from other services it will extend the corresponding entities. All the microservices schema(Api specs) will be merged and created a single schema and registered in the gateway.

Federated gateway creates the graph based on the schema. It will maintain the relationship based on the graph. So it will parse the request body and forward the request into the corresponding services and aggregate the results back to the client. We can pass custom input to multiple services via a gateway. Federated gateway parses the request and forwards it to corresponding services.

Federated Gateway in .Net Core:

We can implement the federated gateway concepts in .Net core using hot chocolate. Its NuGet package recently developed by ChilliCream. The NuGet package is an initial release. Using this we can achieve federated graphql development using .net core. But It needs to evolve a lot, to support the enterprise level to support distributed architecture.

Ocelot + Federated:

Ocelot provides very good routing based on the request URL. Federated provides routes based on the body. So we can add federated implementation in the ocelot gateway. The gateway will support both rest and graphql based routing. It's yet another hybrid gateway. Using this approach we can maintain all the rest and graphql services under a single umbrella. Currently, it's working in the POC with some customization. But it will require a lot of improvements to support enterprise-level applications. 

People have any ideas and suggestions please let me know about this approach.

Comments

Post a Comment

Popular posts from this blog

API Calls Evolution(Callback vs Promise vs Observables)

Application without API calls is very less in the market. At least they will send the app analytics details to the backend to improve their application feature. Making API calls is simple but it will have a lot of complexities in the implementation. As part of javascript, making API calls is a very critical part in terms of performance. We shouldn't block the thread until we receive the data. The application needs to know when the data is returned. Then its need to execute the data processing. Execute the data processing based on the API response will be simple or complex based on the business logic. Data processing parts have been improved a lot based on the developer pain-points. I have started my developments with callbacks, then promise, and now Observer. In each phase, they have addressed a lot of problems. Callback: Calling the function once a response is received. The response will be success or failure. Based on that function will get executed. This is a simple use case.
Read more

Dapper Micro ORM (Connection Management)

Image
Dapper is a micro-ORM or a Data Mapper. It internally uses ADO.NET. Additionally, Dapper maps the ADO.NET data structures to your custom POCO classes. As this is additional work Dapper does, in theory, it cannot be faster than ADO.NET. It's Prevent SQL Injection from external user input by avoiding raw-SQL query string building. Dapper provides methods to build parameterized queries as well as passing sanitized parameters to stored procedures. Dapper has provided multiple methods to Query or execute the store procedures and SQL queries. At the High level, we can split into two categories as Query and Execute. Query: Its mainly used to fetch the data from the database. It has the following feature. To query the data in sync or async way  To fetch single or multiple records. To query single or multiple result sets also. Execute: It's mainly used to manipulate data in the database. We can pass store procedures or SQL statements as input to execute them into the database. It
Read more