https://news.ycombinator.com/item?id=40536581

Has anyone experienced something similar with typedb? It feels a little too good to be true. Make it seems like graphql and nosql trauma.

https://blog.tailcall.run/writing-a-graphql-backend-by-hand-...

GraphQL makes sense only at a certain scale when you have multiple APIs built by multiple teams that need to be exposed as a single endpoint. GraphQL as an API or APIs is the perfect use case and the one that it was designed for.

In every other case, REST is harder to do wrong and easier to do right. The tooling for it is widely supported and well known. Every aspect of building an easy to use, easy to own, easy to scale API is -- well -- just easier with REST.

I have seen more than a few small, 4-8 person engineering teams reach for GraphQL and then wonder why every cycle starts feeling slow. In a 4-8 person team, the devs are usually working full stack and if not, then they are working closely enough that having a highly flexible API layer servicing the front-end doesn't make any sense since it's either the same devs or they're one Slack ping away from getting the right shape from the backend in one simple `GET`.

Like the author, I've found that the story with OpenAPI nowadays is really good. I have a short writeup here with .NET that shows hot re-generation of the API into a TypeScript definition that can be used with React, Vue, or your framework of choice: https://chrlschn.dev/blog/2023/10/end-to-end-type-safety-wit...

This workflow is super productive and perfect for small teams working full stack; far easier than getting GQL right.

GraphQL makes it easier for front-end developers to do the wrong thing, which is why they love it.

it's similar to OpenAPI, but its simpler, and cleaner. In fact, you can generate webrpc schema's to OpenAPI and then generate OpenAPI clients.

Not just for the content but I love it when someone changes their mind (very very hard thing to do) and details out what led them to change.

Frontend - React

Backend - GraphQL

What's extra creepy is the private equity firms squeezing this space dry

Why? Isn't YAML human readable?

GraphQL can be very powerful, but also very dangerous.

For example the whole n+1 data fetching topic: Yes this issue exists and like the author is mentioning: GraphQL has a well understood and common solution for this problem. On the other hand: In REST world you can have exactly the same issue, but either create a custom solution for this issue or push the issue to the client side, where this issue needs to be solved, too. I could not exactly follow the explanation of the special case of the n+1 problem in context of authorization. "This is actually trickier [...], because authorisation code is not alway run in a GraphQL context." OK authorisation code is not run in a GraphQL context, but why is this then a GraphQL issue?

On the rate limiting issue I also do not see why these issue would by design just exist in GraphQL world: Yes you can have recursive data structures and write queries which can take a lot a processing time to resolve. But again: Why would the same recursive data structure not be possible to be modeled for a rest api and why would the same data not be queriable from a rest api? My guess again is: You _can_ model the same data structure and also _can_ query the same amount of data. And also again: In case of the rest api the complexity of querying this data is just pushed to the client side and that is why it seems easier to rate limit individual rest endpoints. But actually I see no reason why a GraphQL API could not rate limit e.g. on data loader or any expensive operation level, too.

Generally regarding malicious (e.g. malformed) queries: I think this is definitely a valid issue, which should be addressed in GraphQL APIs. I think there should be a common way for application developers to sign their queries somehow and query engines should only attempt to process signed queries. This way only trusted developers are able to write arbitrary queries.

On the "Authorisation" section I can not quite follow the reasoning. Aside from implementation-specific extra-calls to a presumed authorisation framework: Why would domain requirements be different when they are implemented either as REST API or as a GraphQL API?

"Compare this to the REST world where [...] you would authorise every endpoint". OK if you can implement an authorization requirement simply on a REST endpoint, why could you not implement this simply on a Query-Type field in an equivalent GraphQL API? If this is about authorization on nested data structures: Can you not have equally nested data structures on REST endpoints, too? I think in these cases authorization on REST endpoints wouldn't be sufficient, too. Assuming you would avoid nested data structures: Would this not simply push the n+1 problem from the server side to the client side?

My general feeling about the REST vs GraphQL debate is both worlds can in principal cause pretty much the same issues. Even for client side caching I see no real design issue which prevents GraphQL queries and responses to be cached, but probably more like a middleware issue. On the other hand I still see a lot of benefit in using GraphQL: Especially the query flexibility for developers, the solved the n+1 query problem (which may still exists on the rest client side or is solved by a custom solution) and the error handling. I still hate to define exact use of HTTP status codes and custom error payload structure in every context where REST is a new or badly defined concept again and again.

I'm looking at Shopify API at the moment, and there's a notification that they're deprecating their REST API and moving it all to GraphQL. I hope it's a joke. But I suspect not. Enshittification intensifies

In other news, bitcoin will never replace cash, most companies don't need k8s and AGI isn't 2 years away.

I think it's worth mentioning that there is a GraphQL project which has worked to address every single point elucidated here. Of course whether the framework's conventions satisfy your tastes and sensibilities is an entirely different story. The project had at least an answer if not the answer to every gripe listed in this article by the end of 2022.

Despite having basically solved all these issues two years ago, there's been a consistent stream of articles, videos, and podcasts like this one claiming that GraphQL is too complex and the GraphQL ecosystem doesn't provide any tooling or support for managing these complexities.

The great irony is that the framework in question is now pivoting away from GraphQL. Seemingly no one wanted to use a GraphQL framework. But why? Whenever someone learned about the framework, they would say to themselves:

"Well I don't want to use a GraphQL framework since GraphQL has all these problems like auth and caching and rate limiting and performance. It's just too complex so I'll avoid any frameworks that use GraphQL." They would never seem to realize that the very framework they were refusing to use was literally the answer to the justification provided for why they didn't want to use the framework. Eventually, after having this exact conversation a few hundred times with a few hundred devs, I decided that there's only two ways I could explain what was happening, either:

(1) Every time while trying to explain this, all of these developers were experiencing some kind of out of body dissociation not dissimilar to a stroke or brain aneurysm which made it impossible for any semantic meaning to reach them.

(2) These developers just didn't like GraphQL and didn't want to use GraphQL. They were making up a bunch of reasons to not use GraphQL but they had no interest in a framework which solved these issues cause the issues weren't the problem, GraphQL itself was the problem.

