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

621–630 of 721 posts

Re: After 6 years, I'm over GraphQL

#621

Post by whitten »

strken wrote: post #160
friendzis wrote: post #147

Earlier quoted context omitted.

The problem with XML is precisely that it is so much more than simple hierarchical, nested trees of data. The fact that in a casual conversation XML is reduced to hierarchical trees of data pretending the rest of XML does not exist more than proves OP's point.

I'm not pretending anything and I hate XML. I would still rather use it than HL7, because it's a hierarchical tree of data and HL7 is not. OP's point is that almost nobody wants to use XML anymore; my point is that almost nobody wants a Ford Model T as their daily driver anymore either, and yet it was still the future, in a certain sense.

Do you think FHIR is acceptable?

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

Re: After 6 years, I'm over GraphQL

#622

Post by aprilthird2021 »

BiteCode_dev wrote: post #95
zer00eyz wrote: post #2

GraphQL is the peanut butter to Reacts chocolate at FB. It works there because 1. Every user is logged in. Is there anything you can do at FB without giving up something to the Zuck? 2. Because it's all behind a login, you can front load the first login/request with a giant SPA and then run all the custom queries you want. 3. everything at FB is some sort of blended context (my user, someone else's user, a permission…

No, GraphQL makes sense at facebook because at their scale, dealing with the consequence of allowing all possible queries was less work that having to create dedicated enpoints for all the possible client queries. People completely missed the point of GraphQL, which is you TRADE flexibility for the client for added cost on the server. Which in a app and team as huge as facebooks' made sense, especially since they hav…

> People completely missed the point of GraphQL, which is you TRADE flexibility for the client for added cost on the server.

I mean, isn't this THE selling point of GraphQL? How was it missed so badly? I think every elementary resource about the technology covers this in the pros and cons section...

Re: After 6 years, I'm over GraphQL

#624

Post by dclowd9901 »

scubbo wrote: post #311
tossandthrow wrote: post #238

Earlier quoted context omitted.

Indeed, this is what graphQL solves. Are you proposing just to add new field to a JSON response, even though they are not needed?

GraphQL "solves" the ability to ignore an unneeded field in a response? Revolutionary.

Even in REST, I’m sure you don’t use every field from every request? In fact, such tight coupling between FE and BE in REST is strongly advised against. And “wasted fields” was never a problem graphql was trying to solve.

Re: After 6 years, I'm over GraphQL

#625

Post by bryanrasmussen »

arp242 wrote: post #370
bryanrasmussen wrote: post #332

Earlier quoted context omitted.

>And both these projects had clear signs of "learning-on-the-go" with loads of bad practices I think two projects having loads of bad practices is too small a dataset to really assume anything, you sort of need to see widespread "bad practices" in the tech to be able to determine that the bad practice is actually the norm practice and there is perhaps a flaw in the tech that encourages that norm.

You're not wrong, but at the same time I think it's a decent data point that getting it right is not straight-forward and that, practical speaking, you at the very least need to think very carefully before actually using it. "The idea of it" is sometimes fine, but then there's also "the practicality of it", and sometimes that's a very different thing. Remember the old microkernel vs. monolithic debate; everyone more…

I think one of the issues is actually that GraphQL has no specific implementation, it's not like you have an SQL database and that's it, so one thing is that when you are consuming a GraphQL api it is impractical for various implementation related reasons from the vendor.

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.

Re: After 6 years, I'm over GraphQL

#626

Post by hattmall »

ForHackernews wrote: post #476
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…

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

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

Re: After 6 years, I'm over GraphQL

#627

Post by sebmellen »

tango12 wrote: post #576

I’m the founder of Hasura - sharing some notes from how I’ve seen GraphQL usage evolve over the last few years. 1. GraphQL was and remains insanely hard to build without an underlying data layer that does the heavy lifting. Without projection push-down, predicate push-down, a data layer that can support heavy parallelism it’s untenable. Exactly the problems the OP highlights - needing to “hoist”… 2. GraphQL on REST i…

We built Yates (https://github.com/cerebruminc/yates) to solve the authz problem.

Yates implements Postgres RLS along with Prisma, which we use as our ORM, and then our GraphQL schema is generated using TypeGraphQL (https://typegraphql.com/). Overall, it's a very nice setup and allows us to be versatile on the client side while still having strong authentication integrity.

While perhaps not as polished as Hasura, this stack does have the nice benefit of being free ;-)

Re: After 6 years, I'm over GraphQL

#628

Post by tango12 »

cletus wrote: post #565

Former Facebooker here. I have some thoughts. IME I find that many people don't have the problems GraphQL is intended to solve. No shade to the author but, as one example, i don't see the word "fragment" mentioned anywhere in this post and fragments are a real issue with GraphQL. Let me explain the problem GraphQL actually solves. FB, as we know, is an incredibly large mobile app, possibly one of the largest in terms…

Counter-opinion:

I totally agree with the sentiment here, but disagree with the conclusion.

1. The rest of the world doesn't have facebooks data layer. Ergo, GraphQL is very hard for everyone who's not FB.

2. Turns out GraphQL is actually a really good data API. Whether it's a postgres/mongo/graph/REST data source. Because it's a great mid-point between something as flexible as SQL but as controlled as a REST API.

Here are 3 things that GraphQL is absolutely great at:

  - Select a 2 fields out of a 100 attributes in a data model? GraphQL is great.
  - Gradually deprecate an old field in a database and replace with a new one? GraphQL is great.
  - Want a flexible way to filter/join/paginate regardless of the underlying storage layer? GraphQL is great.
Other API formats suck at this.

Working with GraphQL ought to feel like you're working entirely with your database and sprinking the right bits of transform/validation/authz business logic and then the API that other teams can use is "free".

GraphQL is dying as a replacement to a REST API layer. I think GraphQL will see its second wind as a data API. Microsoft and Google announced their GraphQL data APIs recently.

GraphQL will probably only make sense when it's as close as a 1:1 map to a DB beneath it. Whether relational or NoSQL or graph.

In all other cases, the GraphQL juice is not worth the squeeze.

Re: After 6 years, I'm over GraphQL

#629

Post by tadfisher »

rezonant wrote: post #557
albertgoeswoof wrote: post #515

Earlier quoted context omitted.

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

Also there is no standard for exposing the schema, and sometimes there isn't a schema at all . Sometimes a vendor will have the schema downloadable from their dev docs, sometimes it will be an endpoint that serves it up, and sometimes they just don't give it to you and expect you to use GraphQL Explorer directly to discover what you can do. When I encountered this I figured surely GraphQL Explorer must be fetching th…

There is a standard, it's called GraphQL: https://spec.graphql.org/October2021/#sec-Schema-Introspecti...

I'm not saying the service isn't a true Scotsman, but a service that calls its API "GraphQL" but doesn't respond to introspection queries isn't really serving GraphQL.

Re: After 6 years, I'm over GraphQL

#630

Post by eYrKEC2 »

frabjoused wrote: post #423

For some reason every person I have worked with that pushed GraphQL seemed sufficiently obsessed with the idea of it that they prioritized its perceived elegance over the product we were trying to build. 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 tal…

Advocating for graphql as a red flag. I like it.
Post reply on HN