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

221–230 of 241 posts

Re: GraphQL: The enterprise honeymoon is over

#221

Post by Dibes »

hashmap wrote: post #220
Dibes wrote: post #57

Earlier quoted context omitted.

If isomorphic TS is your cup of tea, tRPC is a nicer version of client server contracting than graphql in my opinion. Both serve that problem quite well though.

I do like the look of this! It seems like it nicely provides that without like kicking you into React, which I have ended up having to draw a hard line against in development after my first couple experiences not only with it, but how the distributions in AI models make it a real trap to touch. I'll swap this in in one of my projects and give it a go. Thanks!

No problem! I hope you have a good time with it!

Re: GraphQL: The enterprise honeymoon is over

#222

Post by verdverm »

girvo wrote: post #110
fgkramer wrote: post #60

Earlier quoted context omitted.

But has this been thoroughly documented and are there solid libraries to achieve this? My understanding is that this is not part of the spec and that the only way to achieve this is to sign/hash documents on clients and server to check for correctness

I mean yeah, in that Persisted Queries are absolutely documented and expected in production on the Relay side, and you’re a hop skip and jump away from disallowing arbitrary queries at that point if you want to Though you still don’t need to and shouldn’t. Better to use the well defined tools to gate max depth/complexity.

All these extra requirements are why GraphQL never really captured enough mindshare to be a commonly selected tool

Re: GraphQL: The enterprise honeymoon is over

#223

Post by verdverm »

JasonSage wrote: post #160
verdverm wrote: post #73

Earlier quoted context omitted.

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.

People can still draw generalizations about a piece of technology that hold true regardless context or problem fit

One of those conclusions is that GraphQL is more complex than REST without commensurate ROI

Re: GraphQL: The enterprise honeymoon is over

#224

Post by verdverm »

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…

GitHub search is among the worst out there, is this why?

Re: GraphQL: The enterprise honeymoon is over

#225

Post by hdjrudni »

fastball wrote: post #184
hn_throwaway_99 wrote: post #49

Earlier quoted context omitted.

You're misunderstanding. In GraphQL, the server prunes the response object. That is, the resolver method can return a "fat" object, but only the object pruned down to just the requested fields is returned over the wire. It is an important security benefit, because one common attack vector is to see if you can trick a server method into returning additional privileged data (like detailed error responses).

"Just the requested fields" as requested by the client? Because if so that is no security benefit at all, because I can just... request the fat fields.

I wanted to refute you but you're right. It's not a security benefit. With GQL the server is supposed to null out the fields that the user doesn't have access to, but that's not automagic or an inherent benefit to GQL. You have the same problem with normal REST. Or maybe less so because you just wouldn't design the response with those extra fields; you'd probably build a separate 'admin' or 'privileged' endpoint which is easier to lock down as a whole rather than individual fields.

Re: GraphQL: The enterprise honeymoon is over

#226

Post by hdjrudni »

hamandcheese wrote: post #200
8n4vidtmkvmk wrote: post #35

Earlier quoted context omitted.

Pruning the request and even the response is pretty trivial with zod. I wouldn't onboard GQL for that alone. Not sure about the schema evolution part. Protobufs seem to work great for that.

In my (now somewhat dated) graphql experience, evolving an API is much harder. Input parameters in particular. If a server gets inputs it doesn't recognize, or if client and server disagree that a field is optional or not (even if a value was still supplied for it so the question is moot), the server will reject the request.

> If a server gets inputs it doesn't recognize

If you just slap in Zod, the server will drop the extra inputs. If you hate Zod, it's not hard to design a similar thing.

> or if client and server disagree that a field is optional or not

Doesn't GQL have the concept of required vs optional fields too? IIUC it's the same problem. You just have to be very diligent about this, not really a way around it. Protobufs went as far as to remove 'required' out of the spec because this was such a common problem. Just don't make things required, ever :-)

Re: GraphQL: The enterprise honeymoon is over

#227

Post by c-hendricks »

0x696C6961 wrote: post #209
c-hendricks wrote: post #194

Earlier quoted context omitted.

Your response is incredibly anecdotal (as is mine absolutely), and misleading. GQL paved the way for a lot of ergonomics with our microservices. And there's nothing stopping you from just adding pagination arguments to a field and handling them. Kinda exactly how you would in any other situation, you define and implement the thing.

Yeah I love it when a request turns into an N+1 query because the FE guys needed 1 more field.

What's that old saying, "fool me once ..."

Re: GraphQL: The enterprise honeymoon is over

#228

Post by mands »

We've just moved to GraphQL after using REST and bog-standard RPC, and it's been a breath of fresh air. I was considering building my own HTTP RPC system, similar to json-rpc or open-rpc, but I would have ended up with a poorly-specified GraphQL clone.

I think GraphQL's biggest issue is a naming and positioning problem. I, along with colleagues, thought for a long time that it was tied to graphs, DB query languages, and heavy backend implementations.

It's actually a typed RPC system designed for Client UIs, including SPAs and mobile. We're using it with a monolith in a code-first manner, where the schema and client code are auto-generated from backend types.

I think the project could benefit from a `graphql-lite` / `graphql-full` split, where `-lite` includes a well-documented, leaner core featureset (RPC, simple resolvers), and full mode includes federation.

Re: GraphQL: The enterprise honeymoon is over

#229

Post by girvo »

verdverm wrote: post #222
girvo wrote: post #110

Earlier quoted context omitted.

I mean yeah, in that Persisted Queries are absolutely documented and expected in production on the Relay side, and you’re a hop skip and jump away from disallowing arbitrary queries at that point if you want to Though you still don’t need to and shouldn’t. Better to use the well defined tools to gate max depth/complexity.

All these extra requirements are why GraphQL never really captured enough mindshare to be a commonly selected tool

> GraphQL never really captured enough mindshare to be a commonly selected tool

It has been, at the scale it matters and should be used at. Most companies don't operate at that scale though.

Re: GraphQL: The enterprise honeymoon is over

#230

Post by adsharma »

FrustratedMonky wrote: post #212
adsharma wrote: post #129

Earlier quoted context omitted.

Cypher tries to solve problems closer to storage. GraphQL was designed to add types and remote data fetching abstractions to a large existing PHP server side code base. Cypher is designed to work closer to storage, although there are many implementations that run cypher on top of anything ("table functions" in ladybug). Neo4j's implementation of cypher didn't emphasize types. You had a relatively schemaless design th…

Got it. I didn't realize. Checking out the docs, looks like GQL is based on Cypher. So in the thread people were talking about it, just calling it GQL as the common name, not Cypher as the original name and I missed it. GQL-SQL - for queries. GraphQL, more for REST??

GQL is related to Cypher, but not a common name for Cypher.

https://www.tigergraph.com/glossary/cypher-query-language/ https://www.tigergraph.com/blog/the-rise-of-gql-a-new-iso-st...

Has some history behind it.

Syntax and some queries:

https://github.com/opengql/grammar/tree/main/samples

Full specification costs you about $270

Post reply on HN