Since I've already spent hundreds or even thousands of hours trying to explain to the open source web dev community how RedwoodJS solves these issues, you'll have to forgive my laziness today and make due with this ChatGPT rebuttal instead of another one of mine.

Understanding RedwoodJS in the Context of GraphQL Criticisms: A Detailed Response

The blog post raises several valid concerns about GraphQL's use in production environments, particularly around security, performance, and complexity. Here's how RedwoodJS addresses these issues, considering the specifics mentioned in the blog post.

1. Attack Surface - The blog highlights that exposing a query language like GraphQL increases the attack surface of an application, necessitating robust security measures. RedwoodJS leverages GraphQL Armor, which provides built-in protections against common GraphQL vulnerabilities. These include rate limiting, depth limiting, and cost analysis to prevent overly complex queries. Additionally, RedwoodJS uses Envelop plugins for enhanced security measures, such as blocking field suggestions and masking errors, which are essential to prevent information leakage and mitigate potential attacks.

2. Authorization - GraphQL's flexibility can lead to challenges in properly authorizing access to different fields based on context. RedwoodJS integrates authorization directly into the schema using directives like `requireAuth` and `skipAuth`. This ensures that each query and mutation can enforce authentication and role-based access control efficiently. By embedding these security checks into the GraphQL schema, RedwoodJS helps developers avoid the pitfalls of broken access control.

3. Rate Limiting - The blog points out that GraphQL queries can vary significantly in complexity, making it challenging to implement effective rate limiting. RedwoodJS includes mechanisms to estimate and limit query complexity. It supports configurations to set maximum query depth and complexity, thus preventing queries that could otherwise lead to server overload. These settings help ensure that the GraphQL server can handle incoming requests without being overwhelmed, addressing the concern of unpredictable query costs.

4. Query Parsing - GraphQL's requirement to parse queries before execution can lead to vulnerabilities if not handled correctly. RedwoodJS mitigates this by implementing limits on query size and the number of operations, ensuring that the parsing process does not lead to excessive memory consumption or server crashes. This approach helps safeguard against denial-of-service attacks that exploit query parsing vulnerabilities.

5. Performance - The blog mentions issues like the N+1 problem and challenges with HTTP caching in GraphQL. RedwoodJS uses the Dataloader pattern to batch and cache database requests, effectively mitigating the N+1 problem. By ensuring efficient data fetching mechanisms, RedwoodJS maintains performance even with complex queries. Additionally, while HTTP caching is not inherently compatible with GraphQL, RedwoodJS’s structure and client-server interactions are designed to minimize redundant data fetching.

6. Complexity - GraphQL's flexibility can lead to increased complexity in codebases, making it harder to maintain and debug. RedwoodJS aims to simplify the development process by integrating various tools and abstractions that reduce boilerplate code. The framework's philosophy of convention over configuration helps maintain a clean and manageable codebase. Moreover, the built-in support for Cells (components that handle data fetching, rendering, and updating) abstracts much of the complexity away from developers, allowing them to focus on business logic rather than the intricacies of GraphQL.

7. Conclusion - RedwoodJS addresses many of the concerns raised in the blog post through its robust tooling and thoughtful abstractions. By integrating security measures, optimizing for performance, and simplifying the developer experience, RedwoodJS presents a compelling solution for building modern web applications with GraphQL. While the criticisms of GraphQL are valid, RedwoodJS's approach demonstrates that with the right framework, many of these issues can be effectively mitigated, making GraphQL a viable choice for many projects.

> if you expose a fully self documenting query API to all clients, you better be damn sure that every field is authorised against the current user appropriately to the context in which that field is being fetched.

The same is true for a "regular http API" [now abbreviated as "rest API"] (in case it's not clear: imagine how the http API would look like and think about if it would be somehow magically secure by default. Spoiler: it won't). Security by obscurity was never a great thing. It can help, but it's never sufficient on its own.

> Compare this to the REST world where generally speaking you would authorise every endpoint, a far smaller task.

Just think about how many endpoints you would actually need to cover all combinations that the graphql API offers.

> Rate limiting: With GraphQL we cannot assume that all requests are equally hard on the server. (...)

It's true. However: a rest API only makes that easier because it's less flexible and you have to manually create one endpoint for each of the various graphql API combinations. So instead, a classical graphql mitigation that the author does not mention is to simply require the client (or some clients) to only use fixed (predefined) queries. That is then the same as what a rest API does, problem solved. So graphql is not worse of here, but it can be much better.

> Query parsing

This point is actually fair, except for the claim that there is no equivalent in REST. That is simply not true, as there have been many cases where rest frameworks worked with json and could be ddos'd by using large json numbers.

> Performance: When it comes to performance in GraphQL people often talk about it’s incompatibility with HTTP caching. For me personally, this has not been an issue.

Funny, because that is indeed one factual disadvantage of graphql.

> Data fetching and the N+1 problem: TLDR: if a field resolver hits an external data source such as a DB or HTTP API, and it is nested in a list containing N items, it will do those calls N times.

No, this is wrong. But first: this problem exists in a rest API as well, but worse: instead of N+1 queries to the DB, it will N+1 http requests AND N+1 db requests. But with graphql and some libraries (or some handwritten code) it is comparibly easy to write resolvers that are smart and "gather" all requests on the same query level and then execute them in one go. This is harder to do in a http api because you definitely have to do this by hand (as the auther describes).

> GraphQL discourages breaking changes and provides no tools to deal with them.

What? Comon. In a rest API there is no means to do anything against breaking changes by default. Graphql at least comes with builtin deprecation (but not versioning though).

> Reliance on HTTP response codes turns up everywhere in tooling, so dealing with the fact that 200 can mean everything from everything is Ok through to everything is down can be quite annoying.

True, but that can be adjusted. I did that and made it so that if all queries failed due to a user-error, the request will return 400, otherwise 204 if they partly failed.

> Fetching all your data in one query in the HTTP 2+ age is often not beneficial to response time, in fact it will worsen it if your server is not parallelised

Okay, I'm starting to be snarky now: maybe choose a better language or server then, don't blame it on graphql.

And actually, many real problems of graphql don't even get mentioned. For example: graphql has no builtin map type, which is very annoying. Or, it has union types in the response, but you can't use the same types as inputs due to a lack of tagging-concept.

