TechBinaries

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

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

  As part of API development, there are a lot of patterns or architecture that will be available. We can't stick with one pattern as part of large distributed application development. An application can be developed with multiple patterns based on the use cases as well as application performance also. I have created multiple services with multiple architectures or patterns based on the multiple-use case in order to achieve the best results. I have started creating the microservices for my application. Because my application involves multiple entities. Each entity playing a major role in the corresponding services. Based on my need I can scale, extend, and migrate the corresponding service. I have created multiple services. I need to provide my services to the consumers. Here my consumers are web applications and native applications.   Apigateway : All the consumers need to consume the services via endpoints or URL. As part of services development, we can add or update a number...

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