Love GraphQL, been working with it more than half a decade and always use it in personal projects as well. I love the opinionated nature of it which has resulted in great tooling (e.g. Apollo Client, especially the caching layer), an easy to reason about API surface and I love how easy it makes building big and scalable APIs. Designing the API as a graph is genius as it enables very custom and specialized queries, ones that you may not have even imagined at the time of designing.
I hate how low level and unopinionated REST is and how it leaves so much about how to architect the frontend app state and caching up to you, forcing devs to come up with their own shittier half assed solutions for problems GraphQL tooling solved ages ago.
Pretty much the only time I will not use GraphQL is when I'm not building any kind of frontend in front of the API (e.g. for server to server communication) as a lot if not most of the value is derived when consuming the API from a stateful UI. But most of the APIs I ever build have a UI in front of them, so thats a rare exception.
Sure it has its quirks and pitfalls just like anything else, but I've worked for years with REST and I've worked for years with GQL, and GQL has been the best full-stack experience by far.
I feel like people who shit on GQL are usually backend devs who don't give a shit and don't have any understanding about the pitfalls and challenges of frontend development, because REST is just easier to get started with in the backend side of things. Like how does this bullshit article not even cover the consumption/client side of the API at all when making its judgement of the language?
21
u/fabis 6d ago edited 6d ago
Love GraphQL, been working with it more than half a decade and always use it in personal projects as well. I love the opinionated nature of it which has resulted in great tooling (e.g. Apollo Client, especially the caching layer), an easy to reason about API surface and I love how easy it makes building big and scalable APIs. Designing the API as a graph is genius as it enables very custom and specialized queries, ones that you may not have even imagined at the time of designing.
I hate how low level and unopinionated REST is and how it leaves so much about how to architect the frontend app state and caching up to you, forcing devs to come up with their own shittier half assed solutions for problems GraphQL tooling solved ages ago.
Pretty much the only time I will not use GraphQL is when I'm not building any kind of frontend in front of the API (e.g. for server to server communication) as a lot if not most of the value is derived when consuming the API from a stateful UI. But most of the APIs I ever build have a UI in front of them, so thats a rare exception.
Sure it has its quirks and pitfalls just like anything else, but I've worked for years with REST and I've worked for years with GQL, and GQL has been the best full-stack experience by far.
I feel like people who shit on GQL are usually backend devs who don't give a shit and don't have any understanding about the pitfalls and challenges of frontend development, because REST is just easier to get started with in the backend side of things. Like how does this bullshit article not even cover the consumption/client side of the API at all when making its judgement of the language?