TechBinaries

 While moving from REST to Graphql people are encounter the following issues. 1) How we can migrate the backend without any customer impacts? 2) How we can migrate all our client apps from Rest to Graphql? 3) Will Graphql will serve the business needs without any performance downgrade in real load? There are five phases that will be required to move from REST to Graphql. Graphql Federation Setup: We need to develop the graphql microservices and need to be orchestrated via graphql federated gateway. So all the graphql APIs can be consumed via a single endpoint. Graphql Conversion Layer(GQCL): It's just a data conversion and pass-through layer. It will convert the rest api request to equivalent graphql requests and it will access the graphql gateway and return the responses back to restful services. Test on Graphql: Before releasing the Graphql gateway to client apps first it needs to be consumed by internal restful APIs. Restful APIs already serve the business needs. If grap...

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 servic...

  I am seeing a lot of posts about GRAPHQL is going to replace the REST. From my experience, it might not happen. Rest replaced the SOAP because of content-type. Rest supported JSON. That is the big milestone in terms of performance using data transfer. Data transfer has been reduced a lot using JSON instead of XML. Here REST and GRAPHQL using JSON as data transfer. Both will support microservice architecture. The difference is GRAPHQL using queries as part of the post method for all type of CRUD. Protocols and Verbs: REST is using the HTTP protocol. Directly we can access from the browser. It provides HTTP verbs for a different type of CRUD operation. Graphql is also using HTTP protocol. We can access via the playground or simple post API from the postman. It provides different names like Query and Mutation of CRUD operation. Authentication & Authorization: In Microservices architecture we can keep Authentication and Authorization at the gateway level or services level, or API...