And so on. My conclusion: the auther is actually fairly inexperienced when it comes to graphql and they probably had a bad experience partly due to using ruby.

My own judgement: graphql is great except for very very specific cases, especially in projects that require huge amounts of servers and have a high level of stability in the API. I would always default to graphql unless the requirements speak against it.

Maybe I'm missing something obvious, but React isn't mentioned in that post. Maybe you put the wrong URL?

So that: 1. we enjoy the current tech stack from REST/rpc 2. we gain the ability of quick composition from resolver / dataloader 3. with iteration, we can replace/ refactor endpoint without breaking anything.

for fastapi user, the lib 'pydantic-resolve' can help.

Seems really great to not have each service adhere to another service’s potentially unstable api contract.

Especially if that service is owned by another team.

    > Data fetching and the N+1 problem
    > [...] if a field resolver hits an external data source such as a DB or HTTP API, and
    > it is nested in a list containing N items, it will do those calls N times

F.e. using REST, if the nested list contains on average N-2 items that can be efficiently cached, wouldn't that be better than having the cache constantly invalidated on the aggregation of the parent and its items?

Yes there is, simply throw JSON such as `[[[[[[...` at the server. You probably don't have to get into parsing though, nearly all C# (and Node, and Ruby, some Rust even) assumes that memory is, in-fact, infinitely large and just throw network input into a precisely-sized buffer. Just upload a few GB of nonsense to an API endpoint, bonus points if you omit Content-Length.

Skill issue.

REST serverless business logic on top and graphql is great

For graphql like needs we use a standard set of props (select, filter, sortBy, limit, offset).

They map to a single sql statement and executed efficiently by PG.

select can be nested properties if we need deeper nesting. Server emits typescript types package for frontend.

It's worked really well so far at our scale. Eng team is fairly productive.

I'm less happy about the time I wasted on bash, DOOM WADs, and Desktop Linux. Yes these are are all a while ago. I didn't invest my time wisely when I was young.

I'm also glad I didn't invest in GraphQL, Kubernetes, Angular, Solaris, and perl.

One example that stood out to me though:

> GraphQL discourages breaking changes and provides no tools to deal with them.

GraphQL the standard doesn't provide tools no, but I've been very successful using Apollo Studio to solve this as (in my experience) the workflow maps to how you generally develop applications:

1) agree on some schema 2) make a (Apollo studio) "branch" with the schema change 3) mobile & backend devs (typically) code gen the objects they need for the schema 4) backend dev deploys a preview branch of their implementation, mobile dev points the client to it 5) test it, merge it, publish the schema on the main "branch" - deal with the breaking changes if Apollo warns you of them.

So maybe you can accomplish this with other tools, and maybe it's not fair to compare "the standard" to a particular tool, but I usually say I stick to gql (where appropriate) because there is a tool for it that works so well for the problem(s) I'm typically solving.

Would it be fair to say that GraphQL is extremely useful for internal-only clients? For example an inhouse data store, query service, test status monitor, etc?

So many issues disappear when you aren't concerned about bad-actors and you have _some_ control over both client and server.

We don't have mobile app and don't even plan, but if we do, we always can implement some rest api.

Then I'm designing my table structure, optionally designing my views when I don't want a 1:1 reflection of how data is stored, setting up row-level security at the data layer, and making user-defined functions for the one-offs that deviate from plain CRUD.

But solutions like Spring DGS for Java, Graphene for Python, and Apollo for Node? No thanks. Never again. Way too much trouble and pain. I'd rather make lambdas that talk to the data store directly and output HTML than make and maintain a GraphQL schema manually again.

I really wish Postgraphile and Hasura were more popular, so folks could have skipped the low level plumbing and optimization fences like dataloaders that make GraphQL such a chore otherwise.

It really is elegant when you're not stuck in a swamp.

