I'm using the GraphQL server which is most-often a gateway that bundles all my different microservices created using gqlgen.
I want to make a switch to the TwirpQL server as I was following the official documentation of TwirpQL. I believe it wants me to wrap every microservice inside it so there will be multiple GraphQL layers one for every microservice.
I don't want to expose the other microservices as Graphql, but rather "just" create one entry point for all the requests and later send them to the respected microservice accordingly.
Can anyone please enlighten me on the correct usage?
Thanks.
Related
I'm building a graphql gateway service, which merge multiple services into one graph, using Apollo/Node/Express and following the Apollo Federation model. Initially, most of the services I'll be connecting to are REST services.
In all of the examples I find (e.g. here), I see that the gateway project runs multiple instances of ApolloServer, one for every REST service plus one more for the gateway itself, and runs them all using a package like concurrently. Basically the gateway project runs n+1 ApolloServers. Having all of these servers running seems strange to me, but I'm pretty new to this whole ecosystem.
I'm not clear if this is just for demonstration purposes, or is this also how it's implemented and deployed in the real world?
I hope that those were just examples, and are not the expected pattern.
If you need multiple GraphQL Services, each one of those would be served as a separate Domain Graph application, as its own project. Then an additional service (the gateway) would consume all of those applications and expose a single unified GraphQL API.
Planning to migrate my PHP APIs to Graphql using Apollo Federation. After a bit of research, I see it is done using the following way:
My questions are:
Is there any better way to create the federated services so it is not a separate layer (1 for each REST API)? Maybe something close to the previous schema stitching approach where all can sit in one place and be stitched together at the end (instead of a specific federated layer for each service).
If this is the recommended way, how do I deploy this infrastructure? From the diagram, does it mean I have 5 instances running to cover all of the services?
Is it recommended to run Gateway and Federated services all inside one instance (from diagram - 3 servers running in one instance)?
Let me know if it helps.
Federated services are great when you want to break the monolithic structure of the non federated implementation of apollo server. It can be designed by incorporating the micro-service best practices. Instead of blindly having one federated service per rest endpoint, you can have federated services based on the functionality the service is suppose to take care. One service can call multiple rest endpoit. This would provide you better control on scaling, securing and managing services at infrastructure level. An example can be as simple as amazon where item browsing hits will be way more than buying transactions. In this case you can have one federated service which provides browsing data where as another one can for managing transactions. Then you can scale one to multiple instance to handle user load and have additional security in place for the one hadnling transactions.
2 & 3. Yes you would need to have deploy all the components separately. I would recomend to have all the services in the same VPC cluster so that you don't have to worry about network layer security. If the services are deployed across multiple clusters, it will be adding handling firewall and https/tls for every request, which would cause unnecssaery delay becuase of network call. Although it would be in milliseconds but can be easily avoided.
I am well aware of the fact that east/west, or service to service synchronous communication between services is not the gold standard, and should only be used sparingly in a microservice architecture. However, in every real world implementation of a microservice architecture, I have seen some use-cases which require it. For example, the user service is often needs to be communicated with by other services to get up the millisecond details on the user (I'm aware that event based sharing of that data is also a possibility, but in some cases that isn't always the right approach).
My question is, what is the best way to do function to function, service to service communication in a Lambda + API Gateway style architecture?
My guess is that making an http request back out on the domain name is not ideal, since it will require going back out over the internet to resolve DNS.
Is it using the SDK to do an invoke on the downstream function directly? Will this cause issue if the downstream function depends on an API Gateway Proxy Event structure?
I am starting to build a Microservice API Gateway, and I am using Spring Cloud Zuul to help me with the routing. But some calls to the Gateway API will need multiple requests to different services.
Lets say I have 2 services: Order Details Service and Delivery Service. I want to have a Gateway endpoint GET /orders/{orderId} that makes a call to Order Details service and then Delivery Service and combine the two to return full Order details with delivery. Is this possible with the routing of Zuul(maybe filters?) or should I make these by hand(create a controller specifically for these kinds of requests) using something like RestTemplate to make the calls?
You can avoid that complication and forward request from your Gateway to the Order service to make an order, than make HTTP request from Order service to Delivery service to make the delivery. By nature those entities work like that. And don't worry about the speed, it is extremely fast.
That is in a first place, in your case, if you want to get the order details, with delivery details, that should go in the same manner. Maybe even your order service should persist some of delivery details in its database. We were doing it like that, you should avoid redundant data, but sometimes it make sense.
Here is the chart of making the order:
Make sense?
We are evaluating a move to microservices. Each microservice would be its own project developed in isolation. During planning, we have determined that some of the microservices will communicate with other via REST calls, pub/sub, messaging (ie. a order service needs product information from product service).
If a microservice depends on retrieving data from another microservice, how can it be run in isolation during development? For example, what happens when your order service requests product details, but there is nothing to answer that request?
What you probably need is an stub rest service. Create a webapp that takes the expected output using a path that is not part of the public api. When you invoke the public api it sends what it just received
If a microservice depends on retrieving data from another microservice, how can it be run in isolation during development?
It should be always temporally isolated from other services during development and production as well.
For example, what happens when your order service requests product details, but there is nothing to answer that request?
This is a place where design flaw reveals itself: order service should not request product details from another service. Product details should be stored in the message (event) that order service will be subscribed to. Order service should be getting this message in an asynchronous manner using publish-subscribe pattern and saving it in its own database. Data about the product will be stored in 2 places as the result of that.
Please consider reading this series of articles about microservices for more details. But in a nutshell: your services should be temporally decoupled, so when your product service is down - order service can continue its operations without interruptions. This is the key thing to understand about good distributed systems design in general.