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

61–70 of 241 posts

Re: GraphQL: The enterprise honeymoon is over

#61

Post by cluckindan »

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…

Have you tried using a decorator for auth?

Also, using a proper GraphQL server and not composing it yourself from primitives is usually beneficial.

Re: GraphQL: The enterprise honeymoon is over

#62

Post by lateforwork »

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.

Re: GraphQL: The enterprise honeymoon is over

#63

Post by sheepscreek »

What I’ve realized over time is the idea is beautiful and the problem it solves is partly of API/schema discovery.

Yet I am conflicted on whether it’s a real value add for most use-cases though. Maybe if there are many micro-services and you need a nice way to tie it all together. Or the underlying DB (source or truth data stores) can natively support responses in GraphQL. Then you could wrap it in a thin API transformation BFF (backend for frontend) per client and call it a day.

But in most cases, you’re just shifting the complexity + introducing more moving parts. With some discipline and standardization (if all services follow the same authentication mechanics), it is possible to get the same benefits with OpenAPI + an API catalog. Plus you avoid the layers of GraphQL transformations in clients and the server.

100% based on my anecdotal experience supporting new projects and migrations to GraphQL in < $10B market cap companies (including a couple of startups).

Re: GraphQL: The enterprise honeymoon is over

#64

Post by cluckindan »

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/

There are also GraphQL interfaces for various databases which can be useful, especially with federation to tie them together into a supergraph.

Re: GraphQL: The enterprise honeymoon is over

#66

Post by komali2 »

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.

Discovering Kubb was a game changer for me last year.

Re: GraphQL: The enterprise honeymoon is over

#67

Post by cluckindan »

mohas wrote: post #27

using graphql specifically Apollo was one of my regrettable decisions when I was designing a system 3 years ago, one that haunts me still today with wired bugs, too much effort to upgrade the version while prev version still have bugs etc. and I lost performance and simplicity of rest on top of that

It’s one of the best pieces of software I’ve worked with. I guess simplicity is in the eye of the beholder :)

Re: GraphQL: The enterprise honeymoon is over

#68

Post by c-hendricks »

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.

What about the whole "graph" part? Are there any openapi libraries that deal with that?

Re: GraphQL: The enterprise honeymoon is over

#69

Post by gethly »

GQL was always one of those things that sound good on the surface but in practice it never delivers and the longer you're stuck with it the worse it gets. Majority of tech is actually like this. People constantly want to reinvent the wheel but in the end, a wheel is a wheel and it will never be anything else.

Re: GraphQL: The enterprise honeymoon is over

#70

Post by lateforwork »

c-hendricks wrote: post #68
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.

What about the whole "graph" part? Are there any openapi libraries that deal with that?

OpenAPI definition includes class hierarchy as well. You can use tools to generate TypeScript type definitions from that.
Post reply on HN