All in all, it's all data, and there is no solution that will make my payload smaller than it physically is.
The biggest issues with REST in my opinion are under- and over- fetching, meaning that you get too little and too much data respectively.
For example, if you want to build a website like dev.to and use REST, on the front page you can read the user's details (one API call), a list of posts (another call), and their notifications (third call).
Each call receives incomplete data, which is underfetching.
Each endpoint defines what data it returns. Sometimes, you can return too much data (e.g. serialize all the comments, when we just want a count), which results in overfetching... Getting more data than we need.
You can limit that data, but then you need to define more endpoints, or pass them parameters.
GraphQL is very elegant in that it can fetch all related data in one call, rather than three (and it could be much more than three in some websites), and only returns the data you explicitly ask for, so it can definitely reduce the amount of data you send in many cases.
Which doesn't mean that you can't / shouldn't use REST, especially if you already have a running codebase... Don't go nuking the repo all of a sudden, but if you're starting a new project, GraphQL is worth a consideration.
Of course, it's newer, not as well supported as solutions that have been around for years (e.g. the django rest framework, which is gorgeous and well documented), etc. There are arguments in favour of both technologies.
You can limit that data, but then you need to define more endpoints, or pass them parameters
In GraphQL, you need to write queries, which is far more verbose than passing a parameter or picking another endpoint. For example, for news list, an endpoint might look like /news?truncated=true, while a query would be far larger.
GraphQL is very elegant in that it can fetch all related data in one call, rather than three
And this may sometimes be an issue. Let's assume you want to build a dev.to clone. You should design your REST endpoints in a manner that'll mirror the view. Then, you should leverage, what resources are needed first (post list), what are secondary (sidebar lists) and so forth. Then, you can fetch those accordingly.
This solution is also valid for GraphQL. Here it would be less API-based discussions, but like I've said previously, finding people fluent in GQL on both front- end back-end side is way harder than for REST.
All that said, I really like GraphQL and it is my go-to choice as of recently, but REST is also a great standard, and will be there for years and years.
In GraphQL, you need to write queries, which is far more verbose than passing a parameter or picking another endpoint. For example, for news list, an endpoint might look like /news?truncated=true, while a query would be far larger.
To me, writing queries is not much of an issue. You can share them with the backend if you use Ariadne and .graphql files, and like The Zen of Python says, "explicit is better than implicit."
Plus I like having them all in one directory... Oftentimes, you can see single file components with hard-coded API endpoints. With GraphQL, you can import the queries you need, and reference them. (Of course, you could make an endpoints object, import that, and reference it, but it's not as obvious / common, I think).
All that said, I really like GraphQL and it is my go-to choice as of recently, but REST is also a great standard, and will be there for years and years.
Fully agree. Pragmatism is important - use whatever works. I'd rather use GraphQL in new projects, but I wouldn't turn down a REST job, and I wouldn't bother converting an existing API unless its REST implementation has too many pain points.
As for structure, imports etc, this all can be achieved with REST. Keeping hardcoded endpoints is just as poor practice as keeping queries hardcoded (the exception may be a single-time-use thing).
The problem with queries is, while you don't mind writing them, and I don't either, there will be people that won't see it that way. And I totally understand a seasoned developer that worked with REST for 10 years that don't have the time to learn a new way to query the data, given the fact how little GQL is there in the market, comparing to REST.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The biggest issues with REST in my opinion are under- and over- fetching, meaning that you get too little and too much data respectively.
For example, if you want to build a website like dev.to and use REST, on the front page you can read the user's details (one API call), a list of posts (another call), and their notifications (third call).
Each call receives incomplete data, which is underfetching.
Each endpoint defines what data it returns. Sometimes, you can return too much data (e.g. serialize all the comments, when we just want a count), which results in overfetching... Getting more data than we need.
You can limit that data, but then you need to define more endpoints, or pass them parameters.
GraphQL is very elegant in that it can fetch all related data in one call, rather than three (and it could be much more than three in some websites), and only returns the data you explicitly ask for, so it can definitely reduce the amount of data you send in many cases.
Which doesn't mean that you can't / shouldn't use REST, especially if you already have a running codebase... Don't go nuking the repo all of a sudden, but if you're starting a new project, GraphQL is worth a consideration.
Of course, it's newer, not as well supported as solutions that have been around for years (e.g. the django rest framework, which is gorgeous and well documented), etc. There are arguments in favour of both technologies.
In GraphQL, you need to write queries, which is far more verbose than passing a parameter or picking another endpoint. For example, for news list, an endpoint might look like
/news?truncated=true, while a query would be far larger.And this may sometimes be an issue. Let's assume you want to build a dev.to clone. You should design your REST endpoints in a manner that'll mirror the view. Then, you should leverage, what resources are needed first (post list), what are secondary (sidebar lists) and so forth. Then, you can fetch those accordingly.
This solution is also valid for GraphQL. Here it would be less API-based discussions, but like I've said previously, finding people fluent in GQL on both front- end back-end side is way harder than for REST.
All that said, I really like GraphQL and it is my go-to choice as of recently, but REST is also a great standard, and will be there for years and years.
To me, writing queries is not much of an issue. You can share them with the backend if you use Ariadne and
.graphqlfiles, and like The Zen of Python says, "explicit is better than implicit."Plus I like having them all in one directory... Oftentimes, you can see single file components with hard-coded API endpoints. With GraphQL, you can import the queries you need, and reference them. (Of course, you could make an endpoints object, import that, and reference it, but it's not as obvious / common, I think).
Fully agree. Pragmatism is important - use whatever works. I'd rather use GraphQL in new projects, but I wouldn't turn down a REST job, and I wouldn't bother converting an existing API unless its REST implementation has too many pain points.
Thanks for Ariadne – I didn't know that!
As for structure, imports etc, this all can be achieved with REST. Keeping hardcoded endpoints is just as poor practice as keeping queries hardcoded (the exception may be a single-time-use thing).
The problem with queries is, while you don't mind writing them, and I don't either, there will be people that won't see it that way. And I totally understand a seasoned developer that worked with REST for 10 years that don't have the time to learn a new way to query the data, given the fact how little GQL is there in the market, comparing to REST.