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.
Related
I have developed my microservices in springboot, want to implement API gateway in it.
My frontend is Angular.
Read in detail from here:
https://spring.io/guides/gs/gateway/
(All about how to create and config gateway in spring-boot.)
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)
My understanding is that API gateway pattern is like a proxy to all microservices. So client calls the API gateway which takes care of further routing. BFF is a specific case of API gateway pattern where we have a routing mechanism for each type of client. Am I right?
Yes, it is a specific case of API Gateway. For me this comment was helpful for understanding. It says you may think about the following cases when we are talking about API Gateway - Client relationships:
A single API gateway providing a single API for all clients.
A single API gateway provides an API for each kind of client.
A per-client API gateway providing each client with an API. This is the BFF pattern.
Suppose there are 2 backend services:
A product service (to get the product info),
An inventory service (to get the available quantity).
Additionally to that, there is a frontend web application to display product details.
All the examples I see on the internet are about the frontend and the API gateway being the same application and using Zuul just as a reverse proxy.
My understanding is API gateway should be a separate application (layer) and frontend application should use it to call backend services.
In that case what is the benefits of Zuul? why not just use feign to create a client for both services and provide an endpoint for the frontend application ?
Feign client and Zuul are two entirely different components in Spring Cloud Netflix.
Feign Client is a glorified REST Template with additions such as Retry, Fallbacks etc. You can think along the lines of Apache HttpClient
Zuul on the other hand is a proxy / reverse - proxy / gateway. Typically Gateway should be a common entry point to your backend services. It should be a separate layer which allows you to add common functionalities like Authentication, Auditing, Logging etc. As #ootero mentioned, you can easily add Filters in Zuul to achieve this functionality.
Zuul as a Proxy server not only route requests but Zuul filters could also be used for handling crosscutting concerns like:
geolocation
token decryption
authentication
request / response manipulation
Traffic shaping
You mention Feign clients and that would work (to the best of my knowledge) with Java-based front-end apps, what if the front-end app is developed with Angular or React?
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