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

151–160 of 241 posts

Re: GraphQL: The enterprise honeymoon is over

#151

Post by WickyNilliams »

hokkos wrote: post #147
WickyNilliams wrote: post #131

Earlier quoted context omitted.

This is very much possible, and I have done it, and it works great once it's all wired up. But OpenAPI is verbose to the point of absurdity. You can't feasibly write it by hand. So you can't do schema first development. You need an open API compatible lib for authoring your API, you need some tooling to generate the schema from the code, then you need another tool to generate types from the schema. Each step tends to…

I use https://typespec.io to generate openapi, writing openapi yaml quickly became horrible past a few apis.

Ha yes, see one of my other comments to another reply.

I never got to use it when I last worked with OpenAPI but it seemed like the antidote to the verbosity. Glad to hear someone had positive experience with it. I'll definitely try it next time I get the chance

Re: GraphQL: The enterprise honeymoon is over

#152

Post by bastawhiz »

lateforwork wrote: post #62
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…

If you generate TypeScript types from OpenAPI specs then you get contracts for both directions. There is no problem here for GraphQL to solve.

tRPC sort of does this (there's no spec, but you don't need a spec because the interface is managed by tRPC on both sides). But it loses the real main defining quality of gql: not needing subsequent requests.

If I need more information about a resource that an endpoint exposes, I need another request. If I'm looking at a podcast episode, I might want to know the podcast network that the show belongs to. So first I have to look up the podcast from the id on the episode. Then I have to look up the network by the id on the podcast. Now, two requests later, I can get the network details. GQL gives that to me in one query, and the fundamental properties of what makes GQL GQL are what enables that.

Yes, you can jam podcast data on the episode, and network data inside of that. But now I need a way to not request all that data so I'm not fetching it in all the places where I don't need it. So maybe you have an "expand" parameter: this is what Stripe does. And really, you've just invented a watered down, bespoke GraphQL.

Re: GraphQL: The enterprise honeymoon is over

#153

Post by lateforwork »

bastawhiz wrote: post #152
lateforwork wrote: post #62

Earlier quoted context omitted.

If you generate TypeScript types from OpenAPI specs then you get contracts for both directions. There is no problem here for GraphQL to solve.

tRPC sort of does this (there's no spec, but you don't need a spec because the interface is managed by tRPC on both sides). But it loses the real main defining quality of gql: not needing subsequent requests. If I need more information about a resource that an endpoint exposes, I need another request. If I'm looking at a podcast episode, I might want to know the podcast network that the show belongs to. So first I ha…

Is dealing with GQL easier than implementing a BFF? There may be cases where that is true, but it is not always true.

Re: GraphQL: The enterprise honeymoon is over

#154

Post by hn_throwaway_99 »

jakubriedl wrote: post #150
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…

I 100% agree that overfetching isn't the main problem graphql solves for me. I'm actually spending a lot of time in rest-ish world and contract isn't the problem I'd solve with GraphQL either. For that I'd go through OpenAPI, and it's enforcement and validation. That is very viable these days, just isn't a "default" in the ecosystem. For me what GraphQL solves as main problem, which I haven't got good alternative for…

Completely agree with this rationale too. GraphQL does encapsulation really, really well. The client just knows about a single API surface, but the implementation about which actual backend services are handling the (parts of each) call is completely hidden.

On a related note, this is also why I really dislike those "Hey, just expose your naked DB schemas as a GraphQL API!" tools. Like the best part about GraphQL is how it decouples your API contract from backend implementation details, and these tools come along and now you've tightly coupled all your clients to your DB schema. I think it's madness.

Re: GraphQL: The enterprise honeymoon is over

#155

Post by tomnipotent »

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…

Facebook had started bifurcating API endpoints to support iOS vs Android vs Web, and overtime a large number of OS-specific endpoints evolved. A big part of their initial GraphQL marketing was to solve for this problem specifically.

Re: GraphQL: The enterprise honeymoon is over

#156

Post by iterateoften »

0x696C6961 wrote: post #139
iterateoften wrote: post #124

Earlier quoted context omitted.

So make things more complicated than gql?

gql is clearly the more complicated of the two ...

a gql server in python is about as simple as you can possibly go to exposing data via an API. You can use a raw http client to query it.

Re: GraphQL: The enterprise honeymoon is over

#157

Post by [deleted] »

hirsin wrote: post #130
verdverm wrote: post #23

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

Authz overhead for graphql is definitely a problem. At GitHub we're adding github app support to the enterprise account APIs, meaning introducing granular permissions for each graphql resource type. Because of the graph aspect, queries don't work til all of the underlying resources have been updated to support github apps. From a juice vs squeeze perspective it's terrible - lots of teams have to do work to update the…

[deleted]

Re: GraphQL: The enterprise honeymoon is over

#158

Post by languagehacker »

Production-Ready GraphQL is a pretty good read for anyone who needs to familiarize themselves with enterprise issues associated with GraphQL.

My favorite saying on this subject is that any sufficiently expressive REST API takes on GraphQL-like properties. In other words, if you're planning on a complex API, GraphQL and its related libraries often comes with batteries-included conventions for things you're going to need anyway.

I also like that GraphQL's schema-driven approach allows you to make useful declarations that can also be utilized in non-HTTP use cases (such as pub/sub) and keep much of the benefits of predictability.

IMO the main GraphQL solutions out there should have richer integrations into OpenTelemetry so that many of the issues the author raises aren't as egregious.

Many of the struggles people encounter with the GraphQL and React stack is that it's simply very heavyweight for many commodity solutions. Much as folks are encouraging just going the monorepo route these days, make sure that your solution can't be accommodated by server-side rendering, a simple REST API, and a little bit of vanilla JS. It might get you further than you think!

Re: GraphQL: The enterprise honeymoon is over

#159

Post by bastawhiz »

lateforwork wrote: post #153
bastawhiz wrote: post #152

Earlier quoted context omitted.

tRPC sort of does this (there's no spec, but you don't need a spec because the interface is managed by tRPC on both sides). But it loses the real main defining quality of gql: not needing subsequent requests. If I need more information about a resource that an endpoint exposes, I need another request. If I'm looking at a podcast episode, I might want to know the podcast network that the show belongs to. So first I ha…

Is dealing with GQL easier than implementing a BFF? There may be cases where that is true, but it is not always true.

I think BFF works at a small scale, but that's true with any framework. Building a one off handful of endpoints will always be less work than putting a framework in place and building against it.

GQL has a pretty substantial up front cost, undeniably. But you hopefully balance that with the benefit you'd get from it.

Re: GraphQL: The enterprise honeymoon is over

#160

Post by JasonSage »

verdverm wrote: post #73
JasonSage wrote: post #71

Earlier quoted context omitted.

> 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 Right, so if you take away the resolver composition (this is graph composition and not route federation), you can do the same things with a similar amount of effort in REST. This is no longer a GraphQL vs REST conversation, it's an acknowledgement that if you…

There are pros & cons to GraphQL resolver composition, not just benefits. It is that very compositional graph resolving that makes many see it as overly complex, not as a benefit, but as a detriment. You seem to imply that the benefit is guaranteed and that graph resolving cannot be done within a REST handler, which it can be, but it's much simpler and easier to reason about. I'm still going to go get the same data,…

Local non-utility does not imply global non-value. Of course there's costs and benefits, but it's hard to have a conversation with good-faith comparison using "many see it as overly complex" -- this is an analysis that completely ignores problem-fit, which you then want to generalize onto all usage.
Post reply on HN