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

131–140 of 241 posts

Re: GraphQL: The enterprise honeymoon is over

#131

Post by WickyNilliams »

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.

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 implement the spec to varying degrees, creating gaps in types, or just outright failing.

Fwiw I tried many, many tools to generate the typescript from the schema. Most resulted in horrendous, bloated code. The official generators especially. Many others just choked on a complex schema, or used basic string concatenation to output the typescript leading to invalid code. Additionally the cost of the generated code scales with the schema size, which can mean shipping huge chunks of code to the client as your API evolves

The tool I will wholeheartedly recommend (and which I am unaffiliated beside making a few PRs) is openapi-ts. It is fast and correct, and you pay a fixed cost - there's a fetch wrapper for runtime and everything else exists at the type level.

I was kinda surprised how bad a lot of the tooling was considering how mature OpenAPI is. Perhaps it's advanced in the last year or so, when I stopped working on the project where I had to do this.

https://openapi-ts.dev/

Re: GraphQL: The enterprise honeymoon is over

#132

Post by WickyNilliams »

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

Earlier quoted context omitted.

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?

There is json-schema which is a sort of dialect/extension of OpenAPI which offers support for fetching relations (and relations of relations etc) and selecting a subset of fields in a single request https://json-schema.org/

I used this to get a fully type safe client and API, with minimal requests. But it was a lot of work to get right and is not as mainstream as OpenAPI itself. Gql is of course much simpler to get going

Re: GraphQL: The enterprise honeymoon is over

#133

Post by WickyNilliams »

HumanOstrich wrote: post #79
komali2 wrote: post #66

Earlier quoted context omitted.

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/

Fwiw I tried every tool imaginable a few years ago including kubb, (which I think I contributed to while testing things out)

The only mature, correct, fast option with a fixed cost (since it mostly exists at the type level meaning it doesn't scale your bundle with your API) was openapi-ts. I am not affiliated other than a previous happy user, though I did make some PRs while using it https://openapi-ts.dev/

Re: GraphQL: The enterprise honeymoon is over

#134

Post by 0x696C6961 »

WickyNilliams wrote: post #131
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.

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.

Re: GraphQL: The enterprise honeymoon is over

#135

Post by twodave »

Aurornis wrote: post #116
verdverm wrote: post #33

Earlier quoted context omitted.

That's something you should only really do in development, and then cement for production. Having open queries where an attacker can find interesting resolver interactions in production is asking for trouble

> That's something you should only really do in development, and then cement for production My experience with GraphQL in a nutshell: A lot of effort and complexity to support open ended queries which we then immediately disallow and replace with a fixed set of queries that could have been written as their own endpoints.

This is not the intended workflow. It is meant to be dynamic in nature.

Re: GraphQL: The enterprise honeymoon is over

#136

Post by WickyNilliams »

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…

Yes, Apollo not leading people down the correct path has given people a warped perception of what the benefits actually are. Colocation is such a massive improvement that's not really replicated anywhere else - just add your data requirements beside your component and the data "magically" (though not actually magic) gets requested and funnelled to the right place

Apollo essentially only had a single page mentioning this, and it wasn't easy to find, for _years_

Re: GraphQL: The enterprise honeymoon is over

#137

Post by presentation »

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…

Agreed on fragment masking. Graphql-codegen added support for it but in a way that unfortunately is not composable with all the other plugins in their ecosystem (client preset or bust), to the point that to get it to work nicely in our codebase we had to write our own plugins that rip code from the client preset so that we could use them as standalone plugins.

The ecosystem in general appears to be a problem.

Re: GraphQL: The enterprise honeymoon is over

#138

Post by presentation »

switz wrote: post #106
rbalicki wrote: post #90

Earlier quoted context omitted.

#1 unnecessary network waterfalls #2 downloading the same fields multiple times #3 downloading unneeded data/code Checks out

Hilariously – react server components largely solves all three of these problems, but developers don't seem to want to understand how or why, or seem to suggest that they don't solve any real problems.

I agree though worth noting that data loader patterns in most pre-RSC react meta frameworks + other frameworks also solve for most of these problems without the complexity of RSC. But RSC has many benefits beyond simplifying and optimizing data fetching that it’s too bad HN commenters hate it (and anything frontend related whatsoever) so much.

Re: GraphQL: The enterprise honeymoon is over

#139

Post by 0x696C6961 »

iterateoften wrote: post #124
lateforwork wrote: post #83

Earlier quoted context omitted.

The question I answered was regarding contracts. Fetching in a single request can be handled by your BFF.

So make things more complicated than gql?

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

Re: GraphQL: The enterprise honeymoon is over

#140

Post by scotty79 »

> The main problem GraphQL tries to solve is overfetching.

GraphQL is solving another problem. Problem of communication between frontend and backend team. When frontend team needs to have yet another, field exposed it needs to communicate this to the backend team. GraphQL let's them do this with code instead of Jira ticket and now the communication between the teams can be done asynchronously and batched. No more waiting for backend implementation each time. And if backend exposes too much then it's a backend problem and the frontend has nothing to do with it so it again can be solved without granular communication between backend and frontend teams.

Post reply on HN