Ask HN: If GraphQL Is So Great, Why Doesn't Everyone Use It Already?
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? In my opinion, graphql is a good detector of companies that want to be "cool" and thinks that they do software well as they follow dogmatically things like clean code.
But that are not pragmatic and so they don't realize the bad side effects of it. Often early stage startups. Graphql is a typical example of something that is nice on paper but doesn't pass the reality check. It does, but only if you use it as intended, ie with Relay: https://alan.norbauer.com/articles/relay-style-graphql Otherwise, yes, it's not better than REST. Explain whether you're cynical on the frontend or backend "doesn't pass the reality check" Can you elaborate on that? We're thinking of migrating to it from plain REST. Don’t build a generic API for your specific interface. Unless you have hundreds or thousands of developers consuming an API endpoint, it’s generally better to build the API tailor specifically for each screen/ use cases/… you have. When thinking about API that way, the value of graphql is not that clear anymore I considered graphql recently and selected against it. I am not saying graphql is bad, but it was not as good for our situation. Graphql is really suited for aggregating disparate data sources and making them look unified. You dont need to use ot that way, but that is the main value prop. The downsides that killed it for us was that performance characteristics seemed less clear, and ever replacing it would be a nightmare due to its unstructured usage. Things that were simple in REST (like rate limiting, capacity planning, authorization) seemed more difficult, and we didn't need the killer feature of it. It is an interesting tech, but you are probably better off starting with REST and adopt gql on top afterward if you need it. Thanks. A lot of these things ring true in a very practical sense. GraphQL keeps getting more mature and adding more and more tooling/features/middleware, but we also need to work on de-risking the technology from a more fundamental perspective to get to a rock solid foundation. For example, one promoted advantage of graphql is to be able to be more efficient by only requesting fields that you really need. But the reality is that it is often more costly to parse exactly what the client want and have graphql retrieve the whole data and decimate just the needed fields. And you don't even save bandwidth because a lot of metadata had to be transferred to do that. In a similar way, you will do one request, and the graphql server will have to trigger n requests to internal services.
Then you have things like having to wait for the slower service to be able to reply and display anything to the user, also having to still send n internal requests even if one of the first and important one would fail, like retrieving an user account. It will be harder to cache responses if the response content is specific to each request. A lot of things like that, where, in the end, you see that it is a lot more easier and efficient to have the client do generic individual api requests. Why? Because REST works, and I just wanna get on with solving actual business problems that make money, NOT play around with GraphQL I 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. I actually don't use GraphQL in my current position, so I don't think to much about it any more. Intresting tools which I might consider in the future(If I have to write GraphQL). I don't want to use it, I don't need to use it, I don't consider it "great". Similar 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 When 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. I am curious how do you do performant joins between different REST APIs? How do you do it in graphql? You are going to hit multiple APIs that aren't integrated so it will be multiple requests. One request to a graphql server and multiple requests to other APIs isn't faster than doing just the requests to the different APIs. Actually it might be faster. GraphQL has its place, but IMHO it is at either side of the bell curve of project complexity. It will be great for trivial projects, and it can help simplify things in really complex large projects with multiple clients and services, but it just isn’t worth it for everything in between these two extremes. Significant engineering time will need to be spent ironing out important things that just work with REST (like caching). The best analogy I have for what working with GraphQL on the backend is like is the “If you give a mouse a cookie” story [1]. You try to set up an API but end up being asked to implement three different caching layers, using the data loader pattern to batch requests to the DB to improve performance, discovering that custom error handling code is needed to get non 200 status codes back from your API, using persisted queries now that your frontend is asking for a lot of data in the body of the request which is taking up too much bandwidth, etc… The code as you can imagine after doing all this is very hard to follow, even without doing any of the optimizations I listed above there are things like reference resolvers that make tracking down bugs or just finding where the data is being collected from a nightmare. [1]: https://en.m.wikipedia.org/wiki/If_You_Give_a_Mouse_a_Cookie > GraphQL has its place, but IMHO it is at either side of the bell curve of project complexity. It will be great for trivial projects, and it can help simplify things in really complex large projects with multiple clients and services, but it just isn’t worth it for everything in between these two extremes. I understand why GraphQL might make a lot of sense at a very large scale, but how does it add anything noticeably positive over REST to a trivial project to make up for the extra work? I don’t think it will add anything as compared to REST for trivial projects but it’s just easy to setup and get working A lot of people use GraphQL. Like everything else, there's pros and cons. If you've invested highly into a certain tool you're going to see all of the pains. Graphql offers benefits for a few types of architecture (typically microservices or when you are supporting multiple clients such as Android/iOS clients). If you don't have these, then Graphql primarily adds complexity As 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) The reasons mentioned above is exactly why we started Tailcall. https://github.com/tailcallhq/tailcall GraphQL community is quite small and fragmented. Mostly composed of frontend engineers who are focused on improving dev-ex with APIs. It would benefit the ecosystem, if people with a system's background or platform engineering background could get involved. Fix various aspects of performance, security and maintenance. There’s an inherent amount of complexity with two (or more) systems talking to each other over a network. You can shift the balance from one to the other, but it’s always there. GraphQL pushes complexity into the backend where it’s arguably easier to manage, in return the frontend can have more flexibility and autonomy as a client. REST pushes the complexity to the frontend requiring clients to orchestrate multiple calls, and reconcile the data models in the API to their own. GraphQL got a lot of early praise for having good tooling that can provided end-to-end type safety, autogenerated client and server frameworks, and so on. OpenAPI has more or less caught up on this front now. You can’t just take a REST api and convert it into a GraphQL api. Like going from dynamic to static types, with GraphQL it pays off to define your data model and reuse it throughout the API. I’ve seen simple things like using the same field name, or same set of fields for a given type get bikeshedded for months. You can get with this for REST APIs, but not GraphQL. I 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. GraphQL basically a layer that hides data federation from the client. Would this benefit encourage you to use GraphQL as your backend/data api layer? Usually it's forced on the backend by the frontend team. Really, it's just more awkward than writing a straight-ahead REST implementation. Also the error-handling semantics gets pushed to the backend, and the frontend team (who generally doesn't like handling errors) doesn't really know what to do with errors in general...so the UI design team needs to add that sort of error handling to the UI which makes everyone confused because usually there's nothing you can do about errors on the client side. The error handling issue can be seen with this simple example: you federate 10 API calls, and 9 of them work fine. Do you return partial data? How do you indicate to the front end that there's partial data? What if the data in the 10th call is the one they need in the UI? This implies that you need yet another state indicator that says "part of the data was returned" (if the destination was a field)...which is different than "that field was empty." And that's at a minimum. GraphQL is great if you're a frontend developer. REST is great if you're a backend or infra developer (not because of complexity of developing it, because of complexity of using it) You cannot satisfy both with one tool. Migrating to GraphQL (or choosing it in the first place) will frustrate consumers of it who primarily use your API for things other than writing frontend clients. Using REST will frustrate people who use your API to write frontend clients. GraphQL is great for both. It's a collaboration tool between front and backend. You can design the schema for the resolvers during the RFC phase of planning a new feature, and then both teams can implement their tasks in parallel. And you can use the spec to generate type safe libraries on each side. We did this with Strawberry in Python for backend (which uses dataclasses for defining resolvers), and TypeScript + graphql-codegen on the frontend. We have fully automated type generation from the backend to the frontend, meaning GraphQL becomes a cross-language, shared type layer. It works great, once you get everything setup. Worth the effort IMO. > REST is great if you're a backend or infra developer Not sure about that, we have a codebase that's huge, with 100s of REST endpoints, and the backend engineers simply start writing new endpoints because frontend needs one more specific field, and the backend folks can't be bothered to refactor the codebase for an endpoint that's used elsewhere, as that takes time. GraphQL solves that cleanly by allowing the frontend to request any data they want and for the backend to focus on figuring out how to give back a piece of data if it's requested. No 100s of endpoints required. The only reason GraphQL is "better" is it forces documentation. The fact is, you still need those endpoints, it's just your developers aren't afraid to change the GraphQL endpoints because they're documented. Sometime down the line your developers will become afraid to change the GQL endpoints and you'll have the same, but different, issue. Not sure this always happens in practice. I’ve seen lots of redundant resolvers being implemented for the same type at work because someone didn’t know one already existed. Because it's complex and daunting in implementation. REST is conceptually simple. Don't make me think. Also tRPC rules. incumbent effect. I think its great, but its not that much better than what exists I wrote another comment the other day (https://news.ycombinator.com/item?id=37125685) about how GraphQL has true typing unlike bolted on solutions to REST, and that most people use GraphQL incorrectly then complain about how they're running into problems with N+1 and all that. Basically, the way Facebook originally designed it was in combination with Relay and its graph query optimizing compiler that can stitch your entire app's query data together so that you never over- or under-fetch, at all. If you just use it like REST, you're gonna have a bad time. The comment: GraphQL is very useful, it removes whole classes of bugs. You can even use a Result/Either type where if you don't handle both the success and error cases, the GraphQL request won't even compile, so you can get type safety at both the client and the server while also not having to use purely TypeScript like with tRPC, allowing multiple clients like mobile and web. Pothos does this very well as an error extension [1], where, given the schema: I should also add that most people use GraphQL incorrectly, to get the benefits of not over/underfetching, the Relay approach using fragments is the only viable way currently. Otherwise it's not too much better than REST. You define the exact data required for a specific React component in GraphQL fragments, then the Relay compiler will stitch those fragments together into one and only one request. This is a great (if long) overview on the problems Relay solves and why everyone else uses GraphQL incorrectly (then complain that GraphQL sucks) [2]. Hint, Apollo is not the way. [0] https://www.youtube.com/watch?v=yab6i9lrEv0
you can then query it with type Error {
message: String!
}
type Query {
hello(name: String!): QueryHelloResult
}
union QueryHelloResult = Error | QueryHelloSuccess
type QueryHelloSuccess {
data: String!
}
If you forget `... on Error` the query will simply fail. query {
hello(name: "World") {
__typename
... on Error {
message
}
... on QueryHelloSuccess {
data
}
}
}