buyvova.blogg.se - Graphql vs rest vs grpc

#GRAPHQL VS REST VS GRPC HOW TO#

Different libraries which help you implement JSON:API or GraphQL may differ in how you opt in or opt out of this sort of extensibility, and perhaps in practice GraphQL libraries tend to require opting out (and GraphQL consumers might tend to expect a lot of this extensibility), but at the end of the day there's little difference in principle for two APIs with comparable functionality.

#GRAPHQL VS REST VS GRPC HOW TO#

JSON:API, for example, specifies how to request fields on related objects with a syntax like `/articles/1?include=author,thor`, which is comparable to the extensibility you get by default in GraphQL. As soon as you start implementing field/resource customizability in a REST API you have roughly the same problems guaranteeing performance. You will also need a message-broker like RabbitMQ or Kafka to manage some more complex state changes via events and message queues.I'm not convinced that GraphQL is any more difficult to implement robust rate limiting or other performance guarantees than a REST API with comparable functionality. So, your remote microservices will look like part of your local backend code. GRPC will make it possible to call your CQRS commands remotly like it was local.

You will benefit from the federation (parallel reads of data from several microservices will be "joined" in federation engine without any participation of your API nodes).įor communication among your backend services in write model (mutations), use gRPC. In order to seamlessly integrate Apollo, you will have to implement GraphQL layer into the architecture of all of your backend services. Use hexagonal architecture (we use Explicit Architecture in my company) to implement DDD - Domain-driven-design. Use CQRS pattern on your API and microservices, and strictly separate the read model from the write model. Use Apollo Federation as a border node to seamlessly handle the requests from your frontends talking in GraphQL. I would suggest to use both GraphQL and gRPC: It depends on the overall architecture you are implementing.

Are there better alternatives for this use case?.

in terms of ease of use, maintainability, scalability, performance, etc?

Are there any significant (dis)advantages we should consider? E.g.

How do we decide which approach to use?.

Or just creating two APIs, one facing the gateway clients and one for communication between services. Perhaps another alternative is to use the best of both worlds by implementing mutations in gRPC and queries in GraphQL. This approach will make queries more flexible, but internal requests become less performant because of the lack of protocol buffers. Option 2: GraphQLĪnother option is for each microservice to implement their own GraphQL schema so they can be easily stitched together using Apollo Federation in the API gateway. However, gRPC makes it more difficult to query relational data and requires more work to hook up to our API gateway. GRPC seems to be a popular choice for microservice internal communication because of its performance and efficiency.

In our case we have some services that are called internally by other services, but are also exposed via a GraphQL API gateway towards our clients. At my company we're about to set up a new microservice architecture, but we're still trying to decide which protocol would be best for our use case.