Follow me on Twitter, happy to take your suggestions on topics or improvements /Chris
I've written a two-part series explaining a quite common situation. You have 1 or more services where there is a team maintaining each service and it thereby lives its own life.
Sometimes you might need to build an app that needs to read from a few of these services. Instead of doing a bunch of HTTP calls, wouldn't it be great if we had something like GraphQL in front of these services so the builder of the new app can query for just the data they need? The GraphQL ends up using the URL of these services, as we Dockerize them and thereby we have a very loosely coupled approach between the GraphQL API and the Services. It's loosely coupled in the sense that the services don't know about the GraphQL API and the GraphQL API can easily replace a data source for another that conforms to the same schema, after all, it's just a URL.
I'm assuming in this series that we won't be using the GraphQL API so often, so it doesn't make any sense to give it the same uptime and thereby the same cost as the other business-critical services. Also, the GraphQL can be seen as a computation of the results it pulls in and doesn't really need to have a state of its own. Thereby it's an ideal candidate to make Serverless.
These are the two parts:
- Building the services and the GraphQL API Here we are showing how we build the services and containerize them with Docker and thereby makes them ready to easily be pushed to the Cloud. We also show how we pull in the Dockerized services, and their URLs, and build our GraphQL API
- Sign up for a free Azure account To create Serverless Azure Functions you will need a free Azure account
- Moving to the Cloud Here we are pushing each of the services to a Container Registry in the Cloud and we also create a service endpoint from each of the services. We also create a Serverless app and a function and call our GraphQL API from it. Then we bring the Serverless app to the Cloud using VS Code.
Top comments (0)