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

391–400 of 721 posts

Re: After 6 years, I'm over GraphQL

#391

Post by yCombLinks »

azangru wrote: post #180
diggan wrote: post #158

Earlier quoted context omitted.

> [0] https://blogs.windows.com/msedgedev/2024/05/28/an-even-faste... Maybe I'm missing something obvious, but React isn't mentioned in that post. Maybe you put the wrong URL?

Odd, I thought I saw something about React in Microsoft's communications as well. Anyway, here is the horse's mouth: https://toot.cafe/@slightlyoff/112521248529973776

The options we have today are not the options we had at the time Facebook introduced React. React solved tons of browser shortcomings that are finally being fixed in the actual browser.

Re: After 6 years, I'm over GraphQL

#392

Post by unnouinceput »

I worked with CORBA during 90's and early 2000's. A truly shitty piece of technology that I do not wish upon my worst enemies, except maybe the higher ups at Microsoft who invented COM interfaces. When I saw the hype of GraphQL in 2017 I looked into it and while exploring it I started to have PTSD from CORBA days. "So you're the new CORBA, huh? I'll fuck off as far away as I can from you then" - and told the same to every client that even mention it.

Re: After 6 years, I'm over GraphQL

#393

Post by hosh »

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…

Hmm. I wonder if there is some kind of query builder that can live server-side. That is, capture the flexibility of a query language when developing, and then consolidating that when going into production.

Though I guess you can do that with REST too.

I'm currently exploring all of this myself. I have a side project in mind that can use a graph db, and I thought a front-end graphql can work well with a graphdb backend. I was not sure why this pattern is not more popular, but reading all of this now, I'm seeing where these problems may arise.

A graph db backend can use efficient graph search algorithms, especially for deeply nested data, but the issue with authorization is still there. If anything, fine-grained authorization is something better represented with graph dbs than with relational databases.

Re: After 6 years, I'm over GraphQL

#394

Post by hansonkd »

WorldMaker wrote: post #381
hansonkd wrote: post #231

Earlier quoted context omitted.

I guess depending on the context of a simple app one level could be viewed as far. Any more levels and you have now reinvented GraphQL

OData existed before GraphQL in the wild, it's possible to suggest GraphQL reinvented OData. https://www.odata.org/

The point is GQL is currently the standard for querying dynamic nested data shapes not that it is the first or was the first.

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.

Re: After 6 years, I'm over GraphQL

#395

Post by dventimihasura »

mst wrote: post #347
dventimihasura wrote: post #290

Earlier quoted context omitted.

PostGraphile compiles GraphQL directly to SQL. The SQL is "custom" in that it's specific to the GraphQL operation, though naturally it does follow rules. For example, Hasura does the same thing, and among the rules that it follows is that it uses `LEFT LATERAL JOIN` between tables (at least, on PostgreSQL). Full disclosure, I work for Hasura, so I'm not super familiar with the style of SQL PostGraphile generates but…

> PostGraphile compiles GraphQL directly to SQL. The SQL is "custom" in that it's specific to the GraphQL operation Yes, that's why I said GraphQL and -corresponding- SQL, I was hoping to find something that showed me the SQL for each of half a dozen or a dozen examples ... though the debug option there will let me point the out-of-the-box CLI at a pre-existing database and have a look at as many examples as I like,…

Ahh, I see. Yeah, I suppose some examples in the docs would be nice.

Anyway, here's an example with Hasura:

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

Re: After 6 years, I'm over GraphQL

#396

Post by dventimihasura »

purge wrote: post #345
dventimihasura wrote: post #290

Earlier quoted context omitted.

PostGraphile compiles GraphQL directly to SQL. The SQL is "custom" in that it's specific to the GraphQL operation, though naturally it does follow rules. For example, Hasura does the same thing, and among the rules that it follows is that it uses `LEFT LATERAL JOIN` between tables (at least, on PostgreSQL). Full disclosure, I work for Hasura, so I'm not super familiar with the style of SQL PostGraphile generates but…

postgraphile v5 has significantly improved query generation ( https://postgraphile.org/postgraphile/next/ ) since moving to grafast ( https://grafast.org/grafast/ )

Nice!

Re: After 6 years, I'm over GraphQL

#397

Post by burutthrow1234 »

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…

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.

Re: After 6 years, I'm over GraphQL

#398

Post by hansonkd »

randomdata wrote: post #368
hansonkd wrote: post #355

Earlier quoted context omitted.

Because exposing your Database to the outside world is asinine. GQL sits between letting the frontend query semi-customizable queries and not having any customizability to select related resources.

Nobody said you should expose your database to the outside world. Do you not understand the difference between APIs and services?

You said

> The database will already have its own API

Where is this API coming from? You have to build it. I'm saying you should make those APIs graphql apis though a language framework and not REST apis because GQL consuming GQL is much better than GQL consuming REST.

Re: After 6 years, I'm over GraphQL

#399

Post by chuckadams »

moribvndvs wrote: post #323
chuckadams wrote: post #260

I must be the only one who found GraphQL, used it in a small project, and liked almost every bit of it. I used Apollo Client and graphql-codegen to generate types and functions for Vue 3, and nothing else could touch it. It wasn't all smooth sailing of course: I did find defining new scalar types to be fiddly, and I couldn't really even make proper use of union types, directives, or even enums due to the impedance mi…

After building several GraphQL-based applications, the design time experience and expressivity offered to UI developers particularly when the application is first starting out feels really great. But like the author, it sours quickly after that. I found myself spending a large amount of time inventing and trying to patch in solutions that most RPC and REST frameworks solved long ago for both the server AND the client…

> (auth, rate limiting, error handling and validation stick out particularly)

I got all that for free with API Platform because it's based on Symfony. Ironically it's the graphql implementation that's primitive [1] -- but rock solid, so it won out, and being a rank newbie at GQL when I started, it was probably best I was stuck with the basics.

The JS backend world is a lot more ad hoc than the modern PHP world, so I can picture a lot more nightmare integration scenarios there. Besides, I'd probably prefer using tRPC + zod for my next all-TS project.

--

[1] - It's actually pretty sophisticated underneath, but the code is a loosely-documented architectural maze, so yeah.

Post reply on HN