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

191–200 of 241 posts

Re: GraphQL: The enterprise honeymoon is over

#191

Post by rbalicki »

etherfirma wrote: post #165

I don't agree with the author on most of this. GraphQL is far better than REST in almost every way and I disagree that the server side resolvers are somehow difficult to write. In a true enterprise setting, the federation capabilities are fantastic. There are plenty of things to dislike about GraphQL that he doesn't touch on, like: * lack of input type polymorphism * lack of support for map types * lack of support fo…

I would encourage you to write an educated person's critique of GraphQL, because OP's article + https://bessey.dev/blog/2024/05/24/why-im-over-graphql/ etc. suck up all of the oxygen, and no one hears about the genuine issues like that.

(And don't forget lack of generics, no support for interfaces with no fields, lack of closed unions/interfaces, the absolutely silly distinction between unions and interfaces, the fact that the SDL and operation language are two completely different things...)

Re: GraphQL: The enterprise honeymoon is over

#192

Post by devmor »

etherfirma wrote: post #165

I don't agree with the author on most of this. GraphQL is far better than REST in almost every way and I disagree that the server side resolvers are somehow difficult to write. In a true enterprise setting, the federation capabilities are fantastic. There are plenty of things to dislike about GraphQL that he doesn't touch on, like: * lack of input type polymorphism * lack of support for map types * lack of support fo…

> GraphQL is far better than REST in almost every way

I hear this so often, but never do I hear more than one or one and a half ways that it is better. No one seems capable of explaining how it's "better in almost every way" without diverging to very specific examples with cutout problems.

Re: GraphQL: The enterprise honeymoon is over

#193

Post by girvo »

rbalicki wrote: post #172
girvo wrote: post #108

Earlier quoted context omitted.

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

Neat! I basically just reimplemented some of the missing pieces myself, but honestly for the kind of non-work GraphQL/Relay stuff I do React Router with an entry point-like interface for routes (including children!) to feed in route params to loadQuery and the ref to the route itself got me close enough for my purposes

I’ll have a play though, sounds promising :)

Oh this is interesting, sort of seems like the relay-3d thing in some ways?

Re: GraphQL: The enterprise honeymoon is over

#194

Post by c-hendricks »

JAlexoid wrote: post #173
iterateoften wrote: post #156

Earlier quoted context omitted.

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

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.

Re: GraphQL: The enterprise honeymoon is over

#195

Post by rbalicki »

girvo wrote: post #193
rbalicki wrote: post #172

Earlier quoted context omitted.

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

Neat! I basically just reimplemented some of the missing pieces myself, but honestly for the kind of non-work GraphQL/Relay stuff I do React Router with an entry point-like interface for routes (including children!) to feed in route params to loadQuery and the ref to the route itself got me close enough for my purposes I’ll have a play though, sounds promising :) Oh this is interesting, sort of seems like the relay-3…

Yeah, you can get a lot of features out of the same primitive. The primitive (called loadable fields, but you can think of it as a tool to specify a section of a query as loaded later) allows you to support: - live queries (call the loadable field in a setInterval) - pagination (pass different variables and concatenate the result) - defer - loading data in response to a click

