Illustrating the advantages of GraphQL over REST and demonstrating how GraphQL enables supercharged serverless applications which are faster and more performant than REST API counterparts

GraphQL is a query language that lets you create powerful interactions with minimal to no middleware logic by allowing clients to query for and update exactly what they need and render views accordingly. This allows you the developer,  the creative and technical freedom to focus on your application logic without having to worry about the underlying network and compute costs of your code. This is particularly useful for mobile-first applications where bandwidth and computing power is constrained and devices need to render complex views with the logic being executed entirely on the client side.

This is a paradigm shift from the traditional REST based architectures where clients were constrained by predefined endpoints and often required over-fetching and under-fetching of data and additional expensive map and filter compute on the client-side to normalize the response data according to the views.

Advantages of GraphQL over REST

To understand how GraphQL shines, we need to first understand some of the limitations of REST.

A typical REST API server allows for definition of various endpoints of type GET, POST, PUT, etc. each of which is suitable for a particular task and for each new task the developer would either define a new endpoint or combine the results from existing endpoints on the client to accomplish the task.

A REST server can thus be visualized as a vending machine, where each button accomplishes a particular task, if you wanted to add a new functionality you’d add a button for that task.
GraphQL, on the other hand allows for complex querying and updates without needing to add extra endpoints for each such operation, for instance you can ask for specific fields for an object, paginate lists based on custom criteria or define resolver functions which allow you to construct queries as exactly how your view renders the data without needing to add extra endpoints or doing additional compute on the client.

The primary advantages of GraphQL over REST are as follows-

Querying multiple types at once:

With a classic REST architecture, if you wanted to query multiple types of objects at once, you either create new endpoints for each custom view or you send multiple requests from the client to fetch the different objects/lists and do client side JOINs and filter out the required keys. This approach is not only inflexible and verbose and also compute and networks intensive as it returns more data than is needed and requires client side computations.

With GraphQL however you can create indexes to query lists of a given type and resolvers to query custom lists consisting of many indexes. This allows you to construct queries that can match many different views and combine fetching multiple types of objects in a single query.

Querying for only what you need:

In a REST based application when creating custom listings, such as paginated views on criterion such as items created after a certain date, or below a certain price, you typically need to fetch all items and then do a client side filter before doing a render. This leads to either a mushrooming of custom endpoints each supporting a view or expensive data over-fetching, once more putting network and compute constraints on the client.
With graphQL you can construct your query to fetch only the page that the client needs and request only the keys that the view needs. This saves the overhead of doing client-side filtering or having to create custom endpoints to support every different types of query that a view requires.

Make complex updates without having to create custom endpoints

In a REST server you create new data or edit existing data, you typically create separate endpoints for single vs. bulk create/updates and also pass down the entire objects to the middleware and let the server find the diff of the objects. This leads to wasted bandwidth as more data is sent than is needed as well as additional compute on the server slowing down the application responsiveness.

GraphQL allow you to define custom mutations, which are basically definitions by which you can tell your database exactly which fields you want to modify, and thus saves you the overhead of having to send down entire objects. Since you can fetch data exactly customized to your applications, you no longer need to do expensive middleware logic.

Model your application logic as an object graph instead of relations

Some applications such as social-networking applications are naturally modeled as object graphs instead of relationships between tables. In a traditional REST architecture, the API layer translates the relational data model consisting of rows and columns into the object model that the UI expects. With a GraphQL, you can model your data as an object graph just as is expected in the client. This lets you simplify your application logic and model the application bottom-up as an object graph. It is no accident therefore that the initial implementation of GraphQL was developed by Facebook to solve the problem of building a performant mobile app for their social network application.

Comparing a typical RESTful architecture with graphQL/Serverless architecture

In a typical 3-tier RESTful architecture, we have a client layer running on user devices. The client is typically running javascript on a browser and the UI is modeled as an object-graph consisting of documents. The second layer is the API server which is responsible for understanding the UI queries and transferring them to the data layer. For each client query type there is an endpoint, and the client creates more complex views by combining the results of multiple queries to different endpoints.
This layer is defined by the REST specification and exposes endpoints of different types such as get, post, put etc. The third layer is the data layer which is typically a relational database consisting of tables which in turn of rows and columns.

Serverless architecture with graphQL enables removing the API indirection layer altogether and allows the client to send graphQL queries and mutations directly to the database graphQL endpoint.
While serverless architectures can be REST based as well, such architectures usually involve a REST API gateway which intercept and route the client requests to the managed data-layer and are not as beneficial or ground-breaking, the true potential of serverless is exposed with native graphQL support.
Such an architecture skips the REST api layer altogether and uses the data-layer itself as a thin API which the client can talk to.
Furthermore the data-layer in serverless architecture is usually highly available and globally replicated, allowing for low latency response to clients connecting from around the world. Native graphQL support by managed database services such as FaunaDB are enabling the new paradigm of serverless application development.

Advantages of GraphQL/serverless apps over RESTful apps


GraphQL based serverless architecture provides many advantages over RESTFul apps such as removing the need to run dedicated API servers and saving the costs associated with developing and deploying them. API servers are a layer of indirection which slow down the application responsiveness unless globally replicated themselves. Furthermore they also expose security loopholes unless the endpoints are properly secured. Without the need to run API servers, and using managed multi-tenant database layer, you can simplify your application orchestration and maintenance and can focus on your core business logic running in lean and agile mode. This not only results in huge-cost saving as using managed multi-tenant database means that you only pay for what you use and can potentially scale infinitely but also reduce the surface of attack on your application.

Any app of moderate complexity running on a RESTful architecture soon sees a myriad of endpoints which can easily turn into a maintenance nightmare without accurate documentation, this leads to significant technical debt on the part of the organization and with each app upgrade APIs need to be versioned and are often not compatible with previous versions.

When the application is using graphQL, it means that the client needs to run less computations since it can ask for and send exactly the objects and keys that it needs to. This allows developers to add more features without worrying about device compute constraints and allows for rich applications to run on smaller devices. Furthermore since the client and the API are exchanging only the minimum required amount of data, it also leads to network cost savings for the client since less bandwidth is utilized and compute costs for the server since it needs to process less data.

Since managed database services like FaunaDB which natively support GraphQL code execution run in a CDN like database-as-a-service model, the app has access to a pay-per-use globally distributed, fast data-store without needing to orchestrate containers itself and can service clients with extremely low latency and high throughput.

Conclusion

In this post, we saw how GraphQL is changing the landscape of application development though a superior and more flexible CRUD schema, allowing us to implement operations such that they exactly model our views and also allowing us to perform operations directly on the database without needing an API layer or additional logic for translating our object model to and from a relational schema. Not only is this is more efficient compute and less round trips but we have managed to entirely remove a layer of indirection from our application architecture. So go forth and build your next app with GraphQL there are several excellent resources available online to help you get started and many of the major public API endpoints now support GraphQL as a first-class citizen.