I can distill it down to “backend devs love rest and front end devs love GQL”. The reason is simple: you have to pay the complexity cost somewhere. From multiple experiences I can point to GQL pushing complexity to the backend and rest pushing complexity to the front end.
For me, the transport mechanism matters less these days. I do prefer GQL because it forces you to think and model your data as an infinitely extendable graph. Last project I used rest on we went through the hoops of trying to find a way to fetch related models, and select specific fields…
In the end, however you can build and maintain something of value wins regardless of the tech or framework.
I’m not sure if gql results in bigger complexity on the backend. If you consider schema first approach. When designing an API it forces consistent schema on the backend and it's something not only fronted dev will appreciate. An even more interesting approach would be not to write your resolvers at all and use gql schema to construct a graph DB - take a look at Dgraph. Doesn't it cut the complexity of managing separate DB, rest API, and keeping documentation up to date?
I'm afraid with Dgraph I might run things that need to be changed later. Not sure that's a valid fear. There are similar solutions, like how with Hasura you can generate the schema based on your PostgreSQL schemas.
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.
Yes a bit click baity ;).
I can distill it down to “backend devs love rest and front end devs love GQL”. The reason is simple: you have to pay the complexity cost somewhere. From multiple experiences I can point to GQL pushing complexity to the backend and rest pushing complexity to the front end.
For me, the transport mechanism matters less these days. I do prefer GQL because it forces you to think and model your data as an infinitely extendable graph. Last project I used rest on we went through the hoops of trying to find a way to fetch related models, and select specific fields…
In the end, however you can build and maintain something of value wins regardless of the tech or framework.
And nice article review of the options!
Is it true that FE devs love GQL? To us it's just another string to send to the BE, it could've been a SQL string for all I care.
it shifts a lot of work from FE to BE, of course FE dev love it 🙃
Did you considered JSON:API specification? It supports both features within REST architecture.
In my experience many issues with REST are caused by using an ad-hoc architecture, which can't support the features needed.
I’m not sure if gql results in bigger complexity on the backend. If you consider schema first approach. When designing an API it forces consistent schema on the backend and it's something not only fronted dev will appreciate. An even more interesting approach would be not to write your resolvers at all and use gql schema to construct a graph DB - take a look at Dgraph. Doesn't it cut the complexity of managing separate DB, rest API, and keeping documentation up to date?
I'm afraid with Dgraph I might run things that need to be changed later. Not sure that's a valid fear. There are similar solutions, like how with Hasura you can generate the schema based on your PostgreSQL schemas.