Front-End System Design

Classic REST & GraphQL

Evgenii Ray

Evgenii Ray

Staff UI Engineer
Front-End System Design

Check out a free preview of the full Front-End System Design course

The "Classic REST & GraphQL" Lesson is part of the full, Front-End System Design course featured in this preview video. Here's what you'd learn in this lesson:

Evgenii compares classic REST APIs with GraphQL. Adding a GraphQL API introduces additional complexity, including requiring client libraries, caching layers, client state management for syncing data with the server, and the potential impact on JavaScript bundle size. GraphQL can also reduce complexity by providing a single API for client applications but multiple network implementations on the server.

Preview
Close

Transcript from the "Classic REST & GraphQL" Lesson

[00:00:00]
>> Evgenii Ray: Okay, REST vs GraphQL, so generally, when you want to introduce the GraphQL in your application, you need to think about the consequences. So it's you're adding the new client library to work with the server with your GraphQL API. You're adding the new additional client caching layer that maintains the cache for you.

[00:00:22]
And you also add in a new state manager that ensures that your client is synced with a server. And there is also a potential impact on the web bundle size. So this is the tax that you pay when you introduce the GraphQL. And I would say, GraphQL is great, but there are use cases when you actually want to fall back to REST.

[00:00:46]
So let's go for the schema. So I try to draw the decision diagram. [LAUGH] And so first, parameter that you need to consider is your application size. If it's a very small app, then you'll be fine with a classic REST. You don't need GraphQL, because GraphQL complicates things.

[00:01:05]
If it's a medium or large size app, the next point is, are you planning to consider the public API? If you are planning to build the public API, then probably the classic REST is the way to go because most of the clients expect to have the REST API.

[00:01:20]
Then the next point is, how many of your requests are read-only? So if the good chunk of your request are read-only and you have a limited budget or the team size, then the REST would be better because you will be able to utilize the default HTTP server cache and the client cache.

[00:01:42]
So you would simplify your architecture. But if you have the large team size or you have unlimited budget, you can still go with GraphQL. But one question you would ask is, do you use isomorphic types? Isomorphic types is when your server data types are shared between the clients, so they have a very close relation.

[00:02:08]
So if this is the case, then the GraphQL might be considered. If it's not the case, then you need to do lots of transformation of the data, then it's probably the classic REST still better way to go. And then, is it critical for your bundle size to be increased by 1,500 kilobytes?

[00:02:30]
And if it's yes, again, classic REST. And do you expect to have your API model to be complex? Are you expecting to return different variation of the same object? In this case, the GraphQL might be a good decision, so we can choose the GraphQL. So as you can see, there are more nos than yes, but let me try to be unbiased.

[00:02:55]
The GraphQL actually provides the most values in the Complex Apps. It's actually can help you to simplify the architecture sometimes. Consider the following case where you have a trading app, and within this trading API, you have three endpoints. One is using short polling, another one's WebSockets, and so they get orders that gives you your current orders, use the short polling.

[00:03:20]
Real time price, we're using WebSockets and getOrderUpdates using the server-sent events. So in your web application, you will have to use three different ways how you get the updates from your endpoints. So you can encapsulate these complexity on the internal layer by basically, having the GraphQL that has a subscription that implements different source stream.

[00:03:49]
The source stream is just interface of the endpoint you're going to utilize. So the source stream can implement the short polling, the WebSockets, or server-sent events. So you can implement this on the source stream level. So your developers will use the same subscription across the whole application, but internally it will be backed by different protocols.

[00:04:16]
So this way, you can actually simplify the way how you fetch the data from the server, minimizing different code style and maintaining unified code. So this is the case where the GraphQL can really help. And I stand to the point that the GraphQL really helps in the Complex Apps where you have lots of variations of the data that you receive, and so on.

[00:04:44]
And for simple cases, you will be good with a normal REST API.
>> Evgenii Ray: And we're done, this is the section for network connectivity. So we basically walk through the different types of the APIs and now you have the good overview, what we can use. And you definitely need to work with the server folks to provide you such endpoints, but it's always good to understand what are the types of the protocols available to us.

[00:05:12]
And the next section will be the performance optimization of our application.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now