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

71–80 of 241 posts

Re: GraphQL: The enterprise honeymoon is over

#71

Post by JasonSage »

verdverm wrote: post #29
hjnilsson wrote: post #18

Earlier quoted context omitted.

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

> 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 don't want any of the benefits you won't get any of the benefits.

Re: GraphQL: The enterprise honeymoon is over

#72

Post by mansa10 »

EionRobb wrote: post #11

The article pretty much sums up why I've been a bigger fan of OData than GraphQL, especially in the business cases. OData will still let you get all those same wins that GraphQL does but without a sql-ish query syntax, and sticking to the REST roots that the web works better with. Also helps that lots of Microsoft services work out of the box with OData.

in my experience OData has several big issues:

- Overly verbose endpoint & request syntax: $expand, parenthesis and quotes in paths, actions etc.

- Exposes too much filtering control by default, allowing the consumer to do "bad things" on unindexed fields without steering them towards the happy path.

- Bad/lacking open source tooling for portals, mocks, examples, validation versus OpenAPI & graphQL.

It all smells like unpolished MS enterprise crap with only internal MS & SAP adoption TBH.

Re: GraphQL: The enterprise honeymoon is over

#73

Post by verdverm »

JasonSage wrote: post #71
verdverm wrote: post #29

Earlier quoted context omitted.

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

> 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, but with less complexity and reasoning overhead than using the resolver composition concept from GraphQL.

Is resolver composition really that different from function composition?

Re: GraphQL: The enterprise honeymoon is over

#74

Post by verdverm »

cluckindan wrote: post #61
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…

Have you tried using a decorator for auth? Also, using a proper GraphQL server and not composing it yourself from primitives is usually beneficial.

This was an auth extension or plugin for Apollo, forget what they called it.

Apollo shows up in the README and package.json, so I'm not sure why you are assuming I was not using a proper implementation

Re: GraphQL: The enterprise honeymoon is over

#75

Post by c-hendricks »

lateforwork wrote: post #70
c-hendricks wrote: post #68

Earlier quoted context omitted.

What about the whole "graph" part? Are there any openapi libraries that deal with that?

OpenAPI definition includes class hierarchy as well. You can use tools to generate TypeScript type definitions from that.

And the fetching in a single request?

Re: GraphQL: The enterprise honeymoon is over

#77

Post by p2detar »

We have a BFF and were considering for a while to go with GQL but eventually scrapped the idea: it seemed like a lot of work on the BE side.

But, we are quite constraint on resources, so now even the BFF seems to consume more and more BE development time. Now we are considering letting the FE use some sort of bridge to the BE's db layer in order to directly CRUD what it needs and therefore skip the BFF API. That db layer already has all sorts of validations in place. Because the BE is Java and the FE is js, it seems the only usable bridge here would be gRPC. Does anyone have any other ideas or has done anything in this direction?

Re: GraphQL: The enterprise honeymoon is over

#78

Post by mirekrusin »

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…

Except you can't have ie. union as argument, which means you can't construct ie. SQL/MongoDB-like where clauses.

Re: GraphQL: The enterprise honeymoon is over

#79

Post by HumanOstrich »

komali2 wrote: post #66
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.

Discovering Kubb was a game changer for me last year.

Thanks for mentioning this. I always find it unsettling when I've researched solutions for something and only find a better option from a random HN comment.

Site: https://kubb.dev/

Re: GraphQL: The enterprise honeymoon is over

#80

Post by ashishb »

throwaway613745 wrote: post #9
fcpguru wrote: post #3

i wrote this a few weeks ago: https://gist.github.com/andrewarrow/c75c7a3fedda9abb8fd1af14... 400 lines of QL vs one rest DELETE / endpoint

wut we have a mixed graphql/REST api at $DAY_JOB and our delete mutations look almost identical to our REST DELETE endpoints. TFA complains needing to define types (lol), but if you're doing REST endpoints you should be writing some kind of API specification for it (swagger?). So ultimately there isn't much of a difference. However, having your types directly on your schema is nicer than just bolting on a fragile ope…

Generate the open API spec from the backend for internal applications.

No need to update manually. Further, you can prevent breaking changes to the spec using oasdiff

Post reply on HN