GraphQL Beyond HTTP APIs

Hi, let's talk about GraphQL beyond HTTP APIs. My name is Guilherme Fiera. Feel free to call me Gui. I live in Vancouver, Canada and I work at Shopify in the API Appendix Team.

GraphQL is commonly used as an HTTP API. You submit your query to the endpoint and get a response. This is how a request looks like. The client converts the query and the variables into JSON, adds some kind of authorization header and makes a POST request. This is an example of a GraphQL server executing a query.

Putting them side by side, we can see that the back-end routs the HTTP methods and path to a function or method. Then, use the request payload as arguments to building a GraphQL query. It gets the variables and the query keys. And it makes a query aware of the current user by checking the authorization header. Then, it executes the query and returns a JSON response. WebFramework is doing an excellent job on making very easy to get data from HTTP requests and performing any kind of business logic with them.

This is very good, but can we go further? Executing GraphQL relies on very simple data structures that can come from anywhere, not only from HTTP requests. The query is just a string. The variables, just a hash. And you're free to provide any context to the query execution. GraphQL doesn't depend on HTTP requests. HTTP is just a layer that transports our data, and GraphQL doesn't depend on any transport layer. GraphQL doesn't even require a network. This allows GraphQL to be used in a variety of use cases. Let's get to know some GraphQL use cases beyond HTTP APIs.

The first example is WebSockets. Subscriptions is a very common use case of GraphQL using WebSockets, but we are not limited to that. We can use WebSockets for any kind of real-time communication or asynchronous communication where you send a query or a mutation and you're not expecting to get a response right away. Or if you are sending several queries or notations, you're not expecting to get a response in the same order you submit it. And because WebSockets keep open connections, it's very performant and very suitable for real-time messaging.

In this example, the user is sending a message to a chatroom and we don't need to get the response of the mutation right away.

We should be able to send several mutations and handle the response as they return. Another very good use case for GraphQL is in background jobs. We use background jobs for recurring tasks, for example, reporting, or sometimes for something that can be run asynchronous, like sending a notification. And we need to get some data for running those background jobs. And we can use GraphQL to get this data. It's very good because you get the data using the same business logic and formatting that you have, for example, for your HTTP API, so it's very easy to handle the data in a way it's useful for you.

In this example, we have a daily sales report where we can generate the GraphQL variables, in this case the beginning and the end of the previous day, and rerun the GraphQL query, and the results is the data that will be used by the mailer to send the report by email. And you can have a predefined query, so this can be the query that returns all the data needed to generate the email report, so here you have the start and end date timestamps that was generating when the background job ran, and you have the number of orders for this particular timeframe, and some of the latest orders with some of the details.

Another use case is for book operations, so book operations are background jobs, but they handle large amounts of data, both for importing and exporting, so, for queries, it's very useful when you want to export large amounts of data, and if you see here, for the orders, it's a connection, but we are not, we're not limited to, for example, 100 records per page, so, instead of having to paginate and get all the data for all orders, you can split this huge query into smaller pieces and then assemble all the data at the end. So, this way, it's fast and safe to get this kind of huge data export. Fermentations is a bit different. It's very useful when importing large amounts of data, and you can provide all the input fields as a JSON file, and iterate over every line of the JSON file.

Another use case is when generating webhook payloads. So, when you have to deliver a webhook, because some kind of event was triggered, it's very important to have consistency between the payload that you provide on your webhook, and, for example, the data the user expects from the HTTP API. Web assembly. This is very nice. This allow us to execute any code that was provided by the user, and because we have control over how the GraphQL query is executed, you can limit, for example, you can deny any kind of mutations, or you can override any kind of authorization, or anything that you want, so it's very safe to execute untrusted code, and because many languages can compile to WebAssembly, it gives users a lot of flexibility.

Thank you for watching. I hope to answer any questions in our Q&A session, and see you soon. Bye-bye. Thank you.