How GraphQL Fits into the Ecosystem - Architecture #2
Deep dive into GraphQL use cases & how if fits together in the existing architecture
GraphQL has gained widespread adoption by API developers in recent years. GraphQL’s flexible query language, strongly typed schema, focus on client data needs, tooling, community, and ecosystem have made it a great choice for client-facing applications and API authors.
Considering GraphQL as a layer between clients and servers, there are a few reasons: one of those reasons and the most popular one is - efficiency.
In general, the client needs to ask the server about many resources and the server usually understands how to reply with a single resource. Therefore, the client ends up doing multiple round-trips to the server to gather all the data it needs.
There are a number of benefits to using a GraphQL layer, for example, one other big benefit is communicating with multiple services. If you are having multiple clients requesting data from multiple services, a GraphQL layer in the middle can simplify and standardise this communication.
Though, this is not really a point against REST APIs as it is easy to accomplish the same over there. However, a GraphQL run-time offers a structured and standardised method of achieving it.
. . .
Difference Between REST & GraphQL
A REST API is an architectural concept for network-based software. GraphQL, on the other hand, is a query language, a specification, and a set of tools that operates over a single endpoint using HTTP.
In addition, over the last few years, REST has been used to make new APIs, while the focus of GraphQL has been to optimize for performance and flexibility.
REST APIs
True REST API is hard to pull off. It takes educated clients to consume the API correctly. If you have decided to go with the micro-services architecture, REST is probably the best style in order to enable for independent evolution of services and context separation.
It almost feels like REST and micro-services architecture were meant for each other. It also took me years to fully understand the REST, the mechanics and benefits of the server-driven application state interaction, accordance - centric design and the reality of frameworks & implementations.
Depending upon where you are in your API journey making a quick judgment on what you think REST is. It might lead to the world of problems known as so-called REST API. Below are the benefits of REST APIs
- High performance, especially over HTTP2
- Proven for decades
- Works with any representation
- Accordance-centric
- Server-driven application state
GraphQL APIs
Selecting GraphQL allows you an easy to design and amazing to consume API. It also rewards you with effortless consistency between the APIs. By its nature, GraphQL is contact-driven and comes with introspection that is something REST lacks out-of-the-box.
Using GraphQL leaves you vulnerable to what HTTP protocol and the whole internet infrastructure already solved like -
- Scaling
- Performance
- Network communication mechanics
- Concepts like content and language negotiation
Here's an Infographic representing the difference between GraphQL and REST API:
Image credit: https://devathon.com/
. . .
GraphQL Integration with Other APIs
GraphQL can be easily integrated with other APIs such as REST and SOAP APIs. It can be used to wrap legacy systems. GraphQL is quite flexible in terms of the context where it can be used.
GraphQL has been released only as a specification. This means that GraphQL is in fact not more than a long document that describes in detail the behaviour of a GraphQL server.
Below are the different kinds of architectures that include a GraphQL server::
- GraphQL server with a connected database
- GraphQL server that is a thin layer in front of a number of third party or legacy systems and integrates them through a single GraphQL API
- A hybrid approach of a connected database and third party or legacy systems that can all be accessed through the same GraphQL API
- Wrapping REST/SOAP APIs behind the GraphQL API
1. GraphQL server with a connected database
This architecture will be the most common for greenfield projects. In the setup, you have a single (web) server that implements the GraphQL specification.
When a query arrives at the GraphQL server, the server reads the query’s payload and fetches the required information from the database. This is called resolving the query. It then constructs the response object as described in the official specification and returns it to the client.
It’s important to note that GraphQL is actually transport-layer agnostic. This means it can potentially be used with any available network protocol. So, it is potentially possible to implement a GraphQL server based on TCP, WebSockets, etc.
Image Credits : https://www.howtographql.com/
2. GraphQL integration with existing systems
Another major use case for GraphQL is the integration of multiple existing systems behind a single, coherent GraphQL API. This is particularly compelling for companies with legacy infrastructures and many different APIs that have grown over the years and now impose a high maintenance burden.
One major problem with these legacy systems is that they make it practically impossible to build innovative products that need access to multiple systems.
In that context, GraphQL can be used to unify these existing systems and hide their complexity behind a nice GraphQL API. This way, new client applications can be developed that simply talk to the GraphQL server to fetch the data they need.
The GraphQL server is then responsible for fetching the data from the existing systems and package it up in the GraphQL response format.
Image Credits : https://www.howtographql.com/
GraphQL allows you to hide the complexity of existing systems, such as microservices, legacy infrastructures or third-party APIs behind a single GraphQL interface.
3. Hybrid approach with connected database and integration of existing system
Finally, it’s possible to combine the two approaches and build a GraphQL server that has a connected database but still talks to legacy or third—party systems.
When a query is received by the server, it will resolve it and either retrieve the required data from the connected database or some of the integrated APIs.
Image Credits : https://www.howtographql.com/
Both approaches can also be combined and the GraphQL server can fetch data from a single database as well as from an existing system - allowing for complete flexibility and pushing all data management complexity to the server.
4. Wrapping REST/SOAP APIs behind the GraphQL API
Another major use case for GraphQL is the integration of multiple existing REST?SOAP APIs behind a single, coherent GraphQL API. This is particularly compelling for companies with legacy infrastructures.
All the REST/SOAP APIs can be wrapped behind the GraphQL API, it can be used as data aggregator to collect information from the existing APIs
The GraphQL server is then responsible for fetching the data from the existing systems and package it up in the GraphQL response format.
Image Credits : https://www.howtographql.com/
GraphQL allows you to hide the complexity of existing systems, such as microservices, legacy infrastructures or third-party APIs behind a single GraphQL interface.
. . .
Write your response...
© 2024 Ednsquare hello@ednsquare.com