I have a use case where a microservice communicates with front-end as well as other microservices. Currently it is using REST for all its communication. Can I expose GraphQL for frontend API's and use GRpc for internal communications in the same microservice on the same server . Can I have Grpc and Graphql implementations on the same server . I am using Spring with java 11 . Are there any examples for this .
Yes you can, I've used this setup for many services. But you will need to bind the gRPC server to a different port than the rest api. Check the documentation at https://grpc.io/docs/languages/java/basics/#starting-the-server. You could then expose only the rest api port to the external users and let the services communicate internally on the "trusted" gRPC channel.
Related
I am using grpc http protocol but i want to pass all grpc calls through a gateway to centerlize the calls. I am using Zuul proxy gateway in spring boot application. How can I implement this ?
Last I checked zuul doesn't support http/2 which gRPC needs.
I need to convert monothic application to micro service architecture. Few suggestion/confirmation are required before i finalize the design.
I will be using docker containers and kubernetes. Structure will be like this
Ingress -> Zuul API Gateway--> Microservice
-> Angular PODS
Ingress Router to route traffic to
Angular PODS where angular code will be present
API Gateway Zuul API Gateway where we will perform Authorization and
Authentication
So my doubt is, for inter service communication do we need to configure SSL ?
It depends on the level of security you need for inter-service communication. If that is required, I would recommend to use service mesh for the same. It will give mutual TLS for your services and many other benefits. Istio (https://istio.io/) is the most widely used service mesh.
I'm setting up an environment with an API Gateway (KONG) and microservices (Spring-boot apps), but I have a lot of doubts/concerns with the SSL communication between them.
Should I put the SSL settings in the API Gateway or on the microservices?
Currently my microservice app has its own SSL certificate and it runs in a container through 8443 port.
But now implementing the API Gateway, I'm not sure if I have to remove it from my microservice and setting up in the API Gateway or add it in both.
I expect the correct communication between my microservice and the API Gateway in order to the clients are able to consume the services through 8443/ssl.
Your API gateway will be facing the clients. So for secure communication, your API gateway must be behind the SSL.
Regarding microservice, it's up to you to have it behind SSL or not. Both way it will work. According to me, if your microservices are restricted within the VPC (and API gateway is part of the same VPC) and not exposed publicly, then there is no need to have microservices as well behind SSL.
The setup:
I have a set of Spring Boot based microservices that are fronted by Spring Cloud Gateway, meaning every request that comes from UI or external API client first comes to Spring Cloud Gateway and is then forwarded to appropriate microservice.
The routes are configured in Consul, and Spring Cloud Gateway communicates with Consul to get the routes accordingly.
Requirement:
There is a need of some microservices communicating with each other with REST APIs. I would prefer this communication to happen via the Spring Cloud Gateway as well. This will help in reducing multiple services going to Consul for getting other service's details.
This means every service should know Gateway's detail at least. And there can be multiple instances of Gateways as well. How is this dealt with in bigger architectures?
Any example that I look up contains one service using Consul, or Gateway using the consul with one microservice. Couldn't understand how to extrapolate that design to a bigger system.
I have a restful application made in Go, now I have to make this app also serve as gRPC server (I already created the needed files). I have the restful endpoints running in the port 8000, now I have the next questions:
Can I server grpc as well as the restful app in the same instance?
Should I assign a different port to serve gRPC?
What is the recomended approach in this case? as the grpc stub will be only
consumed by some of our microservices, but the restful will be
consumed by the frontend of some apps
In the case that I can serve boths, how should I initialize the servers?
Yes! If you want to serve gRPC as a RESTful service, there is a gRPC Gateway project that allows you to annotate your Protos, so they can be served over REST.
Yes, but this gets a little trickier. The gRPC server in Go implements net/http.Handler, so you can add it to your existing HTTP server. Getting the URL paths to match is something you'll need to play around with, but it is certainly possible.
I don't think there is any recommended approach. It depends mainly on environment constraints (such as if there are proxies, how you encrypt your connections, etc.).
Initialize the gRPC Server first, and then add it to the HTTP server.