Core points
This article will discuss how to get data from multiple data sources while keeping the front-end responsive quickly, and a potential solution: using GraphQL gateway.
As software engineers, we all face the challenge of putting together data from multiple systems. Even a single page requires data from multiple services to be rendered.
Data is everywhere, from CRM to financial systems, from SaaS platforms to databases. It is inevitable that every business will buy a large number of SaaS platforms and then hope to get a unified business view on top of all of them. We have to face this problem and put everything together.
GraphQL gateway combines the advantages of traditional API gateways and GraphQL.
We will first discuss the advantages of API gateways and then see how GraphQL fits into it. Please continue reading this article, we will cover some frameworks for building our own API gateways.
Advantages of API Gateway
Protecting public-facing APIs from hackers is an all-weather job. Over time, organizations have evolved to create many APIs, from service-oriented architectures to microservices. Organizations tend to add an extra layer of security rather than putting these APIs directly on the internet, which is ahead of all of these APIs and ensure access to data always follows the same authentication rules.
They use API gateway to do this.
Products such as Kong or Apigee expose internal APIs from a central location. They act as reverse proxy with features such as API key management, rate limiting and monitoring.
API gateway allows us to control who and what can access each service, monitor connections and record access.
Recently, applications need to combine data from API gateways and other external SaaS providers. This means that the old centralized tools (make sure our rules are followed) are now bypassed regularly.
Suppose we are building a web application for the company. Our task is to create user profile pages. During the login process, we need to combine data from multiple systems:
The client needs to issue three separate requests to obtain the data, as shown in the figure below.
In the above image, the web client sends three separate API requests, and then the results must be combined in the front-end code. Sending multiple requests can affect the performance of your application, and combining this data can increase the complexity of your code. Additionally, if there are multiple applications, now all applications must know about all the backends, and a single API change in a service may result in updates for all our applications.
We can do better. Ideally, we want to reduce the request from three to one. We can create a new service to do this - a service that coordinates requests for backend services. This idea has a name: BFF mode.
The backend, that is, the frontend (BFF) architecture mode allows the frontend to issue a single request.
But how does it work? Let's take a closer look at this pattern.
Advantages of BFF mode
Using BFF mode, the application sends a single request to the API gateway. The BFF service then requests data from each backend service and combines it. Finally, the data is filtered and only the data required by the front end is returned, thereby reducing the amount of data transmitted over the network.
As shown in the image above, we introduce an extra layer into the stack to coordinate requests.
The user profile endpoint returns the data required by the application on the profile page. Reducing our three requests to one has solved our previous performance issues.
But we are not done yet.
The enterprise decides to release a mobile app. The mobile app also has a profile page, but this screen displays much less profile information.
At this point, the mobile team has two options. The team can use the web team's endpoints, which means we overfetch data (get more data that the mobile app doesn't need). Another option is to create your own BFFs on the mobile team.
According to expectations, the mobile team decided to create their own BFFs as they wanted good performance for their applications.
As shown in the picture above, things are starting to get complicated, and we now have two new problems:
How do we solve these problems?
We need a solution where each application can choose the data it needs, and it should be a single API used by all the company's applications.
As BFF matures, many developers have begun to try to use GraphQL instead of REST.
Let's see how this technology can help.
The advantages of GraphQL over BFF
GraphQL has many advantages that make it an ideal technology for BFF:
The front-end can now select only the required data for each request.
We can now connect two of our applications to the same GraphQL server, reducing the need for a second BFF service.
We can now share BFF for any application in our organization. We also have a single endpoint that needs to be tested for penetration.
But, we have introduced another new problem! We still have to manage two systems – API Gateway and GraphQL BFF.
What if we merge the two into a GraphQL gateway?
Next, let's see how GraphQL gateway works.
What is a GraphQL gateway?
GraphQL Gateway combines API gateway with GraphQL API for the best results of both technologies.
Let's review the advantages:
The following image shows how user profile API requests work with GraphQL gateway.
In the above image, the client sends a single request to the GraphQL gateway, requesting its required data. The gateway issues a single request to each service and combines the results. We now have only one service that needs to be managed and deployed.
I hope you are ready to try it yourself. Next, let's see how to build a GraphQL gateway.
Build GraphQL gateway
When choosing a gateway framework, we need to look for some key features:
There are many frameworks to choose from, but I recommend exploring the following three frameworks further.
Hasura has become increasingly popular over the years, initially as a GraphQL-over-Postgres server. However, it increases the ability to connect to external systems.
We can connect to a "remote mode" which combines GraphQL from other servers.
This method has some disadvantages. First, we need to create and manage our remote schema in a separate service, and this service must be a GraphQL endpoint. This leads to a second problem: we cannot directly connect to the data source.
In addition, Hasura does not allow us to filter data in one data source based on the values in another data source. This may sound academic, but we often want to express something like “give me an order with the name ‘ABC’”.
This provides flexibility, but at the cost of running multiple services. Let's take a look at an option that can be connected directly.
StepZen allows us to connect directly to the data source from the GraphQL server. This reduces the need to run multiple services to create a gateway.
To connect Stepzen to the data source, we create a GraphQL schema file as shown below:
<code>type Query {
anything(message: String): JSON
@rest (
endpoint: "https://httpbin.org/anything"
method: POST
headers: [
{name: "User-Agent", value: "StepZen"}
{name: "X-Api-Key", value: "12345"}
]
postbody: """
{
"user": {
"id": "1000",
"name": "The User"
}
}
"""
)
}
</code>In this example, we use custom mode to connect the server to the database.
There is another option you might prefer, which is the pure code approach. Let's take a look next.
For the past few years, I have been developing an open source product called Graphweaver that can be used as a GraphQL gateway.
It connects directly to our data source and creates an instant GraphQL API. This API contains all CRUD operations we may expect to create, read, update, and delete. It automatically generates filters, sorting and paging parameters, saving time. We can extend built-in operations with our code for complete flexibility.
Graphweaver provides data connectors out of the box for databases such as Postgres and Mysql, as well as SaaS providers such as Xero and Contentful.
Making changes or connecting to data sources involves writing Typescript code, allowing us to make full customization.
If you are interested in creating your own GraphQL API, I highly recommend you check out the Graphweaver GitHub code.
Conclusion
In this article, we examine how to replace our current API gateway and BFF pattern with a single GraphQL gateway.
We examined the advantages of API gateways and why organizations use them. Versioning, rate limiting, and access management are some reasons.
We also looked at the BFF pattern and how it coordinates API requests for front-end applications.
Finally, we looked at GraphQL and why it is a beneficial technique for BFF.
End of the day, this led us to create a GraphQL gateway, and we looked at three options to create our own: Hasura, StepZen and the product Graphweaver, which I have been developing.
I hope this article convinces you to try using GraphQL gateway yourself, and if you can, consider trying Graphweaver.
GraphQL Gateway FAQ (FAQ)
The GraphQL gateway acts as a single entry point for all GraphQL operations. It is responsible for routing requests to the corresponding service, aggregating the responses and sending them back to the client. This allows you to manage multiple GraphQL patterns and services from a single location, making your applications more scalable and easy to maintain.
The traditional API gateway is designed to handle RESTful APIs, and its operating mode is different from that of GraphQL. On the other hand, GraphQL gateways are specially designed to handle GraphQL operations. It provides features such as pattern stitching and merging that allow you to combine multiple GraphQL patterns into one. This is something that traditional API gateways cannot do.
Mode stitching is a feature of the GraphQL gateway that allows you to combine multiple GraphQL patterns into one. This is especially useful when you have multiple services and each has its own schema and you want to expose them as a single API. Pattern stitching is responsible for merging the patterns and resolving any conflicts, providing a seamless experience for the client.
GraphQL gateways can significantly improve performance by reducing the number of round trips between clients and servers. Instead of making multiple requests to different services, the client simply makes a single request to the GraphQL gateway, which then routes the requests to the corresponding service, aggregates the responses and sends them back to the client. This reduces network latency and improves overall performance.
Yes, GraphQL gateways are particularly suitable for microservice architectures. Each microservice can have its own GraphQL pattern, which the gateway can splice together to provide a unified API. This allows you to independently manage and scale microservices while still providing a consistent interface to your clients.
GraphQL gateway is language-free, meaning it can be used with any programming language that supports GraphQL. This includes popular languages such as JavaScript, Python, Ruby, and Java.
GraphQL gateway provides powerful error handling capabilities. If an error occurs in one of the services, the gateway returns a detailed error message to the client, including information about which service caused the error and what error occurred. This makes diagnosing and fixing problems easier.
Yes, GraphQL gateway is compatible with serverless architecture. You can deploy your gateway as a serverless function, which allows you to take advantage of the scalability and cost-effectiveness of serverless computing.
GraphQL gateway provides a variety of security features including authentication and authorization, rate limiting and request verification. These features help protect your services from unauthorized access and abuse.
Yes, you can use GraphQL gateway with your existing RESTful API. Gateways can wrap your RESTful API in GraphQL pattern, allowing you to take advantage of GraphQL while still using existing APIs.
The above is the detailed content of Build a GraphQL Gateway: Combine, Stitch or Merge any Datasource. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
