[burutthrow1234]

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.

[peterldowns]

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.

[0] https://hasura.io/events/hasura-con-2021/speakers/peter-down...

[tangkikodo]

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.

[jack_riminton]

Yep, Conway’s Law:

“ 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

[belter]

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

[torginus]

This.

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.

[sodapopcan]

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!

[torginus]

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 is one, Redux is another.

[ForHackernews]

Sounds good to me. I'll do GraphQL for $250k.

[hattmall]

You can, just start rewriting all the broken shopify plugins that the switch to GraphQL killed.

[belter]

Plenty of SAP and COBOL around, to make more money, and feel miserable at the same time :-)

[TheNewsIsHere]

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.

[janmatejka]

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

[intelVISA]

> GraphQL absolutely feels like a technological solution to an organizational problem

Because it is :')