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

171–180 of 241 posts

Re: GraphQL: The enterprise honeymoon is over

#171

Post by makeitdouble »

WickyNilliams wrote: post #142
0x696C6961 wrote: post #134

Earlier quoted context omitted.

I write all of my openapi specs by hand. It's not hard.

I imagine you are very much in the minority. A simple hello world is like a screen full of yaml. The equivalent in graphql (or typespec which I always wanted to try as an authoring format for openapi https://typespec.io/ ) would be a few lines

I see your point, yet writing openapi specs by hand is pretty common.

There is the part where dealing with another tool isn't much worth it most of the time, and the other side where we're already reading/writing screens of yaml or yaml like docs all the time.

Taking time to properly think about and define an entry point is reasonable enough.

Re: GraphQL: The enterprise honeymoon is over

#172

Post by rbalicki »

girvo wrote: post #108
rbalicki wrote: post #86

The author is missing the #1 benefit of GraphQL: the ability to compose (the data for) your UI from smaller parts. This is not surprising: Apollo only recently added support for data masking and fragment colocation, but it has been a feature of Relay for eternity. See https://www.youtube.com/watch?v=lhVGdErZuN4 for the benefits of this approach: - you can make changes to subcomponents without worrying about affecting…

Quite. Apollo Client is the problem, IMO, not GraphQL. Though Relay still needs to work on their documentation: Entrypoints are so excellent and yet still are basically bare API docs that sort of rely on internal Meta shit

100% agree on the unnecessary connection between entrypoints and meta internals. I think this is one of the biggest misses in Relay, and severely limits its usefulness in OSS.

If you're interested in entrypoints without the Meta internals, you may be interested in checking out Isograph (which I work on). See e.g. https://isograph.dev/docs/loadable-fields/, where the data + JS for BlogBody is loaded afterward, i.e. entrypoints. It's as simple as annotating a field (in Isograph, components define fields) with @loadable(lazyLoadArtifact: true).

Re: GraphQL: The enterprise honeymoon is over

#173

Post by JAlexoid »

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

Earlier quoted context omitted.

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.

You still require gql requests to deal with. There's pretty much the same amount of code to build in BFF as it is to build the same in GQL... and probably less code on the frontend.

The value of GQL is pretty much equivalent to SOA orchestration - great in theory, just gets in the way in practice.

Oh and not to mention that GQL will inadvertently hide away bad API design(ex. lack of pagination).. until you are left questioning why your app with 10k records in total is slow AF.

Re: GraphQL: The enterprise honeymoon is over

#174

Post by JAlexoid »

bakugo wrote: post #166
0x696C6961 wrote: post #144

Earlier quoted context omitted.

No it doesn't

Did you see the repo? https://github.com/kubb-labs/kubb Most of the commits and pull requests are AI. Issues are also seemingly being handled by AI with minimal human intervention.

AI assisted, not necessarily generated.

And yes, current models are amazing at reducing time it takes to push out a feature or fix a bug. I wouldn't even consider working at a company that banned use of AI to help me write code.

PS: It's also irrelevant to whether it's AI generated or not, what matters is if it works and is secure.

Re: GraphQL: The enterprise honeymoon is over

#175

Post by JAlexoid »

hn_throwaway_99 wrote: post #49
FootballMuse wrote: post #37

Earlier quoted context omitted.

Pruning a response does nothing since everything still goes across the network

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).

I would like to remind you that in most cases the GQL is not colocated on the same hardware as the services it queries.

Therefore requests between GQL and downstream services are travelling "over the wire" (though I don't see it as an issue)

Having REST apis that return only "fat" objects is really not the most secure way of designing APIs

Re: GraphQL: The enterprise honeymoon is over

#176

Post by rbalicki »

akio wrote: post #53

If all your experience comes from Apollo Client and Apollo Server, as the author's does, then your opinion is more about Apollo than it is about GraphQL. You should be using Relay[0] or Isograph[1] on the frontend, and Pothos[2] on the backend (if using Node), to truly experience the benefits of GraphQL. [0]: https://relay.dev/ [1]: https://isograph.dev/ [2]: https://pothos-graphql.dev/

Incidentally, v0.5.0 of Isograph just came out! https://isograph.dev/blog/2025/12/14/isograph-0.5.0/ There are lots of DevEx wins in this release, such as the ability to create have an autofix create fields for you. (In Isograph, these would be client fields.)

Re: GraphQL: The enterprise honeymoon is over

#177

Post by JAlexoid »

scotty79 wrote: post #141
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…

> when a server receives an input object, that object will conform to the type Anything that comes from the front end can be tampered with. Server is guaranteed nothing. > GraphQL always prunes return objects to just the fields requested, which most other API tech doesn't do, and this can be a really nice security benefit. Request can be tampered with so there's additional security from GraphQL protocol. Security mus…

Expecting GraphQL to handle security is really one of the poorest ways of doing security, as GQL is not designed to do that.

Re: GraphQL: The enterprise honeymoon is over

#178

Post by mixedCase »

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.

If you generate OpenAPI specs, and clients, and server type definitions from a declarative API definition made with Effect's own @effect/platform, it solves even more things in a nicer, more robust fashion.

Re: GraphQL: The enterprise honeymoon is over

#179

Post by JAlexoid »

timcobb wrote: post #22

> 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, wh…

> 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.

How is this easier or faster than writing a few lines of code at BFF?

Re: GraphQL: The enterprise honeymoon is over

#180

Post by bakugo »

JAlexoid wrote: post #174
bakugo wrote: post #166

Earlier quoted context omitted.

Did you see the repo? https://github.com/kubb-labs/kubb Most of the commits and pull requests are AI. Issues are also seemingly being handled by AI with minimal human intervention.

AI assisted, not necessarily generated. And yes, current models are amazing at reducing time it takes to push out a feature or fix a bug. I wouldn't even consider working at a company that banned use of AI to help me write code. PS: It's also irrelevant to whether it's AI generated or not, what matters is if it works and is secure.

> what matters is if it works and is secure.

How do you know it works and is secure if a lot of the code likely hasn't ever been read and understood by a human?

Post reply on HN