I. GraphQL vs REST
- The similarities of GraphQL and REST are that both are used to create APIs, and managed over HTTP
- Regarding the difference, REST mainly focuses on the fixedness of an API (API’s durability), ie call returns data, there is no customization so it does not care much about performance.
- And GraphQL is a query language created to operate on a single endpoint, customized to match the context, so it is quite good for performance management.
II. Data Fetching
- This is one of the fascinating things that GraphQL has
- No need to request to multiple endpoints, just one endpoint to connect to data available on the server
1 2 3 4 5 6 7 8 9 10 | query { books { id title author isbn price } } |
III. Over or Under Data Fetching
- In REST it’s much simpler to find and load data than in GraphQL, because it has predefined inputs and terminals, but there is a drawback that when an additional request is needed, it creates a new endpoint
- GraphQL, on the other hand, in order to be able to use it, programmers must know how to query in this language, and also only need to get what they need in the context they want, so the return of redundant data. is impossible
1 2 3 4 5 6 7 | query { books { title price } } |
IV. Error Management
- In REST error handling it is quite simple, just check the HTTP headers to see what the error is
- But in GraphQL, it always only returns 200 OK, so it takes a lot of effort to set up or use the 3rd tool, luckily, some frameworks have built-in support like nestjs, …
1 2 3 4 5 6 | Request: query { books { error_field } } Response: Request Method:POST Status Code: 200 OK {“errors”:[{“message”:”Cannot query field ”error_field” on type ”Book”.”,”category”:”graphql”,”locations”:[{“line”:3,”column”:3}]}]} |
V. Caching
- REST is implemented using HTTP that has been caching, so it can be used to prevent getting resources
- And GraphQL does not have a caching system, so everything must be handled by hand
BECAUSE. Versioning
- When changing an api in REST it can affect old constructs if the user does not update, so version creation manages between users using the old api and the new api to avoid making mistakes
- Meanwhile, GraphQL only gets necessary data, so if developers know how to handle them, changing APIs in GraphQL will not affect old or new users.
VII. Performance Optimization
- In REST it is normal to only get a few fields but return them all, for example: when you just get the name and email fields, you call the api account, it will return all the name, email fields. , address, address, …
- And GraphQL, it will depend on the context that you want to return only the necessary fields, avoid reducing performance
1 2 3 4 5 | ‘author_name’ => [ ‘type’ => Type::string(), ‘deprecationReason’ => ‘Deprecated. Use author field’, ], |
VIII. Shortcomings with caching
- Unlike REST as mentioned above, GraphQL calls for a completely different approach, as clearly explained by graphql.org.
“In an endpoint-based API, clients can use HTTP caching to easily avoid refetching resources, and for identifying when two resources are the same. The URL in these APIs is a unique identifier that the client can leverage to build a cache. In GraphQL, though, there’s no URL-like primitive that provides this unique unique identifier for a given object. It’s so a best practice for the API to expose such an identifier for clients to use. ”
IX. Authorization issue
- Think of GraphQL as a domain-specific language, it has only a single layer placed between the server and the client. Authorization is a separate layer and the language itself has no support or use of verification.
- However, you can still use token creation for access between client and server, this is similar to REST doing before.
X. Problem with query n + 1
- When you work with GraphQL you are susceptible to n + 1 queries
- for example you have 2 tables namely users and addresses (users 1 – n addresses), when querying GraphQL you will have code like this
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | query { users { name education { degree year } age address { country city street } } } |
- As GraphQL has a so called sub resolver, when the address is called in the user, normally we would design the structure like this:
1 2 | const addresses = await this.address.find({ user_id: id }); |
- If you only call 1 user, the above sentence is okay, but if you call it as the first request, it will get query n + 1.
- This problem also has many different solutions such as:
- calls left join from the user and then passes the address received from the user passed back to the resolver
- Or split 2 streams to check private and multiple calls
- …
XI. Conclusion
Here are some issues from my experience as well as learning about GraphQL, hope it will help you somewhat better understand GraphQL.