Software engineer, architect, consultant, amateur UI/UX designer, computer enthusiast, gamer. Often coming up with ideas and thoughts that I then write into a post within the next 60 minutes.
REST API as a concept has been known for nearly 20 years. The GraphQL specification was publicly released 6 years ago. There are tons of frameworks out there which already contain support for REST API implementation, in a variety of languages, with all sorts of features and helpful things for developers to start using it out of the box. We have it so easy when a framework converts those HTTP requests to a standardized request / response format, with easily implementable middleware per route and all sorts of cool gadgets to make it even better.
GraphQL doesn't really have this kind of ecosystem. At least not yet in the open source world (I think?). Commercial solutions might have some since they're motivated by money to produce them.
If GraphQL solved some specific problem we have, since most of us don't work at the level that Facebook operates in, people would be all over it. I'd bet there'd be tons of libraries out there that allowed users to write GraphQL schemas with custom directives for queries, mutations and fields with little effort, and middleware/some other security mechanism to protect those. So far I've had to implement all of those by hand, because there's very little support for mechanisms like those in languages like PHP.
We used GraphQL on a front-end rewrite project and it didn't take long for five developers to learn how it work. It's not that hard. When you explain to them what the n+1 problem is and how you can solve it by deferring resolving to a later stage when you have all the necessary data to perform a batched query or something, it's relatively simple to use.
Unfortunately, who likes implementing that extra layer of complexity to a project without any significant performance increase (mobile devices?) when you're not Facebook? I personally like GraphQL, because it gives me type safety and a pre-defined schema for my API. That's quite good in languages like JavaScript or PHP. I don't really like writing an OpenAPI spec schema 'just as an extra'.
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.
REST API as a concept has been known for nearly 20 years. The GraphQL specification was publicly released 6 years ago. There are tons of frameworks out there which already contain support for REST API implementation, in a variety of languages, with all sorts of features and helpful things for developers to start using it out of the box. We have it so easy when a framework converts those HTTP requests to a standardized request / response format, with easily implementable middleware per route and all sorts of cool gadgets to make it even better.
GraphQL doesn't really have this kind of ecosystem. At least not yet in the open source world (I think?). Commercial solutions might have some since they're motivated by money to produce them.
If GraphQL solved some specific problem we have, since most of us don't work at the level that Facebook operates in, people would be all over it. I'd bet there'd be tons of libraries out there that allowed users to write GraphQL schemas with custom directives for queries, mutations and fields with little effort, and middleware/some other security mechanism to protect those. So far I've had to implement all of those by hand, because there's very little support for mechanisms like those in languages like PHP.
We used GraphQL on a front-end rewrite project and it didn't take long for five developers to learn how it work. It's not that hard. When you explain to them what the n+1 problem is and how you can solve it by deferring resolving to a later stage when you have all the necessary data to perform a batched query or something, it's relatively simple to use.
Unfortunately, who likes implementing that extra layer of complexity to a project without any significant performance increase (mobile devices?) when you're not Facebook? I personally like GraphQL, because it gives me type safety and a pre-defined schema for my API. That's quite good in languages like JavaScript or PHP. I don't really like writing an OpenAPI spec schema 'just as an extra'.