Here at Cloud Academy, we have recently been evolving our back-end architecture. We took the path toward a microservices architecture, and we’re still working on some pillars that will enable us to become faster in development while gaining overall reliability and stability.
Many projects are contributing to the core foundation of Cloud Academy’s new architecture, since we are working on different topics such as authentication and authorization and event-driven communication between microservices, along with some improvements to the infrastructure.
In this scenario, we have also introduced GraphQL as the abstraction layer between services and their clients. Initially developed in Facebook, GraphQL is now an open-source query language for APIs. It means that the client can define the structure of the data it requires, reducing the amount of data transferred between client and server. GraphQL provides stable interfaces for querying and mutating objects on the back-end services through the definition of a schema, which is the contract between the front end and back end. This solution is particularly effective to hide the complexity of the back-end systems to the front end: this is something we wanted to introduce into our architecture to ease its evolution.
Think big, start small
Once we decided to introduce GraphQL into our architecture, we planned how to do that safely. First of all, we conducted a spike to dive deep into GraphQL, and we evaluated the right technology for our needs.
We compared Java, NodeJS, and Python, with the latter emerging as the stack that best fit our needs, not only because it is the main language of our back-end stack but also because it also satisfied our performance requirements.
Once we agreed on the technological choices, we decided to test GraphQL in production to gain confidence with this technology and spot issues as soon as possible. Given these premises, we chose