I bought into the hype and I feel bad for the company where I implemented it. One true endpoint to rule them all and cause endless headaches in the process.
With most tech that I screw up I assume that "I wasn't using it right" but with GraphQL I'm not sure how anyone could. The permissions/auth aspect alone is a nightmare. Couple that with potential performance issues (N+1 or just massive amounts of data) and I want nothing to do with GraphQL anymore. Everything we attempted to fix our permissions issues just caused more problems. It would break existing queries and debugging GraphQL sucked so much.
If you only live on the frontend and someone else is responsible for the backend GraphQL then I understand why you might like it. From that perspective it's amazing, you can get as little or as much as you want with the specific fields you want. No waiting on the backend team to write an endpoint. However even then you end up saving queries as files or abstracting them (maybe IDE support has improved but it wasn't great last time I was using it ~5 years ago) and now you just have REST endpoints by another name.
At one point we considered whitelisting specific queries and that's when I knew we had gone too far and made a mess for ourselves. If we had taken the time to just write REST endpoints instead we would have gotten way more done and had way fewer grey hairs.
GraphQL absolutely feels like a technological solution to an organizational problem. What if your front-end team wants to write crazy queries and your back-end team wants to build their resume doing Real Engineering, but what you actually need is just a CRUD app?
Now your backend devs aren't bored writing "business logic" and your front end devs aren't bored waiting for your backend devs. You have a new class of inscrutable errors and performance issues, but that's why you pay your backend devs the big bucks! Because some guys from a technical college couldn't possibly solve your issue, you need to pay 250k to people who went to Stanford or Berkeley.
Ha, I gave this exact speech at the 2021 Hasura Conference [0]. You hit the nail on the head.
Sometime in 2022 we switched back to REST endpoints for all of the reasons listed in the OP's article. Didn't hurt that we had hired for more fullstack engineers rather than "frontend only", so they saw exactly why we wanted to make the switch.
EDIT: to be fair, using Graphql and Hasura absolutely did help us iterate more quickly early on. But once we had a firmer idea of what we wanted to build, switching to REST was the right call. One of our most talented engineers wrote some helpers to make sure the frontend types were synced up with the backend types and that pretty much replaced the main benefit of using Graphql.
Things will be very interesting if we treat each single rest endpoint as a GQL query.
With static typing definition and OPENAPI, we can declare the response type first, and then borrow the concepts of resolver and dataloder to easily construct the response we want.
Using resolver and dataloader can iterate as fast as GQL, and after the requirement is stable, we can refactor each single endpoint on demand.
for FastAPI user, pydantic-resolve is developed for this purpose.
“ Any organization that designs a system will inevitably produce a design that mirrors the organization's communication structure. “
Your point about Resumé Driven Development, together with the dividing wall between front and backends is why FE frameworks have got so hideously and needlessly complex imo
In other words...Once in a while a new generation of software developers champions frameworks that not only repeat historical mistakes, but also systematically dismiss the proven wisdom of older developers. Must be that experience ages out like old code...
The past few years I've been a 'full-stack' engineer - which is code for a backend guy who knows frontend.
In my personal taxonomy, a frontend developer is someone who cares a lot about UX, and making things look pretty, who also writes code.
I've met a lot of these people and they were more than happy to hand over all the infrastructure plumbing side of frontend apps to me - which I did along whatever REST API needed implementing on the server.
This was my experience. We were forced to use it in a project where we controlled the entire stack. It was so much extract work just to serve data from a backend we had full control over. I don't dislike it but I feel like it's far more of a time-and-place technology than most that people just default to using in any old situation. I'm sure some have used it successfully in a similar scenario—we certainly weren't exactly super knowledgable about it when we were told to use it. We tried, though!
Why does Facebook keep pumping out 21st century moral equivalents of UML and OOP design patterns - trendy technological ideas that are often considered the gateway to writing 'professional' code, but end up being overengineered boilerplate nobody actually needs.
GraphQL makes sense in the narrow context of "you have a high latency end-user and you're pulling in deeply nested social graph data". It didn't need to be a general purpose framework, but you don't get to start your own company and talk at conventions about the clever API design you did at Facebook for Facebook-only problems. The incentives are for (a certain type of) developers to act like this solution is a panacea and sell it as a revolutionary new architecture.
There’s definitely a pattern here that I think gets promulgated by hyperscalers and major vendors. Even if not intentionally, but as a byproduct of engineering blogs and marketing meets well intentioned developers.
A good friend of mine is a solid developer generally, but he only works in AWS and while he leads a technical team, he doesn’t seem to have any idea what things actually cost in AWS.
He also seems somewhat susceptible to the hype trains that get started by AWS and customers of a much larger scale than his employer. He builds in the name of scalability but in ways that don’t necessarily address future organizational needs. I’ve seen this impact his work in ways that it isn’t my place to directly address, but that I know will come back to haunt his employer.
By way of example, he has built the service his current employer provides around the idea that each customer gets a different tenant that isn’t connected to any other tenant, and there is no ability even from their control plane to transfer data between tenants. His thinking was based on the idea from a prior employer where enterprise customers got their services managed in a customer specific AWS account managed by the company: total isolation. That made a lot of sense at his last two employers, but for the industry in which his current employer operates it is an anti-pattern. To draw an analogy, it would be like building an EMR that doesn’t have the ability to output patient records in a manner that another EMR could ingest. In his industry this sort of portability of end user data for his employer’s customers is both customary and expected.
This means his company has to build some kind of abstracting service that can enumerate and communicate across all customer tenants to shuffle data around or export it. It isn’t a capability anticipated in the architecture, but it’s a basic need.
Down-thread there is a reference to Conway’s Law. You can argue this kind of thing is a manifestation of that concept. My friend has never worked in this specific industry before, and so he just doesn’t understand their needs. He talks about it in purely AWS Well Architected terms and designs based solely on that for everything. That may be his job to an extent, but I think the broader problem is that no one in his company clearly communicated to him predictable end user expectations that impact architectural design.
> To draw an analogy, it would be like building an EMR that doesn’t have the ability to output patient records in a manner that another EMR could ingest. In his industry this sort of portability of end user data for his employer’s customers is both customary and expected.
That's not necessarily contradicting the design to me. I don't know AWS but I assume you still can move data between tenants, only through some export/import system. And there may be a good a reason for it. Like you need an import/export system anyway because your tenants need it for data exchange with "tenants" that are not your customers. So you can still have both. Another reason may be a need for auditing the data movements between those tenants.
One of the things that really burned me out over the years is how many times I would say something to the effect of "Maybe using GraphQL is over complicating the process and we should just use the old tried and true methods" and I would get drowned out by everyone chasing the latest thing or derided for not wanting to try something new.
"Maybe implementing CORBA for message passing is over complicating it."
"Maybe using OOP and facade classes is over complicating it."
"Maybe using XML to store all the config information is over complicating it."
"Maybe using this ORM with a strange file based caching mechanism is over complicating it."
And always get drowned out by everyone going with the trend.
It isn't specific to software either. The root cause seems to be a large number of people who don't understand either the basic technique (like rest) or the alternate technique (like GraphQL) and so make the choice based on what the majority of people are talking about right now. They won't listen to you, because there is one of you and usually 5-10 people talking about the latest big thing. They make the decision using that literal metric.
That simultaneously makes marketing value and drives a lot of silly decisions. Not much to be done though, humans are human
I spend loads of time on LoB apps, still rocking Apache prefork to CGI. Does it scale? Sure, to all 3200 users company wide. Everything it's boring. Caching? Never got in the Memcache vs Redis fight later. 10yr after that? We picked Redis for the case where it had proven to kick ass.
Did you know that PHP5.4 apps can still generate profit in 2024?
For a long piece that doesn’t once mention Erlang or Elixir, it’s the strongest argument for using them I’ve read.
You could literally replace every part of any of the stacks he mentioned with Erlang. Python/PHP, cron, memcache, even the databases in the extreme case. It’s an older tech, too, so in his model this amounts to spending m zero innovation tokens for the entire stack.
"Maybe using a general-purpose programming language instead of just SQL is overcomplicating it," said I every day of my life for the past 25 years. Oh well. You can't fight City Hall.
This is an eternal struggle for either senior or self-assured developers, convincing others to rein in their enthusiasm / hype. Plus, extroverts (loudmouths) vs introverts (who are correct, but refuse to play the extrovert's game).
I had an eerily similar experience with GraphQL where by the end of "productionizing" the backend to support the client load, were using whatever their equivalent of cached/persisted queries is called (sorry I can't recall their terms for this). We had ultimately come full circle to something that was harder to use than a REST API but also more complicated at every layer.
My biggest problem is that it seems like nobody understands the data or where the data is coming from. You can have the same variable names and mostly even the same values under different levels of the graph. Now someone has to figure out what system is feeding that info to GraphQl to figure out which level we should use. I don't see this as a real GraphQl problem, but more so a problem with the process discouraging detailed knowledge and documentation.
You can write shit in any framework or language though. That's why I always found Typescript such a boon; it provides a way to box people in to use code/framework how it was designed to be used.
It's definitely possible to write shit in anything. It just seems that writing something more structured, like SQL stored procs and a REST endpoint, means someone had to actually think about what data is coming back, it's structure, and how it's being used and the dev generally had better insight as to where the data was coming from and what values to expect.
There's a lot about graphql that is really cool. It just seems like the way my company uses it is to cut corners.
The same structure thinking etc can and should be done for GQL as well. But same same, once you have project handoff some other team can pick up your nice rest api and not follow existing conventions at all. I've seen far too many rest apis that will do all these variations across the one API: delete /user/comment, post /user/comment?action=delete, post /deleteUserComment, etc.
I'd agree that GQL is definitely one of those "gets used because it was the cool thing at the time" technologies but I still think it has a place in our toolboxes, it's definitely not the right solution for every problem.
Yeah, I love my TypeScript serverless backend project and my successful DynamoDB project but often I think I could have saved a lot of pain by using PHP and/or Postgres.
I dunno, I still quite like GraphQL, but as with all technologies it can be misused; a lot of the schemas I've seen are pretty poorly written, but the spec certainly doesn't make it easy with design choices like: no type inheritance, fields are optional by default (causing huge annoying problems with GQL->TS). Adding a few linting rules helps as well.
The problem I always had with rest was that nobody really follows any patterns, not in the same company, not in the same project. There are a million different decisions you can make with rest and if you let a dev alone to build it themselves you're gonna get yet another variation, whereas GQL is only implemented according to a spec.
The N + 1 problems are pretty much fixed these days & mostly any dev can build something in themselves to fix it if they want to. Permissions/auth is relatively easily achieved with middleware and directives, though it's also totally possible to roll your own by writing something that inspects the querys AST if you really need to have your auth layer separate to your schema.
Can you give an example for the permission issues that you had with GQL and would've been easier in REST? Genuinely curious, as I'm implementing a GQL backend with simple permission handling and haven't run into anything yet, but I wanna know what could await me
With REST I can fairly easily filter out any data based on roles/permissions either at query time or before turning it into JSON. With GraphQL I need that info deep in the resolver logic and for nested data I don't want to fetch the name of a person if they calling user doesn't even have access to see that user (and I don't want to fetch the user and their name only to delete it from the response later). GraphQL, being so open-ended to what you are fetching, means I have to make sure to plug a ton of holes whereas REST I have a specific query, there is no way to fetch nested data (unless I specifically allow it via GET/POST params). I can easily say "If role X -> use this query, if role Y -> use this query, etc", I found that very difficult to do in GraphQL.
GraphQL feels like magic when you first start with it (which should be a red flag) but once you need to support more roles or sets of permissions and as your business logic starts to creep in things go haywire. In my experience things that are easy up front are unmanageable once business logic gets added in. For straight CRUD it's amazing but very rarely do our apps stay as just CRUD and that's when things fall down. For example, on create of a new user I need to send a welcome email. It's been 5 years since I was working on that GraphQL project but I have no clue how we'd handle that. I'm sure there is some kind of a event system we could hook into but with REST I just have a simple endpoint that saves the data to the DB and then sends and email (or puts it in a queue), way easier than in GraphQL. Again, fetching and updating data is easy until you need to handle edge cases. I have the same feelings about Firebase and friends. Feels like magic at the start but falls down quick and/or becomes way too complicated. GraphQL feels like DRY run amuck, "I have to keep writing CRUD, let me abstract that away", ok but now if you need special logic for certain use-cases you have a mess on your hands. Maybe GraphQL has ways to solve it but I'll bet my hat that it's overly complicated and hard to follow, like most of GraphQL once you get past the surface.
I'd love to see a "Pet Store" (I think that's the common example I've seen demo'd in REST/Swagger/GraphQL/etc) example with heavy restrictions based on different users/roles. It's like using the "Todo app" example in a framework, sure that works and is straight forward, I want to see how you handle the hard stuff and if it's still easy.
Let's say you add a user object to your graphql. It's only so the viewer can inspect themselves (i.e. the current authenticated user). Maybe this is for a settings page or something.
A while later, suppose someone adds some connection from user to, say, orders. The person who added orders to users was kinda lazy and assumed (somewhat correctly, at that moment anyway) that permissions weren't an issue. So there's no additional permission checking when fetching the orders connection.
Now, suppose 6 months pass. Some other engineer is now implementing reviews. Each review must have an author. What do ya know, there's already a user object available in Graphql. How convenient!
Now every user can inspect all orders of every other user, if that user has left a review.
Mistakes like this are all too easy with graphql, and is the number one reason I would never consider using graphql without a query whitelist.
I am just pointing out that it is easy to make mistakes like this which would be, in this commenters experience, more obvious with a REST API.
In the equivalent REST API you would probably have to go far far out of your way to expose users order information in a reviews API, whereas in graphql that is the default.
In a typical REST application, it is enough to ask "does this user have permission to take this action".
In graphql, the question is rather different. It is "does this user have permission to access this data irrespective of the action they are taking", and you have to both ask that question and answer it correctly for everything in your graph.
If you go back to the early stuff coming out of Facebook about GraphQL, it was designed to roll up all the REST services (or similar) into a single request for high latency clients. Occupying what has become known as the backends for frontends (BFF) layer.
In theory, it should be just as obvious either way as your actual services are going to be REST (or similar) either way. I recognize that some people have started using it as a poor man's SQL, but that's not really what it is for.
In the wild, I primarily have seen graphql implemented instead of, or perhaps next to, REST. Not on top of REST.
I'm not sure what you mean about a poor man's SQL. Whether it's backed by micro-services via REST, or just a graphql API in a single app, the value prop for frontend<>backend communication is the same. It's not "using graphql wrong" to not have a micro service architecture.
>Now every user can inspect all orders of every other user, if that user has left a review.
Lmao that's just bad development, bad testing and the exact same thing can happen when using rest. "The dev wrote code and forgot to take permissions into account" happens to everyone.
And unlike rest, a properly written schema helps ensure they mostly do the right thing - even without strict permissions check, it should be obvious to anybody that they can't just write an `orders` resolver that does a `select * from orders`...
In practice, there are innumerable paths one can take through a complicated graph, and it is not reasonable or possible to test them all.
The cure is, like you say, writing a proper resolver. This form of permissions error most frequently happens when there is not a dedicated resolver (graphql-ruby, for example, makes it trivial to make a connection without a dedicated resolver).
I don't think this is as easy of a mistake to make with a typical REST application. In no normal universe would you return orders data in a reviews API, and the mistake would be much more obvious during development since you don't have to explicitly select the data you fetch from a rest API (so you are more likely to notice the extra information).
Whereas during development in graphql, the permissions error would be hidden because you probably would not select extra data for no reason.
I think a lot of people like GraphQL because it provides strongly typed API interfaces. But I've been able to hack together a better REST alternative in full-stack typescript codebases. And my solution doesn't need to compile any kind of client or intermediary.
GraphQL gives you the ability to compose fragments, so if the UserDetail component and UserPaymentInfo component both use the user’s name, it is loaded once.
With ad hoc solutions like tRPC, you end up fetching the same field multiple times (and probably doing some sort of network waterfall), or you give up on data masking and composability. And if you have enough engineers, data masking and composability are critical to maintain velocity.
I'm not sure I follow. Are you saying swr allows for fragments and deduplication?
If you don't have fragments (in particular, if you have a single call to an swr hook at the root), then you have implicit deduplication. But then you run into the issue of it being unclear whether you can remove a given field when a subcomponent stops using it — you have to check whether any other subcomponent happens to use that.
And if you have many separate queries, you're architecting in waterfalls. But you have clarity about who uses which field.
How many underlying services and clients was the GQL layer catering to? How many different digital products and independent teams? You referred to "the backend team" (one) and did not mention stitching/federation. This makes it likely that you were using GraphQL to address a set of needs that may not be aligned with the goals of GraphQL. Just like the author of the article - it sounds to me like he probably has been working in contexts where he would not have been able to see the org/collab/infra benefits of GraphQL. Much like the case with microservices. Enterprise tech/arch solve more than just technical problems.
Whitelisting the queries that clients can use in prod actually doesn't seem like a bad option to avoid a lot of these security issues, assuming you control the clients
This solution works very well, and I’m surprised that others on this thread do not take advantage of persisted queries. Yes, it’s recreating REST, except that you don’t need to version endpoints, etc. The source of truth is the front end repo. That’s the point!
Use of persisted queries also addresses the article’s concerns about DDOS.
I don't understand this argument, how is it "remade REST" if you still don't need to implement and maintain an endpoint with exactly the data that clients need? Persisted/whitelisted queries require much less backend effort, and are decidedly different from REST, the only similarity is in having a closed set of possible actions.
Perhaps you're thinking in terms of public APIs where I agree limiting available GraphQL queries makes little sense. But for internal APIs, whitelisting whatever queries current clients need isn't any less convenient
I might be thinking about this the wrong way, but with GraphQL you're writing a query (in the GraphQL syntax) on the frontend which gets whatever data the frontend needs for whatever it's doing, and that query is interpreted by the backend to fetch specific data. But if you're whitelisting specific queries, which has to be done on the backend, what if you just move the queries themselves to the backend, and call them from the frontend by specific names for shorthand? And then from there, what if you refactored it so that each "query" was just a function with an associated endpoint?
You would have a more permissive development environment where all queries are permitted. Then, once the change to FE code and related queries are finalized, you could automatically have the production whitelist updated before the FE is deployed to prod.
Not really. The usual strategy for persisted query is to only use them in production or adjacent areas. You build your app using regular graphql doing whatever you need, then after you tested things and it all looks good, when you ship, you parse the codebase, store the queries, and ship them.
It doesn't work if you don't have control over the client (eg: exposing to third parties), in which case query complexity limits are easy to implement and do the job, too.
I’ve only been a consumer of a GraphQL API, so I don’t know what it’s like to maintain, but I mostly enjoyed using it.
Of course the documentation on some kinds of query syntax was too sparse, (this is for Shopify) but I could see how it might be nice for certain kinds of cases. If you run a platform it might be a good option to offer in your API. For shopify afaik there are equivalent calls in both REST and graphql so you have options.
Can you elaborate on lack of syntax docs? As far as I understand one of the big big huugge benefits of GraphQL is that you get the strongly typed schema via the introspection query, so you can build queries with some confidence, that as long as the schema (version) is the same it should be syntactically okay. What did Spotify do compared to this?
I think it wasn't just the schema structure, it was the API abstractions implemented in the schema.
If I remember correctly it was something about Shopify discounts, which can be applied multiple times and across different modalities- percent, dollar amount, etc. and what those were called in the API, and how they were represented and to which object they were applied to.
Then once I had figured that out, then understanding how to construct the query.
But of course my problem was more from the point of view of, "I just want to get x done". As the consumer of the API I wasn't as concerned about fully understanding the entire set of abstractions and schemas.
This is one of the problems with graphql, there are no docs because the schema is all you need. But that assumes the schema is logical and consistent, which it rarely is.
It also means you need to be an expert in the tooling to figure it out, so just dropping in to a graphql api is so frustrating compared to plain old rest
Also there is no standard for exposing the schema, and sometimes there isn't a schema at all. Sometimes a vendor will have the schema downloadable from their dev docs, sometimes it will be an endpoint that serves it up, and sometimes they just don't give it to you and expect you to use GraphQL Explorer directly to discover what you can do. When I encountered this I figured surely GraphQL Explorer must be fetching the schema, but I guess this is not always the case, as I never was able to get a complete schema that worked with the tooling. For that vendor, there was no way to generate client code for the schema using one of the many GraphQL client library generator frameworks.
I'm not saying the service isn't a true Scotsman, but a service that calls its API "GraphQL" but doesn't respond to introspection queries isn't really serving GraphQL.
This was also my issue with APIPlatform (php/symfony ecosystem tool to generate REST endpoints for your Doctrine entities). Nice OpenAPI spec autogenerated at first glance but very sterile and hard to use once you really needed to understand the business reasons behind some normalization choices.
this was also the problem with WSDL and REST itself, and so on. of course there are things that make sense to be in-band .. but there are things that have to be communicated out-of-band (just as REST doesn't say anything about what to do with a specific content type OpenAPI and GraphQL doesn't worth much with empty description fields, though I'd argue still much better than getting a .doc file named API_doc-Finalv2(1) :) )
> equivalent calls in both REST and graphql so you have options.
It's not that simple, new features are add to GraphQL only, some other things are REST only,some APIs work differently (like product search by title, in REST it have to be an exact match, in GQL it can be partial match)
This has been my experience when integrating with a vendor's APIs where they've been bit by the GraphQL bug. They have a full featured, stable and easy to use REST API, and then a poorly implemented GraphQL solution that doesn't cover all the use cases of the original API, and new features only appear in the GraphQL schema, so you have to be stuck using both and it's a horrible experience.
I'm also not personally a fan of having my API queries on the frontend span multiple lines for things that with a good REST design with OpenAPI are a single method call, but all too often the calls I would need to make to the vendor's GraphQL API were exactly this: did not make use of any of GraphQL's query features, and were effectively just RPC calls.
Last place I built a complex REST app, I solved this by auto-generating a set of standard endpoints from the database schema, and then adding a UI where a small set of trusted users could write queries that'd be stored in a table that were then made available.
It provided an escape hatch that allowed rapid prototyping, and came with a default UI, and then we cleaned up the ones that were worth it.
Hmm. I wonder if there is some kind of query builder that can live server-side. That is, capture the flexibility of a query language when developing, and then consolidating that when going into production.
Though I guess you can do that with REST too.
I'm currently exploring all of this myself. I have a side project in mind that can use a graph db, and I thought a front-end graphql can work well with a graphdb backend. I was not sure why this pattern is not more popular, but reading all of this now, I'm seeing where these problems may arise.
A graph db backend can use efficient graph search algorithms, especially for deeply nested data, but the issue with authorization is still there. If anything, fine-grained authorization is something better represented with graph dbs than with relational databases.
This is a vague recollection, but I seem to recall Meta/Facebook engineers on HN having said they have a tool that allows engineers to author SQL or ORM-like queries on the frontend and close to where the data is used, but a compiler or post-processor turns that into an endpoint. The bundled frontend code is never given an open-ended SQL or GraphQL interface.
And perhaps not coincidentally, React introduced "server actions" as a mechanism that is very similar to that. Engineers can author what looks, ostensibly, like frontend code, merely splitting the "client" side and "server" side into separate annotated functions, and the React bundler splits those into client code, a server API handler, and transforms the client function call into the annotated server function into an HTTP API call.
Having used it for a bit it's really nice, and it doesn't result in yielding so much control to a very complex technology stack (GraphQL batchers, resolvers, etc. etc.)
> I seem to recall Meta/Facebook engineers on HN having said they have a tool that allows engineers to author SQL or ORM-like queries on the frontend and close to where the data is used, but a compiler or post-processor turns that into an endpoint.
> perhaps not coincidentally, React introduced "server actions" as a mechanism that is very similar to [the above]
Yep - there's also the Scala framework LiftWeb (https://www.liftweb.net/), the Elixir framework Phoenix (https://www.phoenixframework.org/) and of course the system we're using right now (Arc) that do similar things. Scaling these kinds of UUID-addressed-closures is harder (because the client sessions have to be sticky unless you can serialize closures and send them across the network between servers).
Code generation is very common at Meta. One just needs to create a query or fragment. A fragment can be spread at the root query level using relay so it will do the fetch once. It gets more complex because you can lazily query more data based on parameters you pass into GQL. It feels like magic and is really annoying imo.
> Hmm. I wonder if there is some kind of query builder that can live server-side. That is, capture the flexibility of a query language when developing, and then consolidating that when going into production.
I think this is what a lot of people end up doing (and yes, with REST). Translating options via query params / POST body into a query. In theory GraphQL was supposed to mitigate this DSL-like translation, but the thing is people like flexibility and ability to change and, yes, break backwards compatibility. That's also why a lot of people end up with a translation layer with things like RPC, which is itself supposed to be a direct, shared communication protocol.
The messiness of APIs is often a feature, at least internally. These approaches that attempt to avoid the mess are better for the end consumer but cause friction within development groups and the benefits are often obscured.
Assuming the query language for the graph DB you have in mind is declarative like SQL, I recommend templated queries. I have found this technique scales pretty well for query complexity, makes it relatively trivial to "get to the query" if something needs to be debugged in the details more easily outside of the app, and it makes performance-oriented optimization work far easier.
I've had my share of headaches with the various flavors of ORM and GraphQL and always come back to query templates, e.g. MyBatis in the JVM ecosystem or Go's template package. There is still value in abstracting this from the REST web service interface to make it possible to change the app<->database connection without disrupting REST clients. It's possible to reuse parameter structs/classes between the REST client and DB+template client layers to avoid a lot of rote translation. It seems simple and repetitive, but actually saves time compared to the GraphQL/ORM complexity as apps & query complexity scale, in my experience.
> Hmm. I wonder if there is some kind of query builder that can live server-side. That is, capture the flexibility of a query language when developing, and then consolidating that when going into production.
Back when GraphQL started being around, I prototyped a proxy server that accepted a JSON dsl to resolve a series of calls to a backend JSON/REST API, so that the chain of calls would be batched up closer to the server.
Worked pretty well. Definitely something that could be make to. Kind of graphql themed but how it translates to REST can be explicit.
How does an engineer buy into hype? Ur supposed to be analytical. Everytime some new frontend bs like tailwind comes out I roll my eyes. People want to be famous not practical. React is only popular because of Facebook and react native. It's a shit ecosystem and frontend tool set. Webpages are slow due to bloat not shadow dom.
With most tech that I screw up I assume that "I wasn't using it right" but with GraphQL I'm not sure how anyone could. The permissions/auth aspect alone is a nightmare. Couple that with potential performance issues (N+1 or just massive amounts of data) and I want nothing to do with GraphQL anymore. Everything we attempted to fix our permissions issues just caused more problems. It would break existing queries and debugging GraphQL sucked so much.
If you only live on the frontend and someone else is responsible for the backend GraphQL then I understand why you might like it. From that perspective it's amazing, you can get as little or as much as you want with the specific fields you want. No waiting on the backend team to write an endpoint. However even then you end up saving queries as files or abstracting them (maybe IDE support has improved but it wasn't great last time I was using it ~5 years ago) and now you just have REST endpoints by another name.
At one point we considered whitelisting specific queries and that's when I knew we had gone too far and made a mess for ourselves. If we had taken the time to just write REST endpoints instead we would have gotten way more done and had way fewer grey hairs.