Recent popular posts got me thinking about common complaints about GraphQL and how they're often complaints about a particular implementation.
Performance, security, actually building a GraphQL server. What else have you encountered?
Ask HN: If GraphQL Is So Great, Why Doesn't Everyone Use It Already?
1–10 of 41 posts
Re: Ask HN: If GraphQL Is So Great, Why Doesn't Everyone Use It Already?
#2[deleted]
Re: Ask HN: If GraphQL Is So Great, Why Doesn't Everyone Use It Already?
#3I don't want to use it, I don't need to use it, I don't consider it "great".
Re: Ask HN: If GraphQL Is So Great, Why Doesn't Everyone Use It Already?
#4I was fairly sure we all are :) It’s seemingly found its part in the common web devs toolbelt. Perhaps not universally adopted, I believe it’s still regularly applied to systems with non-trivially large clients/fe-apps.
Re: Ask HN: If GraphQL Is So Great, Why Doesn't Everyone Use It Already?
#5Similar vibes to "if JSON is so great, why haven't SAP and Salesforce rewritten their SOAP APIs?"
Huge companies are slow to adopt things. All the smaller companies I've worked for used GraphQL, but even then I didn't see the benefit over a regular REST-like API.
Re: Ask HN: If GraphQL Is So Great, Why Doesn't Everyone Use It Already?
#6Similar vibes to "if JSON is so great, why haven't SAP and Salesforce rewritten their SOAP APIs?" Huge companies are slow to adopt things. All the smaller companies I've worked for used GraphQL, but even then I didn't see the benefit over a regular REST-like API.
FWIW, Salesforce actually did make a GraphQL API: https://developer.salesforce.com/docs/platform/graphql/overv...
If you're a small company where the FE and BE can work together to make the REST API function exactly how you want, it's not really a big deal. But in B2C or B2B situations where the API provider isn't working alongside the end-users, GraphQL gives the consumers WAY more freedom to choose what they want to fetch -- and no more. That query language is amazing for that use case.
I've used it to work with the Nvidia GeForce Now API, for example, which has thousands of games and dozens of parameters (which store do you want it from, whether you want images, titles, how you want it sorted and filtered, whatever). I wanted a list of all game IDs on Steam, and that is a single query in GraphQL rather than several blocks of back-and-forth REST queries plus more client-side filtering. https://ighor.medium.com/i-unlocked-nvidia-geforce-now-and-s...
Similarly, with headless CMSes like DatoCMS or Hygraph, it gives you a central place to put all your content but then consume it however you like across different frontends (web, native, syndication, whatever) with powerful and customized queries. https://www.datocms.com/docs/content-delivery-api/filtering-... https://hygraph.com/docs/api-reference/content-api/filtering
Re: Ask HN: If GraphQL Is So Great, Why Doesn't Everyone Use It Already?
#7As a frontend person, the most common reason I've heard from the backend folks for not implementing is simply a lack of familiarity plus high difficulty, especially people who are used to existing AWS REST patterns and services. I heard from several people that making the stack for it on the backend is a pain compared to traditional REST, and every time I've brought it up, they decided it was too much work. (I took their word for it)
Re: Ask HN: If GraphQL Is So Great, Why Doesn't Everyone Use It Already?
#8When you have performance issues with hand crafted REST API's, a GraphQL enabled set of API's feels like it could be a lot worse. Huge volumes of data for tables don't blend well with a mix-n-match way of joining things.
Re: Ask HN: If GraphQL Is So Great, Why Doesn't Everyone Use It Already?
#9I find it to be more complex(Hence more error prone), less performant, harder to resolve bugs.
For a queries and mutations you still need to write business-logic and database access which is very similar to how you would develop a REST-API.
Re: Ask HN: If GraphQL Is So Great, Why Doesn't Everyone Use It Already?
#10I find it to be more complex(Hence more error prone), less performant, harder to resolve bugs. For a queries and mutations you still need to write business-logic and database access which is very similar to how you would develop a REST-API.
On the performance side, there is definitely the N+1 problem which is solved (partially) by the data loader pattern.
But curious if the benefits vs tradeoffs is in favour of GraphQL?
And have you considered tools like Hasura/Postgraphile that take care of boilerplate CRUD APIs for databases? Then you actually just focus on writing business logic.