And if you also combine this with the fact that JS and fragments are statically associated in Relay, you can get: - entrypoints - 3D (if you just defer components within a type refinement, e.g. here we load ad items only when we encounter an item with typename AdItem https://github.com/isographlabs/isograph/blob/627be45972fc47.... asAdItem is a field that compiles to ... on AdItem in the actual query text)

And all of it is doable with the same set of primitives, and requiring no server support (other than a node field).

Do let me know if you check it out! Or if you get stuck, happy to unblock you/clarify things (it's hard for me to know what is confusing to folks new to the project.)

Re: GraphQL: The enterprise honeymoon is over

#196

Post by rbalicki »

devmor wrote: post #192
etherfirma wrote: post #165

I don't agree with the author on most of this. GraphQL is far better than REST in almost every way and I disagree that the server side resolvers are somehow difficult to write. In a true enterprise setting, the federation capabilities are fantastic. There are plenty of things to dislike about GraphQL that he doesn't touch on, like: * lack of input type polymorphism * lack of support for map types * lack of support fo…

> GraphQL is far better than REST in almost every way I hear this so often, but never do I hear more than one or one and a half ways that it is better. No one seems capable of explaining how it's "better in almost every way" without diverging to very specific examples with cutout problems.

You may be interested in checking out https://www.youtube.com/watch?v=lhVGdErZuN4, where I talk about the benefits of Relay. This isn't (currently) possible without GraphQL, so it's a pretty compelling case for GraphQL.

But yeah, IMO, GraphQL doesn't justify itself unless you're using a client like Relay, with data masking and fragment colocation.

Re: GraphQL: The enterprise honeymoon is over

#197

Post by marcus_holmes »

I ran a team a few years ago. The FE folks really wanted to use GraphQL, and the BE folks agreed, because someone had found an interesting library that made it easy. No-one had any experience of GraphQL before.

After a month's development I found out that there was one GraphQL call at the root of each React page, and it fetched all the data for that userID in a big JSON blob, that was then parsed into a JS object and used for the rest of the life of that page. Any updates sent the entire, modified, blob back to the server and the BE updated all the tables with the changed data. This didn't cause problems because users didn't share data or depend on shared data.

Everyone was happy because they got to put GraphQL on their resume. The application worked. We hit the required deadline. The company didn't get any traction with the application and we pivoted to something else very quickly, and was sold to private equity within two years. None of the code we wrote is running now, which is probably a good thing.

I get the feeling, from conversations with other people using GraphQL, that this is the sort of thing that actually happens in practice. The author's arguments make sense, as do the folks defending GraphQL. But I'd suggest that 80-90% of the GraphQL actually written and running out there is the kind of crap my team turned out.

Re: GraphQL: The enterprise honeymoon is over

#198

Post by rbalicki »

tcoff91 wrote: post #117
rbalicki wrote: post #88

Earlier quoted context omitted.

1000%. There's almost no reason to use GraphQL unless you take advantage of data masking + fragment colocation.

I have that with URQL+gql.tada. What else does relay give me that URQL does not?

I may be wrong on the details, but with URQL:

- you don't have a normalized cache. You may not want one! But if you find yourself annoyed that modifying one entity in one location doesn't automatically cause another view into that same entity to update, it's due to a lack of a normalized cache. And this is a more frequent problem than folks admit. You might go from a detail view to an edit view, modify a few things, then press the back button. You can't reuse cached data without a normalized cache, or without custom logic to keep these items in sync. At scale, it doesn't work.

- Since you don't have a normalized cache, you presumably just refetch instead of updating items in the cache. So you will presumably re-render an entire page in response to changes. Relay will just re-render components whose data has actually changed. In https://quoraengineering.quora.com/Choosing-Quora-s-GraphQL-..., the engineer at Quora points out that as one paginates, one can get hundreds of components on the screen. And each pagination slows the performance of the page, if you're re-rendering the entire page from root.

- Fragments are great. You really want data masking, and not just at the type level. If you stop selecting some data in some component, it may affect the behavior of other components, if they do something like Object.stringify or JSON.keys. But admittedly, type-level data masking + colocation is substantially better than nothing.

- Relay will also generate queries for you. For example, pagination queries, or refetch queries (where you refetch part of a tree with different variables.)

There are lots of great reasons to adopt Relay!

And if you don't like the complexity of Relay, check out isograph (https://isograph.dev), which (hopefully) has better DevEx and a much lower barrier to entry.

https://www.youtube.com/watch?v=lhVGdErZuN4 goes into more detail about the advantages of Relay

Re: GraphQL: The enterprise honeymoon is over

#199

Post by aitchnyu »

0x696C6961 wrote: post #134
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 write all of my openapi specs by hand. It's not hard.

Do you validate responses from client-side and server-side(Fastapi does this and prevents invalid responses from being sent) from spec?

Re: GraphQL: The enterprise honeymoon is over

#200

Post by hamandcheese »

8n4vidtmkvmk wrote: post #35
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…

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.
Post reply on HN