At Firebase we chose GraphQL as the basis for our new Data Connect PostgreSQL product (https://firebase.google.com/products-data-connect) despite acknowledging pretty much all of the issues outlined in this article as correct.

GraphQL is an excellent IDL (interface definition language). It's compact, it's flexible (through directives), and there's literally no better way I'm aware of to rapidly construct complex nested relational queries. But the promise of "clients can fetch whatever they want" adds an enormous burden to backend developers because you have to secure yourself against queries of arbitrary shape and complexity.

In reality you don't want clients to "fetch whatever they want" because clients can't be trusted. The path we took is that developers can predefine the queries that are needed for their client, and then only those queries can be executed from an untrusted client.

This approach provides a surprising number of benefits - you get the flexibility of nested queries and field selection, the end-to-end strongly typed structure of a schema-driven API, and the ability to reason about security like it's a custom backend.

Made the dev experience a nightmare because I could never be sure whether it was my code or the client cache or the (actively in beta) server that was causing me to get back wrong data.

I've built platform which does just that: https://saasufy.com/

This approach has allowed me to create a library of highly generic components which can be composed into surprisingly complex front ends and where all data updates in real time (in a targeted, efficient and scalable way): https://github.com/Saasufy/saasufy-components?tab=readme-ov-...

You can build just about any front end you can imagine just by assembling these components. Almost no code needed. It takes me hours to build web applications which would take weeks or months to build. The real time update features come free. The dev experience is essentially bug free; any 'bugs' you may encounter have clear visual symptoms which can be 'debugged' by observing the HTML DOM.

I'm currently observing people getting hyped up over HTMX and it's kind of funny to realize that developers do actually like the declarative approach... And yet they're going in the wrong direction again. Just as they did with GraphQL.

It would have been impossible to do this with GraphQL because field-granularity/autonomy is essential. GraphQL queries combine different resources and fields together in complex ways and this makes it impossible to efficiently avoid real time update conflicts on the front end.

Perhaps now it might be;

Nice to haves: Enough experience with GraphQL to never suggest nor implement it.

These are the kind of experiences I think which truly matter.

Looking back, it is hard to believe I spent a decade working in shops with no published spec, no code-gen. So many ugly surprises discovered in production, all of which were avoidable. Never again.

And for each issue he mentions that rest doesn't have said issue is basically because rest doesn't have the feature at all.

You could use graphql the same way as rest (by exposing queries without allowing to specify fields) and you still have a better rest, since at least the response has a schema out of the box.

GraphQL has a lot of advantages, the most important of which is data masking. In a properly structured GraphQL app, only the function that requested a field (i.e. included it in a fragment) sees that field. This allows many developers to move independently, without communication or coordination.

It's unfortunate, but there are lots of rough edges with GraphQL and it is hard to incrementally adopt, and so if you don't have enough developers (to have communication issues) and a team devoted to adoption, it might not be worth it.

Anyway, Isograph is a framework that seeks to take away many of those rough edges, while baking in stuff like data masking, etc. Y'all should check it out!

This essentially turns GraphQL into a DSL for implementing REST endpoints, which is still a useful thing since it allows to write the REST endpoint with only knowledge of the GraphQL API rather than knowledge of the whole backend architecture, which is generally useful if the backend and frontend are written by different people or teams.

That's the way Facebook uses it on their main website: they pass the query id in the "doc_id" form field, the arguement in the "variables" field, the server gets the actual GraphQL query based on the doc_id from some sort of internal dictionary and AFAIK no GraphQL query string ever goes on the wire in production.

Something just never felt right about the client building the queries for me, I guess.

The problems with GraphQL where so obivious in the first 5 minutes that I looked into that. Looks smart and flexible - but isn't

I remember working on a Rest API and thinking about (things like) GraphQL... the typical "would it make life easier" and all that.

In the end, as the years have passed, I just stick to the minimum. If there is a tried-and-tested library or something.. I use it. When there is something new, I question it.

Never tried GraphQL. It looks like it can improve my data on one end, but cumbersome when it is hard to reason the data, or get generally complicated, which this article demonstrates.

But when you see those job ads with all these "great new technologies" it's hard not to fall into the trap.

Not sure if this will be good. This reads like they will add Vertical Tabs as a Sidebar, like all the other vertical tab-addons doing it now. But since the Quantum-update there is demand for a second sidebar dedicated for tabs, because as it's now, sidebar is really annoying to use.

But maybe it will at least add some improvements which the other addons can built upon.

> More streamlined menus that reduce visual clutter and prioritize top user actions so you can get to the important things quicker.

Oh gosh, no! Why make them even worse than they are already now?

Stick to tried and true - monolith, asp.net, angular or blazor front-end, relational database.

As for how to tackle things today, I alternate between REST+OpenAPI and RPC models for communication. I am certainly biased as I have my own typed open source RPC library (Conduit) which is layered on top of arbitrary message passing transports such as WebSockets, but as of yet it's only suited for Typescript-based clients -- REST+OpenAPI is a better fit for an API with many consumers.

But for dynamic client/server and client/client single-implementor communication needs, I go with RPC.

- GraphQL performance issues

- GraphQL makes tasks more complex

- GraphQL schemas confuse junior devs, higher entry level

- REST cache easier

- REST if you understand what you are doing ... can do the same

- REST is better for error handling and tooling

Now in 2024, I clearly see LLMs gives much better autocomplete for REST or SDK code generated with protobuf ecosystem

There is not enough code repos based on GraphQL for LLMs to reason.

If you have like minded people who loves GraphQL, nothing can stop them but at higher and broader level it's a huge risk for dev velocity (like anything else if you dont know what you are doing)

The entire point is composition + client customization of the response body, but in practice the request schema is never modified. And even if it were, you could just version a REST endpoint.

GraphQL is never done "correctly," adds a layer of obscurity to monitoring and error tracing, and I've yet to see a case where it's actually the right tool for the job.

Maybe if you need to aggregate calls to multiple services into one, but if you're trying to avoid latency by reducing number of calls, you still eat that latency while the GraphQL server makes those calls for you.

GraphQL sucks.

However, you can go very far with a simpler version of it, just by allowing clients to specify what fields/relations they want and in what context.

I'm using a library that I've created for myself for years without any of the problems mentioned in the article.

The client side queries are generated by the server at compile time. Each request for an object requires a "segment" to be specified. On the server, each segment has the necessary filters/limits automatically applied to prevent data leaks.

The lie is that it makes things better. 100% of the time that I add an unnecessary thing to a project in the name of "it will make things better", it never did.

It's the old new-shiny, so here we are lathering on our dislike, which I feel is totally normal and expected. There's a new new-shiny around somewhere and a few years from now, I'll see articles like this one about it.

Having not yet read the comments, I plan to enjoy them thoroughly, I love a good hate-post about software I myself don't like. :)

- https://github.com/rsinger86/drf-flex-fields

- https://django.wtf/blog/graphql-like-features-in-django-rest...

I am also over GraphQL but I really like the api explorers, code completion, type safety, etc.

Because of my experience, I feel that your position is making a slim distinction based on your preferences. All the tech you use is built for big corporations, why pick on one set of tech just because you don’t have the specific problems it solves?

For me, for example, K8s properly solves a bunch of problems for my small SaaS business, not least of which is that I can upgrade my three piddly servers without taking my customers offline. My SSL certs get upgraded automatically without downtime. My CICD pipeline is simple. Logging is much easier. And so on.

I don’t understand the disdain for modern, managed K8s at all.

For example, messages inside messages and messages in other "packages" can, accidentally be named the same, and then the author of such a definition will be spending a lot of efforts debugging such code because, without telling anyone, Protobuf parser (the one written by Google, other implementations behave differently) will prefer the one inside another message to the one inside another package.

To make this more obvious, suppose Protobuf had "package" separator, let it be ":". Then, you could define messages a.b:c and a:b.c. Then, there's no ambiguity. However, since there's none, and physically, the message a.b:c lives in b.pb file and a:b.c lives in a.pb file...

Another hilarious aspect is that fields inside messages are allowed to repeat (in the wire format). And the last one wins! So, using this easy foot-gun, Protobuf made streaming impossible.

Another tell is that Protobuf didn't have a formal grammar until much, much later. And once it was written, it was never tested on the real parser. I submitted a handful of tickets against that grammar because it was ridiculously bad. Simple and very common stuff like strings, that requires a little bit of sophistication (because of quotes and escape characters) was broken in the way indicative of someone doing it for the first time (and not even trying to test). The kind of screwups I saw my classmates do in our automata theory class.

It's wild and weird how such a poorly conceived "invention" gets enormous amount of attention and use (probably because of the company behind it).

The thing that I still _like_ about GraphQL is that it's a nice approach for expressing complex domain models over a protocol. If you are working with either REST or protos, you may still have to reason about graph-like structures but without the benefit of a graph-like schema.

It is often a poor choice for websites that should be cached, are publicly accessible and have simple and predictable data access patterns.

GraphQL has a fairly flat but very long learning curve which makes it a power tool that is great for those who have learned it in depth. Without that experience one is almost always better off using REST.

We've got little to gain, and the lack of flexibility from our POV is a relatively good thing. It gives us direct insight into desired use cases, and since the APIs are internal it lets us provide guidance on potentially better ways of implementing things as well as in some cases being able to provide direct optimizations for specific tasks.

I do really like the Api definition part of it though - but I found something like typespec now to be the perfect middle-ground, it allows out you describe your apis similar to a graphql Api without enforcing the graphql engine on you though.

Authorization: I do it in the database using roles, row level security and column level security. It works well and I defer everything to PostgreSQL's security controls, it feels like the right place to do it and I don't have to worry about it going out of fashion, PostgreSQL is here to stay. Anybody else who talks to the database directly is also subject to the same authorization rules, which is nice.

Introspection: this should really be disabled on production services. Only enable it for development.

N+1 problem: I don't really have a problem with N+1 because PostGraphile converts the request into an efficient query. In other cases this problem presents itself in REST too and the article proposes hoisting N+1 queries to the controller, but that's just really moving the problem around, and you can do this with GraphQL too.

The other problems, yeah sure they are present and a worry if you're running some highly visible/very loaded public API.

Basically, these are all solved problems.

My biggest complain is there seemed to be no way to just to query all fields. I know that is intentional and the point of GraphQL.. but they should support something for the server side to enable this. Maybe they have over the years, I don't know. But my experience was during the implementation phase the client kept adding new fields that I didn't know about and then I had to constantly ask them for the fields because I thought I was missing data. If I could have just queried ALL the fields, then saw what came in, and chop them down to what I need.. great.

The only way GraphQL seems to make any sense is if everything is basically completely defined and you are at a final project stage. After many many years of experience... this is rarely the case.

Cool piece of technology? Sure.. but hardly practical except in scenarios of extreme amounts of data and only when it makes sense for the client to return specific fields.

Although I think still for 95% of even those extreme cases, you just write a REST endpoint that returns the fields that make sense for the query....

GraphQL works pretty well when it's acting as a Backend-For-Frontend. The client can make a single call to get everything it needs at once, the BFF can then fan out to various microservices as needed. The frustrating part is when it's blindly used for something like a monolithic CRUD API with some light permissions. In that scenario you're taking all of the drawbacks, without reaping any of the benefits.

I'm really glad to be leaving this project behind as I move jobs, and I'm praying no one suggests using it in my new job. At least not until the industry more broadly understands it in more depth.

In this way services get freedom to define their stack while still neatly fitting into the suite of services, products get a tidy interface from which to query everything, and because the GraphQL consumer is more akin to a regular database consumer, the database muscle memory kicks back in.

I’ve also grown to prefer bespoke backends for each client over a super backend that tries to anticipate all of the needs of all the clients. It just opens too many holes and what it buys in versatility for the client author it also gives to the exploit author.

But at the same time it doesn’t have to be that bad. I don’t have this array of issues because I do: - query whitelisting for performance and security, - data loading to avoid n+1, authentication with whatever works(session cookies, tokens), - permission check based on the auth context in a resolver.

It works decently for us, allowing to stay away from getting into ESB. Yet have some shared domain, type safety, and easy integration of legacy and new systems/services.

I would say a bigger issue for us was to keep it all nicely organized / designed in terms of types and api contracts. But that’s manageable.

I have no beef against doing REST, jsonRPC etc. Actually I consistently steer people that way. But the documentation format we chose as an industry to build these things with, Swagger, is just disappointing. Some times I think the industry would be at a totally different point had we gone with more powerful standards like API blueprint (or maybe raml).

Case in point, I'm consulting an org with roughly 1k engineers right now on improving their API ecosystem and what we are seeing is that the more OpenAPI tooling they use, the worse the DX gets...

https://github.com/porsager/HashQL

However, lately I’ve been thinking that with the advent of React Server Components we will see a migration away from GraphQL-focused Frontend applications, and instead move toward other solutions. Such as ones based purely on exposing Postgres databases (e.g. supabase & postgREST) and type safe APIs (e.g. tRPC).

Authorization is performed by GRPC which returns only fields available to the user, rate limiting is performed on GRPC requests so at some point your data will start coming partially if you make too many queries or query that is too complex, N+1 problem is still there, but in a distributed system it's there even without GraphQL, the mitigation is caching in GraphQL server on GRPC request level.

In my experience GeaphQL really helped decouple frontend and backend and I'm pretty happy about it.

Besides GraphQL offers some standard way of making server side event streaming, it's not supported that well, but at least it's more comprehensive than bare web sockets.

I never got around to implement mutations though, individual change requests via REST are enough.

It's very true that a few years ago the gap was there, and people implementing GQL had to solve all these problems without access to these mature solutions.

But these days, they're mostly solved problems. Authorization by type that propagate through the graph is pretty simple. Rate limiting and complexity limits on queries is often built in the frameworks. Query parsing is solved with persisted query all the major frameworks have as first class citizen. Performance: lots of GQL caching solutions out there, and the "multi threaded by default" model used by most frameworks helps a lot.

Etc etc etc.

I jumped companies a lot, did both. For a while I too thought GQL was redundant, then went back to a more classic world after a successful GQL implementation. I had forgotten how many problems were solved, especially organizational and people communication issues, through GQL. And so we're moving to GQL again.

Someone in the comment mentioned GQL is a tech solution for an organizational problem. I'll say most good software tooling and frameworks ARE tech solutions for org problem, because technology is usually a solution to people problem. GQL is the peek of that, and it does it quite well. Don't use GQL to solve tech problems, there's better tools for those.

In other words, they cared more about ideal ways to access data than the product of that data.

This has so consistently been the case in my personal experiences that I avoid people in hiring interviews that start talking about or try to sell me on why I should switch my stack to GraphQL.

Auth on leaf nodes, maybe I'm not understanding the issue but it seems solved without GraphQL. JWTs are one way.

Anyway, here's an example with Hasura:

https://gist.github.com/dventimihasura/b3f3c9e7ef1442d8e7f16...

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...

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.

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.

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.

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.

GraphQL is one, Redux is another.

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.

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'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.

I like the thought experiment of adding a new persisted/editable field to an entity in a web app, if you've done full-stack you know all the layers that need to be touched to accomplish this and how lame most of the work turns out to be. After doing that 20 times while iterating, any dev worth their salt starts to wonder why it sucks so bad still and how it could be made better, and some will actually try.

We just joined the CNCF, too!

With GraphQL you are doing a lot of extra work query wise than you do with REST, which is supposed to translate into various benefits. But each vendor has different implementation details that affects whether you actually receive those benefits.

This is different than REST, the benefits of REST are generally the same for every vendor because implementation details and API are extremely simple, what is different is the data structure you receive back.

In GraphQL both the data structure and the implementation details are different. GraphQL I think doesn't make sense if you have multiple data sources from different vendors, because of this increase in complexity and not being to trust how good their implementation actually is until you've gotten into it.

This gives the front-end developers lots of flexibility when initially developing new screens and components. Once the UI is ready to ship, the backend team checks to make sure that performance is acceptable (optimizing if necessary), allowlists the new query/queries, and ships to production.

But if you locally queue, and one worker gets unlucky and gets the longest tasks, then the whole cluster sits idle while this worker starts and finishes multiple tasks. If you reallocate the ones that haven’t started or have timed out, then the overall time comes down quite a bit (and in the latter case also covers workers that crash).

For development teams it could mean moving the boundary on a service or API so your team does more of the feature work than originally planned, because the other team keeps getting jammed up on bugs or other operational issues.

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.

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 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 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).

