Projects in which REST is more suitable for GraphQL?

Question

Based on the articles I read, GraphQL is more resource-efficient in terms of end-to-end sessions, and it can also do what REST can provide. What are the reasons why a software developer and developers might decide to stay with REST over GraphQL, given that the web application will be launched from scratch? Also, given that this is a continuous project, it will be consumed from the Internet, and mobile and openID connections are a requirement.

Answer 1

In my opinion, among other aspects is also a matter of use:

• If you have something like an application or other external interface with a slow connection and / or a high latency (typical example: a mobile application), GraphQLs “round-trip minimization” can be a big plus. And it can be very convenient to provide control over the data structure on the client side, thereby often reducing the number of API endpoints required.
• If it is enough to exchange data between servers, the fact that the RESTful API is strongly connected with HTTP has such advantages as the semantics of verbs (which GraphQL cannot offer when performing several operations with one GraphQL query) and status codes. Plus: you get all the HTTP caching features for free, which can be very important in data-oriented applications / services. In addition, REST is ubiquitous (although probably most of the APIs advertised as "RESTful" arent, often due to a lack of support for hypermedia).

Answer 2

This is a fairly broad question, but I will try to answer my own experience.

REST provides access to a specific resource, for example. user or product. The query result may be an assumption about what data you want or use, i.e. Probably all about this resource, regardless of whether you use all the data or not.

There is also the problem of N + 1. As an example, we take that the user has and belongs to many scenarios of relations; with the RESTful API you should make a request to the user, for example. /users/:id then query all of their relationships, e.g. /users/:id/relationships , so there are already two requests. It can be assumed that the relationship endpoint should include both the relationship (friend, family member, etc.) and the user in the resulting array, but if the API does not make this assumption, you will need to query each user endpoint to receive data for each user in every respect.

This example may go deeper; What if you want all the relationships of the second level (for example, friends of friends)?

GraphQL solves this by letting you specifically ask what you need. You can build a query to return data to depth:

 query myQuery($userId: ID!) { user(id: $userID) { id name relationships { id type user { id name relationships { id type user { id name } } } } } } 

Fragments can clean this up a bit and there may be recursive problems, but you should get this idea; one request will deliver you all the nested data that you need.

Unless you have a great need for such nested or interconnected result sets, GraphQL may not offer many advantages between advantages and complexity.

However, one of the biggest advantages that I have found with GraphQL is its extensibility and self-documentation.

Answer 3

There may be several reasons. This is very subjective, I believe, but for me it is based on:

REST is an old and sustainable way. It is used by most and provides an easy interface for API users. Since this is old (by no means bad), most developers are aware of this and know how to consume it.

GraphQL is the new guy in town. Of course, this saves some performance (roundtrips and payload) for most systems, but changes the way we think about the backend. Instead of providing endpoints of resources, it provides a graph of the data model and allows the consumer to decide which data to receive.

As with the “new guy,” GraphQL is not tested in battle. This is new to the majority, and therefore not accepted by others, but primarily by pioneers and startups.

But then again, this is a subjective question with a subjective answer. I am currently using GraphQL to run to check its longevity and see if it can solve our needs. So far this is far. If you want to decide whether to start a new project using REST or GraphQL, you must consider your needs and how much money / time you want to spend on learning new things, not what you know, and reach your goal faster.