There’s been a long debate about whether it’s better to use REST or GraphQL for building microservices. Both technologies have their proponents and critics, but when it comes to the specific needs of microservices architectures, GraphQL emerges as the clear front-runner. Here’s why.
Understanding the RESTful Concerns
While REST has been the go-to API style for many years, lauded for its simplicity and general applicability, its limitations become glaringly apparent in the context of microservices. These limitations include:
- Over-fetching of data
- Multiple HTTP requests for related data
- Complex versioning strategies
Such issues can impede microservices architectures’ performance and scalability.
Over-fetching of data: REST APIs are designed to return a fixed set of data, which often results in over-fetching. This redundancy is particularly problematic in mobile networks, where every extra byte of data can lead to slower applications and degraded user experiences.
For example, imagine we have a REST API endpoint /api/user/{userId}, which returns the following data for a user:
In scenarios where mobile apps only require specific user details like name and email for a profile overview, fetching comprehensive user data means over-fetching.
This excess data usage can be costly for users with limited data plans and result in slower app performance and degradation of user experience.
Latency and the N+1 problem: Microservices often require data spread across multiple services.
Suppose you have an ecommerce application where the order domain handles product, customer, order and return entities, and the stock domain manages product, stock, warehouse and delivery entities. A common operation might be to display order details along with the current stock status for each product.
Let’s say we have an order microservice and a stock microservice to handle orders and stocks.
In our scenario, a customer places three orders (N=3) and each order contains four different products. To display the order details with the stock status for each product, the application initially makes one request to fetch the orders. Then, for each product in each order, it makes additional requests to the stock microservice to retrieve stock information. This results in one initial request, plus 12 subsequent requests (three orders times four products per order), summing up to 13 API calls. This multiplicative increase in requests leads to higher latency due to multiple round-trip times (RTT) and increased load on the network and servers, embodying the N+1 problem.
Versioning challenges: Maintaining REST APIs over time involves complex versioning strategies, such as introducing new endpoints or embedding version numbers in the API path. This can lead to bloat and confusion, complicating API development and consumption.
The GraphQL Advantage
GraphQL addresses many REST weaknesses.
Domain-Driven Design: Microservices thrive on a domain-driven design, where each service is built around a specific business capability. GraphQL’s schema-centric approach aligns perfectly with this, enabling a more organized and coherent structure for microservices.
Unified schema: In a microservices architecture, each service may have its schema, representing a portion of the business domain. GraphQL stands out by allowing these schemas to be combined or stitched together, presenting a unified interface to clients. This means that clients can query data from multiple services in a single request, drastically reducing the complexity and number of network calls.
Solving the N+1 problem: GraphQL’s ability to fetch data with a single request, regardless of how many underlying services need to be called, directly addresses the N+1 problem inherent in REST architectures. This not only improves performance but also simplifies client-side data fetching logic.
For the N + 1 problem described earlier, if the services support GraphQL, it can be used to fetch nested data in a single query, effectively solving the N+1 problem.
Efficiency and performance: By allowing clients to specify exactly what data they need, GraphQL eliminates over-fetching and under-fetching issues common in REST APIs. This leads to more efficient data retrieval, reduced bandwidth usage, and faster applications, particularly noticeable in mobile environments.
In the earlier scenario where mobile apps only require specific user details like name and email for a profile overview, clients can request name and email alone.
Simplified versioning: Unlike REST, GraphQL reduces the need for versioning by allowing new fields and types to be added to the schema without impacting existing queries. This forward compatibility means that clients and servers can evolve more smoothly over time. GraphQL stands today as a mature technology that addresses specific needs in modern web development that are not fully met by traditional REST APIs. Its design promotes efficiency, flexibility, and developer productivity.
Looking ahead, the future of GraphQL is bright, with community-driven efforts focused on addressing its current limitations, particularly around security, performance and standardization. As these efforts bear fruit, GraphQL’s adoption is expected to widen, consolidating its position as a key technology in the API landscape.
