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 a feature that wasn’t crucial for the business but still generated a considerable amount of traffic: learning path’s certificates generation. If you’re not familiar with Cloud Academy’s learning paths, you should take a look at our website or start a 7-day trial to explore all our features and to test our GraphQL server as well.
Back to our subject: We successfully rolled out a GraphQL query and a mutation, and we were pretty satisfied with them, so we confirmed the adoption of this technology in our stack. We started onboarding all the squads and spreading the usage of GraphQL by making it the default choice for all the new endpoints and enforcing its introduction on the existing ones.
Next steps
After a few months, we noticed that the library we relied on (graphene-python) did not offer a set of commodities such as query cost analysis, the schema-first approach support. In addition to this, graphene library has recently been abandoned by its principal contributor. For these reasons, we decided to move toward a more stable solution, switching to the de facto standard for GraphQL: Apollo Server. This choice will allow us to get the most out of GraphQL features, also giving us the possibility to set up a federated architecture to isolate GraphQL servers and avoid having a single instance covering all our needs. We will “start small” in this case as well: We will follow the same approach we used to introduce GraphQL into our architecture. We’re currently working on the first queries in Apollo Server, and we’re going to release them in a few weeks. The journey continues…
