In terms of GRAPHQL, we need to pass the required parameter as part of the query. In REST we can have simple endpoints like devices/status. Consider IoT devices will return a lot of parameters as part of device status and configuration. We are building an application that will return the response as a big one. Then where the difference is. It will be based on your business. Anyway, both will be the same in terms of functionality only difference is how the data is getting represent to the end-user. In GRAPHQL we will have a simple POST API with different verbs like Mutation and query. It will describe what action API is going to do. In REST we can have different resource name with corresponding HTTP verbs. Either we need to wait until all the partners consume the new implementation or we need to deliver a new API as part of the API provider. If I'm going to remove one of the fields so one of my partners will have corresponding client implementation so API will be work for him, how about the rest of my partners? They will look for the fields that will be required. As an API provider, I can provide a Graphql API to multiple partners. I do not completely agree with this point. People are claiming versioning is not required as part of Graphql. Versioning will be required while removing the existing fields or updating the data type or changing the parameter from not mandatory to mandatory. No need for versioning while adding new fields. It will be the same for Rest and GRAPHQL. We shouldn't guarantee on the message order when it's getting processed. In case we reverse the transaction again we need to publish the message. It will be a loosely coupled and asynchronous one. We can add a message system to communicate with other systems. In this flow, the number of proxies will get increased. Other service calls based on business logic will be held at the proxy. We can add a proxy to the microservices so the atomic operation will be done at the microservice. We can call one service from another one then microservice mesh with multiple API calls. Some people will move the authorization to the corresponding services based on their needs. The gateway should be a pass-through layer with authentication and authorization alone. If we are doing aggregation at the gateway, then the gateway becomes very heavy. Multiple service calls can be done at the gateway using aggregation or we can add the logic at the corresponding services level. Interservice Communication (Resolver)ĭata fetching from multiple services. In Microservices architecture we can keep Authentication and Authorization at the gateway level or services level, or API level based on the business and performance. It provides different names like Query and Mutation of CRUD operation. We can access it via the playground or simple post API from the postman. It provides HTTP verbs for a different type of CRUD operation. Directly we can access it from the browser. The difference is GRAPHQL using queries as part of the post method for all types of CRUD. Both will support microservice architecture. Here REST and GRAPHQL are using JSON as data transfer. Data transfer has been reduced a lot using JSON instead of XML. That is the big milestone in terms of performance using data transfer. Rest replaced SOAP because of a content type. I am seeing a lot of posts about how GRAPHQL is going to replace REST.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |