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.
“ 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
GraphQL is one, Redux is another.
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.
[0] https://hasura.io/events/hasura-con-2021/speakers/peter-down...
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.
Because it is :')
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.
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.
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.
There's a lot about graphql that is really cool. It just seems like the way my company uses it is to cut corners.
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.
Joking aside, I'm sorry that happened to you and I'm sorry for the people that took over the system I helped to write.
Did Akka; thank goodness that didn't make it to production.
GraphQL: Helped in many ways. Hurt in so many too. In production.
Everything in Actors: State was everywhere. So much pain. In production.
I just use Postgres + RPCs for everything now.
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.
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 don't know about on-HackerNews but there's a discussion about their "all of Facebook optimizing compiler" infrastructure from when they did the site redesign in 2020: https://engineering.fb.com/2020/05/08/web/facebook-redesign/...
> 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).
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.
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.
https://www.edgedb.com/blog/edgedb-5-introducing-passwordles...
Worked pretty well. Definitely something that could be make to. Kind of graphql themed but how it translates to REST can be explicit.
Like a stored function in postgresql?
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.
Use of persisted queries also addresses the article’s concerns about DDOS.
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.
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.
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.
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
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.
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.
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)
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.
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.
With GraphQL you can just do the exact same thing? I do this all the time. I don't understand how you wouldn't be able to do that.
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.
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.
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.
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.
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`...
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.
"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.
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.
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?
That simultaneously makes marketing value and drives a lot of silly decisions. Not much to be done though, humans are human
To be fair, it's hard to understand when virtually everyone using this term is using it wrong.
https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...
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.
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.
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.