But I think it comes with a lot more reluctance and skepticism. You are not likely to jump in head over heels, and even when you do give it a try I expect most farmers will do so with the attitude of "if it doesn't work at least I can always go back to the old way".

The "OMG this is amazing and will solve all of my life's problems" attitude I see in tech certainly isn't there in my experience.

Think more like marketing campaign or product design.

2. No reliable way to handle queue overflow.

Combine both and you are 100% guaranteed to have an incident. (I guess it keeps devops and sysadmins employed, though.)

The current version of MongoDB, imo, makes you super productive and scales without a ton of thinking. If you're working in Node.js, it's even more useful as the query language works just like a JS/JSON object so writing queries is super fast (compared to SQL where you have to spend a lot of mental cycles figuring out how to map object/array data).

I've found that denormalizing data (not even necessarily copying/duping data, but trying to centralize storage of it) when using MongoDB is the way to get the most value out of it. If you try to treat it like an RDB (which does work but can cause issues with complex queries), you'll run into headaches. If you just design stuff to be nested, though (and use the built-in APIs to query that nested data), it works incredibly well.

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`...

(Most) GraphQL clients are optimized for relatively small/simple objects being returned, and you typically pay a cost for every single edge (not node) returned in a response / cached in memory.

It can quickly get to the point where your project is spending more time per frame processing GraphQL responses & looking data up from the cache than you spend rendering your UI

  type Starship {
    id: ID!
    name: String!
  }
  type CaptainQuery {
    captains(starshipFilter: [Starship!]): [Starship]
  }

  # leading to
  {
    captains(starshipFilter: [{name: "Alpha"},{id: "cafebabe"}]) { id }
  }

Of course the query itself is not json, why should it be? It describes the shape of a json object, and queries are generally pretty static. But the request to the server is json, the request variables are json, the result is json, and all the json tooling can be used in the responses in our clients.

Honestly, one of the reasons I like GraphQL is the fact that underlying it all is just JSON.

performance was the least attractive reason for adopting React. React introduced composition as the default way of thinking about UIs to the web. You created components and used them to build more complex components. Data was immutable and flowed in one direction (parent component -> child component).

Comparing the above to ng with its dependency injection, MVC style approach to UIs, that used HTML based annotations and tags to sprinkle in functionality (`ng-if` baby) -- it was a much more simple way to build web applications.

React's style of building UIs has largely won. Vue, etc. all follow this component with composition view of the world.

> React sucked for years, with a terrible doc, a crippling webpack experience and breaking compact all the time.

Webpack has nothing to do with React. React has always had good documentation. The reason the documentation was good in the beginning was because the API surface area was tiny compared to Backbone, Ember, ng, etc..

I'm not going to go point by point here. You sound like you have a very superficial understanding of the space.

I'm going to hard pass on clicking a marketing link to your blog.

Webpack wasn't how it started, remember gulp?

Also don't forget the switch from class components to functions, then inventing "hook" functions to reintroduce functionality that already existed in the class components.

For the past few years I've been on a team that handles a legacy system from long before React existed (internal) that just renders HTML directly, a client website that uses Backbone, and a newer client website that uses modern React. The old internal one that doesn't use any frontend frameworks has been by far the nicest to work with, and Backbone the worst.

I think that's some missing context as well - React+Redux was much better than what came immediately before it, for complex web apps. But when you're not building something like that, yeah, both are worse. It just doesn't seem like the Backbone era encouraged people to use it for everything, unlike React.

React solved a very specific issue that was a pain in Angular, which is making it easy to write small, self-contained components and attach them to a mostly static site. That people decided to use it to make entire SPAs further illustrates how much easier they found it than other solutions.

I can't think of a case where JQuery code is ever simpler than React code, even for small things. If you need to worry about the order of rendered items or moving them into different categories on a page based on input, it's much simpler in React.

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.

Or are you just sending all data the client cloud possibly see over?

XML is mostly already lost on the current generation of developers though, much less future developers. Protobuf and cousins generally do typed interchange more efficiently with less complexity.

Go's XML parser straight-up emits broken XML when trying to output tags that have prefixed namespaces.

It sure is better for the backend team, but the client teams will need to have countless meetings begging to establish/change a contract and always being told it will come in the next sprint (or the one after, or in Q3).

> This leads to far more fingerpointing/inefficiency in the log run, despite whatever illusion of short-term expediency it creates.

It is true it can cause these kind of problems, but they take far, far, far less time than mundane contract agreement conversations. Although having catastrophic failures is usually pretty dire when they do happen, but there are a lot of ways of mitigating as well like good monitoring and staggered deployments.

It is a tradeoff to be sure, there is no silver bullet.

With my single WordPress project I found that WP GraphQL ran circles around the built-in WP REST API because it didn't try to pull in the dozens of extra custom fields that I didn't need. Not like it's hard to outdo anything built-in to WP tho...

It's really not, it's not exposing your whole DB or allowing random SQL queries.

> It is far better for the Backend to provide the Frontend a contract

GraphQL does this - it's just called the GraphQL "schema". It's not your entire database schema.

And the REST API can still get hammered by the client - they could do an N + 1 query on their side. With GraphQL at least you can optimize this without adding a new endpoint.

- Each individual thing available in the request should be no less timely to handle than it would via any other api

- Combining too many things together in a single call isn't a failing of the GraphQL endpoint, it's a failing of the caller; the same way it would be if they made multiple REST calls

Do you have an example of a call to a GraphQL API that would be a problem, that wouldn't be using some other approach?

XML is so much more than hierarchical data serialization format. In a typical conversation XML generally means "JSON-compatible subset of XML" as if the other parts do not even exist. Like in the meme "Javascript vs Javascript the good parts".

XML never really took off, only the parts that make up "different flavor of JSON".

It feels like a cross between JSON and HL7 to me.

If you're providing an external API like GitHub does, then that's a different story and I agree.

Surely that is always the case, if the client is composing multiple REST requests, or if there’s one RPC method per client page, or with any other conceivable data loading scheme.

What ends up happening is the clients doing work arounds to backend problems which creates even more technical debt

The other extreme end example is to expose by default the entire data model (PostGraphile) and then getting lost in the customisation and authorisation.

This? Yeah, that seems neat, for command/batch queuing.

I'd be curious how it compares to e.g. rest apis returning refs to e.g. webrtc streams or tcp/udp ones for non-browser. I presume the main advantage would be client side.

It takes a lot of work to actually ensure all possible combinations of graphql params hit exactly what you want in the backend, and it's easy to mess with it in the frontend.

A hand-coded REST endpoint will give you a bunch of predefined options for filtering, sorting etc, and the dev who implements it will generally assume that all of those can be used, and write the backing query (and create indices) accordingly.

The graphql usage I'm used to works more or less the same as REST. You control the schema and the implementation, you control exactly how much data store access is allowed, etc. It's just like REST except the schema syntax is different.

The main advantage of GraphQL IMO is the nice introspection tools that frontend devs can use, i.e. GraphiQL and run queries from that UI. It's like going shopping in a nice supermarket.

You get something more complex, more expensive to maintain, consuming more resources, and configure it to basically be REST with extra steps.

And you can both put queries on an allow list, control max query depth, and/or throttle on query cost.

Far from it actually. I am saying that in practice the data and queries that you perform on your Database actually tend to stabilize and you add less and less as time goes on.

By Allowing the frontend to select what combination of these pre-approved queries that you already approved it can use, you have to do less and less backend work when compared to REST where you have to do backend work for every query combination you want to serve.

> maybe that's fine for most small apps (that will never scale far).

I mean saying GQL doesn't scale for big apps is over looking one of the largest Corporate Software Orgs (FB) created and use it in production purposefully for managing large software APIs.

No, I never said that. You are the one that brought FB into the equation.

Just because it can be used for something does not mean that it should.

I said that that approach doesn't scale well, especially for frequent data/model changes. For small apps, where as you say, you have few data changes, by all means embed your database as closely as possible to you end user code.

Sqlite inside a c app or electron, e.g. No need for any API at all! Just raw query access.

Its nice GQL to generate stuff for small non-changing web apps, I'm sure. But once you get into more performance oriented, data-migration-style stuff, if there's not good support for changing the data and reacting to the environment, then adding complexity (GQL) to an already complex situation is a Bad Idea.

You never said what this 1% was, autogeneration is not a bonus when you already have to manually filter and route things. The simpler solution gets you there as well, with less fuss.

You think you don't have page specific apis, but if you are doing the manual filtering, then you still have them, you are just "hiding" them inside another language, that doesn't have a clear benefit? At least you can't say what it is, without going in circles, another sign GQL is probably ultimately a garbage technology...

Hardly gross. It is what it is and it’s universal across the domain. I bet Windows has internal APIs or even external ones that were created just for one page/widget/dialog of one app. It’s the nature of things at times.

For example, a lot of times people build out nice normalized table structures for online transactional apps. The UI/UX is pretty straight forward because end users typically only CRUD an object maybe a couple nested objects at a time. The API's are straight forward as well, likely following single responsibility principles, etc. Then comes along requirements to build UI's for analytics and/or reporting types of things where nearly the entire schema is needed depending on what the end user wants to do. Its the wrong data model for doing those types of things. What should be done is ETL the data from the OLTP schema into a data warehouse style schema where data is de-normalized so that you can build reporting, etc.

With REST, though, that pain is visible to both sides. Frontend engineers generally don't want to make N+1 REST calls in a tight loop; it's a performance problem that they see and that is very visible in their Dev Tools. Backend engineers with good telemetry may not know why they get the bursts of N+1 calls that they see without asking the Frontend or digging into Frontend code, but they can still see the burstiness of the calls and have some idea that something could be optimized, that something is maybe too chatty.

There are multiple ways with REST to handle things: pagination, "transclusions", hyperlinks, and more. Certainly "single page endpoints" is a way as well, no matter how gross it is from REST theory, it's still a pragmatic solution for many in practice.

REST certainly can please everyone, given pragmatic compromises, even if it isn't very clear or standard.

Single page endpoints is exactly what you want if you have more than 5 engineers in your company anyways.

It ensures that the endpoints are maintainable and future-proof when people are working on different features.

I also recall, we had similar N+1 query problems in the REST API endpoints irrespective of hydrating the returned resources.

The biggest benefit of GraphQL I can see from a user perspective is that it lowers total latency especially on mobile with fewer round trips.

GET /myresource?extra=foo,bar

sure you over fetch a bit if you have multiple accessors.

But agreed, if you have highly nested data especially when accessed with multiple different query purposes then REST might not be the best fit.

I think GraphQL has been positioned as a general purpose tool and for that I am with the author, REST is a better go-to for most usecases.

> With internal REST for companies I have seen so many single page specific endpoints. Gross.

As someone pointed out in reply to another comment, GraphQL is "a technological solution to an organizational problem." If that problem manifests as abuse of REST endpoints, you can disguise it with GraphQL, until one day you find out your API calls are slow for more obscure, harder to debug reasons.

That's an established pattern (backend for frontend). Like all patterns there are trade-offs and considerations to make, but it's certainly not a priori "gross".

https://learn.microsoft.com/en-us/azure/architecture/pattern...

And, resources with an index option obviously should have a db index or unique index.

The challenges with GraphQL are that it makes it too easy to DoS services, leak internal data, break referential integrity, and there were a great deal of tools, infrastructure, and monitoring systems already available for REST (and gRPC to a degree).

Company standards for REST and coding style can and should be set in the diff review pipeline. Another facet is setting standards to minimize duplication of effort or exposing a greater attack surface.

Browser does not allow to access any ports with any protocols.

Often intermediate software gets in the way as well. For example with Kubernetes it's trivial to expose HTTP service using Ingress and it's not trivial to expose other protocols.

Another HTTP plus is that it's trivially secured by TLS and every developer knows API for that. Using TLS for your own protocol or QUIC is absolutely not trivial and probably more like arcane knowledge.

I'm not sure where this narrative comes from that GraphQL immediately means that the frontend time will have no idea what they are doing and will induce load on the system.

95% of my nested graphql fields are based on foreign key indexes so its almost no additional load to the system (only 1 query per "level" of GraphQL) to query the nested objects.

I restrict GraphQL to 5 levels and now I have 5 queries per API call instead of 5 Queries over 5 API calls.

The backend team exposes the fields that they know are efficient to query. They can restrict the depth of the GraphQL, number of fields, etc.

Look at OData download stats on Pypi it had 2 downlaods the last day. Graphql-core for python? 624,201. that is not even on the same planet.

If you don't use GQL and want a system of querying nested data you will be using a less used protocol that is analogous to GQL so you might as well use the standard.

Why waste any time?

> And GraphQL isn't free either; you need to actually implement that

Rest isn't free. You have to actually implement also that and end up with a more limited API.

GraphQL libs in Python are equally as complex as the FastAPI etc..

That is how REST works but is the opposite of the way GQL works.

You don't pile into existing defintions but extend the current definitions out. A team needing new data doesn't affect the consumption of other teams. which is not the case of REST where if one team needs to change a REST endpoint to return different shape of data, they have to verify the new shape with other teams.

I started my career as a full-stack developer, but went all-in on frontend because I felt I was spreading myself too thin. At one point I found that I could choose to be almost good enough at doing two different things or extremely good at one thing. I chose the latter option.

Modern browser apps are complex beasts, at least if you want to do them right. You obviously have to worry about all the technical bits --- HTML, CSS, JavaScript, your view library of choice, platform APIs like <canvas> and WebAudio, cross browser testing, bundle sizes, performance optimizations, techniques like optimistic rendering, all that good stuff.

On top of that, you also need to work closely with designers to make sure they know the features and limitations of the platform(s) they're designing for. More often than not, you end up being a sort of bridge between the backend devs, designers, and product managers.

A lot of times you end up doing design too, whether you like it or not. I've learned a lot about UI/UX design just because I often have to fill in the gaps where a designer forgot to include a certain error state, or didn't test their design on tablet screens, or didn't account for cases where a certain API might not be available.

I tried for many years to learn as much as I could about Django as well as React and friends. But it eventually got too much. I found that I wasn't able to keep up with both ecosystems, and I was producing code that wasn't very good. I could certainly build things quickly because I was familiar with all parts of the stack, but it came at the cost of code quality, security, stability, and robustness. I eventually decided to hang up my backend developer hat and focus exclusively on what goes on inside the browser (which can be a lot by itself these days!)

It's probably possible for a single individual to build a high-quality server-rendered MPA with some forms without making a mess of it. But that says more about how good Rails/Django/Laravel are than about the capabilities of any single individual. I don't think a single person could build a product like Linear end-to-end without cutting corners.

In practice with REST the frontend engineer didn't want to wait and tried to use the existing REST endpoints, did N+1 API HTTPS calls and then joined them client side in javascript.

But yes, that break-down of the problem is insane. People artificially split an atomic problem in two, and go create all of that extra craziness to try to solve the communication problem they made.

And then people go and push UX and UI tasks into the frontend developer, and ops tasks on the backend since them are there... What is insane again, because those are really incompatible tasks that can't be done with the same mindset.

And since it's standard, backend tools won't support the frontend and the other way around. So the insanity gets frozen on our tooling.

I wrote some front-end stuff back in the days but I've lost track of whatever is happening these days. jQuery to append some stuff took five minutes to learn, but learning react hooks takes a determined effort.

Likewise, adding a field to a graphql type is simple, but doing it with authorization, controlling n+1s, adding tests etc.. requires front-end folks to actually invest time in learning whatever back-end they're dealing with this time.

Everything is just a lot more complicated these days, and if you've been around for a while you may not be excited anymore by the churn, but rather fed up.

Yeah sure you can make it work with anything if you spend the extra effort but the ownership really isn't as defined as in REST.

Is there code which have fuzzy or no ownership? Are there changes which affect other teams? Suddenly those became much harder questions to answer.

As far as looking OS-native, this is (unfortunately) increasingly less relevant as OSes themselves drop desktop UX consistency even internally. But that aside, Qt is still around and is a very mature framework for "near native" UI, and then there's Avalonia and others. Even Gtk is surprisingly decent on Windows these days. Although I'm not sure what this all has to do with the original subject, since web apps most certainly don't look native anywhere.

"That would be one way to implement the system in a DB-centric way. However we believe that intermediate application code is pretty critical to any GraphQL implementation." [1]

"GraphQL is a client-server dance that needs server-side capabilities, not just CRUD semantics." [2]

[1] https://news.ycombinator.com/item?id=9879870

[2] https://news.ycombinator.com/item?id=14351800