Why Volvo Car Mobility use Apollo Federation
At Volvo Car Mobility, we’re building a smarter and more sustainable way for people to have access to a car in cities. We provide a car sharing service named Volvo On Demand with the mission of enabling more people to move — freely, meaningfully and sustainably. Today, we have access to all kinds of services in our back pocket (food, music, banking, and more), but our options for using cars are still largely expensive, unreliable or inconvenient. With the technology that’s at our fingertips, we aim to change that — and we should: cars sit idle on our streets 95% of the time.
Architecture
Our car sharing service Volvo On Demand is available as a native iOS and Android application. For internal users, we also provide mobile and web applications for fleet management and operations. We use GraphQL as the query language between our clients and server. In the early days, we implemented a single monolithic service to handle all client operations, but this approach soon became inefficient due to the increasing complexity of the platform and the growing number of developers. In order to improve developer speed and system resilience, we decided to break up our monolith into a microservice architecture.
The GraphQL API layer remained in the monolith, communicating internally via gRPC with multiple microservices to resolve queries, see Figure 1. This meant all teams still had to work within the monolith for GraphQL schema changes, but with the addition of having to define gRPC service-to-service APIs and implement changes in one or more microservices. Additionally, our uptime was heavily dependent on this monolithic service.
In order to achieve the full benefits of our microservice architecture, we had to distribute the GraphQL schema. Additionally, we wanted to keep a single API for clients in order to preserve one of GraphQL’s main advantages over REST. Apollo Federation helps us achieve all of that.
Apollo Federation
Apollo Federation is a powerful, open architecture that allows for a single GraphQL API to be composed of multiple, independent services. Each independent service defines its own subgraph. Using a process called composition, all subgraphs are intelligently combined into one supergraph. A gateway serves as the access point for the supergraph, receiving incoming operations and routing them across the subgraphs — see Figure 2.
Apollo Federation enables us to:
- Keep a single GraphQL API towards clients, while the backend is distributed among independent services.
- Increase developer speed by letting us write less code; GraphQL schema changes can be self-contained within one service.
- Increase resilience; the monolith is no longer a single point of failure.
- Reduce deployment risk that occurs when multiple teams work on the same service.
- Simplify end-to-end testing when all components live in the same service.
- Gradually extract parts of our schema into subgraphs, instead of breaking up the entire schema at once.
Born out of the frustration and pain of working with our GraphQL tests in the monolith, we started off with an initial hackweek project to experiment with Apollo Federation. After further investigation and experimentation on a smaller scale, we were confident that Apollo Federation would be a good solution for us. The final step was to evaluate how well our most critical operations could be run in production as part of a federated subgraph.
Final words
Recently, one of the core teams at Volvo Car Mobility finished migrating all of their schema definitions into its own subgraph; a giant step towards becoming independent of the monolithic API layer. By adopting Apollo Federation, the team has been able to achieve all of the advantages mentioned in the previous section. Mostly, our developers enjoy the freedom of working in a single service, independently of other teams; less code to write, faster to ship and fewer risks to take!
Looking back, we stumbled upon some tricky scenarios when migrating to a federated architecture. We had to change our way of thinking around schema design and how execution flows via the gateway. Stay tuned for the upcoming parts in this series of blog posts, where we share our most important learnings to succeed when working in a federated architecture. In the next part, we will talk about entities, one of the most central concepts of Apollo Federation.
Join the movement
If this blog post made you interested in working with Apollo Federation at Volvo Car Mobility, make sure to explore our careers page for open roles.
Written by Iman Radjavi, Christopher Gustafson and Alexander Lindquister.
