I would like to replace all my REST APIs with GraphQL (apollo-server preferred). It's clear to me how to use GraphQL in monolithic apps but it's not clear how to do it for microservices.
The main API server consists of multiple microservices where each microservice exposes its own REST API through which the central API server communicates with it. I would like to replace all these REST APIs with GraphQL thus I would get microservices as nested GraphQL servers communicating with each other through GraphQL instead of REST.
The problem that I'm facing is how to easily build a GraphQL query string for microservices based on the received attributes in the resolver of the main GraphQL server. There is no way to tell GraphQL to return all the fields for microservice. The best way would be to simple forward just a part of a the main query further to a microservice.
Any ideas? Do you think that REST is still more appropriate for microservices then GraphQL?
I can suggest you to use WAMP protocol and then build a network of all of your functionality.
Finally serve it under 1 GraphQL server
Related
We have few existing rest apis written in spring boot to fetch different data in our project? Now we are exploring options to use GraphQL. But we don't want rest endpoints & response to change since it is being consumed by many UI/backend applications. Can anyone suggest proper way to use GraphQL within existing API without changing rest endpoints and Response type?
Team,
I was an evaluating architecture and it seems that the architecture plans to have a BFF like GraphQL sitting before API Gateway like APIGEE. Just to add, the backend microservices are written in Spring Boot.
Does it make sense to have both BFF and APIGEE? Is there anything that can't be handled via GraphQL which has to be taken care of by the API Gateway?
Thanks
Ashish
In case you missed that API Gateway is now available: https://cloud.google.com/api-gateway/docs/about-api-gateway
I am also currently running a Cloud Run service (kotlin/spring-boot) with a GraphQL endpoint and will try to bring it together with the API Gateway (beta)
We have micro-services with the following architecture:
web-ui <-> graphQL <-> n * back-end services
We are implementing PACT consumer driven contract tests which is working well between the back-end services.
However there are questions on how to implement this through the graphQL layer. In reality this is a consumer of the back-end services, and a provider to the web-ui.
As the consumer, GraphQL doesn't have the domain information for the actual required json that is initiated from the web-ui service. Then the web-ui service doesn't test against the back-end providers (as the graphQL layer is its provider) - and it hasn't got that association / knowledge of the back-end services.
Is it that graphQL should create a PACT interaction with each back-end provider containing all its potential values with each service. Then this demonstrates that those interfaces remain compliant. Thus the real request (interaction) from the user (web-ui) has pacts with the GraphQL service (with mocks of the back-end services), so implicitly would work all the way through the stack.
Has anyone got advice of how this works across this aggregation layer?
I am currently working on a project which has a GraphQL service that takes care of handling all client requests and communicates with other microservices as needed be. This GraphQL service is the only service exposed to the client, basically kind of like an API gateway.
Taking this into account, I was wondering if all microservices are required to have authentication/authorization handlers, as well as input and data validation. Since these microservices can only be accessed by the GraphQL service and are never exposed to the public, is there any risk to not performing these mentioned tasks on them? Can't the main GraphQL service simply take care of all the authentication, authorization and input validation and then proceed to only send requests to the microservices having these steps occurred successfully?
I'm trying to understand if it's possible to use KONG as API Gateway to microservices implementing REST and/or GraphQL interfaces
As API Gateway will expose a GraphQL API and will request to our microservices currently implemented in REST/GraphQL and grpc coming soon.
It can route the Graphql as any other HTTP request but it doesn't parse graphql to route each bit to a a specific service
Kong can front any RESTful API and through a transformation plugin you should be able to deal with GraphQL API as well.