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

141–150 of 241 posts

Re: GraphQL: The enterprise honeymoon is over

#141

Post by scotty79 »

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 must be implemented by narrowing down to only allowed data on the server side. How much of it is requested doesn't matter for security.

Re: GraphQL: The enterprise honeymoon is over

#142

Post by WickyNilliams »

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.

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

Re: GraphQL: The enterprise honeymoon is over

#143

Post by presentation »

nmilo wrote: post #94

This doesn’t really make sense. Obviously if you combine GQL with BFF/REST you’re gonna have annoying double-work —- you’re solving the same problem twice. GQL lets you structure your backend into semantic objects then have the frontend do whatever it wants without extra backend changes. Which lets frontend devs move way faster.

This is the true big benefit, the others talking about over fetching are not wrong but overfocusing on a technical merit over the operational ones.

My frontend developers had their minds blown when they realized that because we’re using Hasura internally, the only backend work generally needed is to design the db schema and permissioning, and then once that’s done frontend developers aren’t ever blocked by anything (which is not a freedom that I would want to give to untrusted developers, hence emphasis on internal usage of GQL)

(Unfortunately Hasura has shifted entirely into this VC-induced DDN thing that seems to be a hard break from the original product, so I can’t recommend that anymore… postgraphile is probably the way)

Re: GraphQL: The enterprise honeymoon is over

#144

Post by 0x696C6961 »

bakugo wrote: post #113
HumanOstrich wrote: post #79

Earlier quoted context omitted.

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/

This project seems to be mostly AI generated, so keep that in mind before replacing any existing solutions.

No it doesn't

Re: GraphQL: The enterprise honeymoon is over

#145

Post by scotty79 »

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…

GraphQL is best if the entire React page gathers all requirement from subcomponents into one large GraphQL query and the backend converts the query to a single large SQL query that requests all the data directly from database where table and row level security make sure no private data is exposed. Then the backend converts SQL result into GraphQL response and React distributes the received data across subcomponents.

Resolvers should be an exception for the data that can't come directly from the database, not the backbone of the system.

Re: GraphQL: The enterprise honeymoon is over

#146

Post by 0x696C6961 »

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

Being verbose doesn't make it difficult.

Re: GraphQL: The enterprise honeymoon is over

#147

Post by hokkos »

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 use https://typespec.io to generate openapi, writing openapi yaml quickly became horrible past a few apis.

Re: GraphQL: The enterprise honeymoon is over

#148

Post by sibeliuss »

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

The docs situation continues to be hilarious and bad, for the gem they have created.

It's the unfortunate situation where those who know, know, and those who do not, blasphemy the whole thing based on misunderstanding.

Super unfortunate, which could be solved by simply moving a little money over to Relay's docs, and working on some marketing materials.

Re: GraphQL: The enterprise honeymoon is over

#149

Post by WickyNilliams »

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

Earlier quoted context omitted.

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

Being verbose doesn't make it difficult.

Not necessarily, no. But at a certain point, I believe it does. Difficult to read, is difficult to edit, is difficult to work with.

A sibling comment to your reply expressed the same sentiment as me, and also mentioned typespec as a possible solution

Re: GraphQL: The enterprise honeymoon is over

#150

Post by jakubriedl »

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…

I 100% agree that overfetching isn't the main problem graphql solves for me.

I'm actually spending a lot of time in rest-ish world and contract isn't the problem I'd solve with GraphQL either. For that I'd go through OpenAPI, and it's enforcement and validation. That is very viable these days, just isn't a "default" in the ecosystem.

For me what GraphQL solves as main problem, which I haven't got good alternative for is API composition and evolution especially in M:N client-services scenario in large systems. Having the mindset of "client describes what they need" -> "graphql server figures out how to get it" -> "domain services resolve the part" makes long term management of network of APIs much easier. And when it's combined with good observability it can become one of the biggest enablers for data access.

Post reply on HN