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.
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.