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