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

GraphQL: The enterprise honeymoon is over

johnjames.blog

Post reply on HN
Print view View original

21–30 of 241 posts

Re: GraphQL: The enterprise honeymoon is over

#21

Post by n_e »

johnjames4214 wrote: post #7
fcpguru wrote: post #6

Earlier quoted context omitted.

yeah tell shopify, it's their api!

Exactly. If it's that verbose and painful for a public API like Shopify/GitHub (where the 'flexibility' argument is strongest), it makes even less sense for internal enterprise apps. We are paying that same complexity tax you described, but without the benefit of needing to support thousands of unknown 3rd-party developers.

The issue is that the API itself is, I assume, badly designed.

Equivalent delete queries in rest / graphql would be

  curl -X DELETE 'https://api.example.com/users/123'
vs

  curl 'https://api.example.com/graphql?query={ deleteUser(id: 123) { id } }'

Re: GraphQL: The enterprise honeymoon is over

#22

Post by timcobb »

> The main problem GraphQL tries to solve is overfetching.

this gets repeated over and over again, but if this your take on GraphQL you def shouldn't be using GraphQL, because overfetching is never such a big problem that would warrant using GraphQL.

In my mind, the main problem GraphQL tries to solve is the same "impedance mismatch" that ORMs try to solve. ORM's do this at the data level fetching level in the BE, while GraphQL does this in the client.

I also believe that using GraphQL without a compiler like Relay or some query/schema generation tooling is an anti-pattern. If you're not going to use a compiler/query generation tool, you probably won't get much out of GraphQL either.

In my opinion, GraphQL tooling never panned out enough to make GraphQL worthwhile. Hasura is very cool, but on the client side, there's not much going on... and now with AI programming you can just have your data layers generated bespoke for every application, so there's really no point to GraphQL anymore.

Re: GraphQL: The enterprise honeymoon is over

#23

Post by verdverm »

I have strong agreement here and would add reasoning about auth flow through nested resolvers is one of the biggest challenges because it adds so much mental overhead. The reason is that a resolver may be called through completely different contexts and you have to account for that

The complexity and time lost to thinking is just not worth it, especially once you ship your GarphQL app to production, you are locking down the request fields anyway (or you're keeping yourself open for more pain)

I even wrote a zero-dependency auth helpers package and that was not enough for me to keep at it

https://github.com/verdverm/graphql-autharoo

Like OP says, pretty much everything GraphQL can do, you can do better without GraphQL

Re: GraphQL: The enterprise honeymoon is over

#24

Post by jayd16 »

gavinray wrote: post #17

I'm probably about as qualified to talk about GraphQL as anyone on the internet: I started using it in late 2016, back when Apollo was just an alternate client-side state/store library. The internet at large seems to have a fundamental misunderstanding about what GraphQL is/is not. Put simply: GQL is an RPC spec that is essentially implemented as a Dict/Key-Value Map on the server, of the form: "Action(Args) -> Resul…

This seems a bit reductive as it skims over the whole query resolution part entirely.

Re: GraphQL: The enterprise honeymoon is over

#25

Post by ericyd »

gavinray wrote: post #17

I'm probably about as qualified to talk about GraphQL as anyone on the internet: I started using it in late 2016, back when Apollo was just an alternate client-side state/store library. The internet at large seems to have a fundamental misunderstanding about what GraphQL is/is not. Put simply: GQL is an RPC spec that is essentially implemented as a Dict/Key-Value Map on the server, of the form: "Action(Args) -> Resul…

Is this relevant to the posted article? I don't see how the OP misrepresents anything about GQL.

Re: GraphQL: The enterprise honeymoon is over

#26

Post by verdverm »

jayd16 wrote: post #24
gavinray wrote: post #17

I'm probably about as qualified to talk about GraphQL as anyone on the internet: I started using it in late 2016, back when Apollo was just an alternate client-side state/store library. The internet at large seems to have a fundamental misunderstanding about what GraphQL is/is not. Put simply: GQL is an RPC spec that is essentially implemented as a Dict/Key-Value Map on the server, of the form: "Action(Args) -> Resul…

This seems a bit reductive as it skims over the whole query resolution part entirely.

Which is where the real complexity comes in

Re: GraphQL: The enterprise honeymoon is over

#27

Post by mohas »

using graphql specifically Apollo was one of my regrettable decisions when I was designing a system 3 years ago, one that haunts me still today with wired bugs, too much effort to upgrade the version while prev version still have bugs etc. and I lost performance and simplicity of rest on top of that

Re: GraphQL: The enterprise honeymoon is over

#28

Post by ericyd »

storafrid wrote: post #20

A blog post about GraphQL in an enterprise setting, that fails to address the biggest GQL feature for enterprises. Not unlike most material on HN about microservices. Federated supergraph is the killer feature imo.

The author states that in their experience, most downstream services are REST, so adding a GQL aggregation layer on top isn't very helpful. It seems possible they would have a different opinion if they were working with multiple services that all implemented GQL schemas.

Re: GraphQL: The enterprise honeymoon is over

#29

Post by verdverm »

hjnilsson wrote: post #18
hn_throwaway_99 wrote: post #12

> The main problem GraphQL tries to solve is overfetching. My issue with this article is that, as someone who is a GraphQL fan, that is far from what I see as its primary benefit, and so the rest of the article feels like a strawman to me. TBH I see the biggest benefits of GraphQL are that it (a) forces a much tighter contract around endpoint and object definition with its type system, and (b) schema evolution is muc…

Agree whole-heartedly. The strong contracts are the #1 reason to use GraphQL. The other one I would mention is the ability to very easily reuse resolvers in composition, and even federate them. Something that can be very clunky to get right in REST APIs.

re:#1 Is there a meaningful difference between GraphQl and OpenAPI here?

Composed resolvers are the headache for most and not seen as a net benefit, you can have proxied (federated) subsets of routes in REST, that ain't hard at all

Post reply on HN