Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

After 6 years, I'm over GraphQL

bessey.dev

Post reply on HN
Print view View original

711–720 of 721 posts

Re: After 6 years, I'm over GraphQL

#711

Post by janmatejka »

TheNewsIsHere wrote: post #659
burutthrow1234 wrote: post #397

Earlier quoted context omitted.

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 insc…

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…

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

Re: After 6 years, I'm over GraphQL

#712

Post by pas »

albertgoeswoof wrote: post #515
pas wrote: post #495

Earlier quoted context omitted.

Can you elaborate on lack of syntax docs? As far as I understand one of the big big huugge benefits of GraphQL is that you get the strongly typed schema via the introspection query, so you can build queries with some confidence, that as long as the schema (version) is the same it should be syntactically okay. What did Spotify do compared to this?

This is one of the problems with graphql, there are no docs because the schema is all you need. But that assumes the schema is logical and consistent, which it rarely is. It also means you need to be an expert in the tooling to figure it out, so just dropping in to a graphql api is so frustrating compared to plain old rest

this was also the problem with WSDL and REST itself, and so on. of course there are things that make sense to be in-band .. but there are things that have to be communicated out-of-band (just as REST doesn't say anything about what to do with a specific content type OpenAPI and GraphQL doesn't worth much with empty description fields, though I'd argue still much better than getting a .doc file named API_doc-Finalv2(1) :) )

Re: After 6 years, I'm over GraphQL

#713

Post by otabdeveloper4 »

FridgeSeal wrote: post #662
otabdeveloper4 wrote: post #645

Earlier quoted context omitted.

1. No reliable way to delete already processed entries. 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.)

I wouldn’t have really called these issues “broken by design”… Rough edges sure. No reliable way to delete processed messages. Well, who’s to say they were processed? It’s a persistent queue, stuff sticks around by construction. Besides, this can be managed with tombstones and turning on compaction for that topic. How would you want to “handle” queue overflow? You’ve either got storage space, or you don’t, this feels…

> Well, who’s to say they were processed?

The queue, which should keep a reference count for messages.

> How would you want to “handle” queue overflow?

At the producer end, of course.

> You’ve either got storage space, or you don’t

Kafka assumes you have infinite storage space. That might be okay for toy projects or for the insane architectures you see in the enterprise space, but not for a serious project.

Re: After 6 years, I'm over GraphQL

#715

Post by jhatemyjob »

nprateem wrote: post #632
jhatemyjob wrote: post #561

Earlier quoted context omitted.

Yeah that's what I'm saying, it shouldn't be surprising, these delusions last entire careers. Look at all the people who base their career on Java

I just picked java up again recently and it's really OK now. I'd have used it for my project but spring boot doesn't have an auto-generated admin like django so I binned it.

The Java thing was a joke lol.

Re: After 6 years, I'm over GraphQL

#716

Post by julik »

joshstrange wrote: post #374

I bought into the hype and I feel bad for the company where I implemented it. One true endpoint to rule them all and cause endless headaches in the process. With most tech that I screw up I assume that "I wasn't using it right" but with GraphQL I'm not sure how anyone could. The permissions/auth aspect alone is a nightmare. Couple that with potential performance issues (N+1 or just massive amounts of data) and I want…

"What if I told you that 99% of GraphQL can be replaced with a QUERY HTTP call with an {"ids": [123, 456, ...]} in the request body?.."

Re: After 6 years, I'm over GraphQL

#717

Post by ttfkam »

danielheath wrote: post #709
ttfkam wrote: post #668

Earlier quoted context omitted.

Hasura and Postgraphile are quite performant. No complaints there. And you can both put queries on an allow list, control max query depth, and/or throttle on query cost.

> put queries on an allow list, control max query depth, and/or throttle on query cost. All of which are features which give you some way to respond to the performance issues you avoid by planning your API up-front.

None of those are automatic. Any API you write still has to remember to put in LIMIT clauses, to avoid OFFSET. And then you have to actually write the API rather than have it generated for you.

There are no free lunches, especially with regard to security and sanity checks.

Re: After 6 years, I'm over GraphQL

#718

Post by culi »

koito17 wrote: post #516
culi wrote: post #470

Earlier quoted context omitted.

Just a couple nitpicks * openapi was basically nonexistent when GQL came out. It certainly wasn't "the tool they were trying to replace" * Postgres and GQL are not in any way mutually exclusive * Today, openapi is still tiny compared to GQL. At least as measured by StackOverflow question tags: https://trends.stackoverflow.co/?tags=graphql,openapi,soap,m...

Stack Overflow trends isn't really a good metric, but setting that aside, you need to sum the time series for Swagger and OpenAPI. There's still plenty of people who call OpenAPI 3.0 "Swagger". And strictly speaking, Swagger is "OpenAPI 2.0".

Good point, thanks!

Re: After 6 years, I'm over GraphQL

#719

Post by hot_gril »

RedShift1 wrote: post #598
hot_gril wrote: post #299

Earlier quoted context omitted.

OpenAPI can do graphs too, since you can put in refs to objects that can themselves have refs to other objects, possibly recursively.

At that point you've recreated the exact same problems many here are complaining about, N+1, authorization on leaf nodes, ability for the client to create queries that are hard to optimize, etc...

The client doesn't create queries in this situation, you explicitly define them server-side. So optimization is easier. I've seen this time and again with services that aren't GraphQL but tried to provide a semi-freeform query feature; if you only have a few clients and control them all, it's way easier to just make separate endpoints for whatever they need. If you have many clients, maybe GraphQL makes sense.

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

Post reply on HN