Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GraphQL kinda sucks

news.ycombinator.com

Post reply on HN
Print view View original

91–100 of 448 posts

Re: GraphQL kinda sucks

#91

Post by cube2222 »

Having had experience with it from a "backend for the frontend" perspective, GraphQL is nice because it gives you an API for free and does partly decouple the frontend team.

At the same time, with most backend GraphQL frameworks the decoupling will be very illusory, as in practice you'll have to tune the backend to the frontend use cases or you'll just end up with a ton of N+1 queries and terrible performance.

In other words, application-specific http endpoints have their advantages and let you have fine tuned queries for each use case, which makes sense for app-style frontends.

Re: GraphQL kinda sucks

#92

Post by vlod »

gabereiser wrote: post #12

I tried graphql in a microservices environment and had huge headaches over schema stitching. Turns out, if you have lots of objects from disparate sources, graphql don’t like that. Now you must stitch these schemas together into an über schema roll query and use with graphql. Maybe we missed a step. Maybe we misunderstood. Maybe it was a bad decision.

I think Apollo Federation is for that: https://www.apollographql.com/docs/federation/

Worth watching some youtube tutorial videos. Here's one I watched recently (~26mins): https://www.youtube.com/watch?v=v_1bn2sHdk4

Re: GraphQL kinda sucks

#93

Post by dasil003 »

breckenedge wrote: post #23
mabbo wrote: post #18

Whether it was the intention or not, I find GraphQL solved a fascinating problem: it let front end developers move faster by greatly decoupling their data needs from the backend developers. Backend developers describe the data model, expose it via graphql. Front end developers, often ones who never met those backend developers, can see the data model and just use it. They can change what they're querying on the fly,…

I get specialization, but are there any other good reasons to divide product teams between frontend and backend? I guess it also helps establish patterns and contracts, but I think those are only helpful above a critical mass that I haven’t reached in my career yet.

The reason is to scale teams. It’s not the only way to do it—you can also have vertical teams—but it’s a common one because frontend and backend have different technical considerations. The downside is the product can lose cohesion as developers get tunnel vision. Of course all big teams suffer from a version of that problem depending how the lines are drawn.

Re: GraphQL kinda sucks

#94

Post by jddil »

legalcorrection wrote: post #11

Ignore all the noise and just use an RPC model between your backend and frontend. All these stupid trends and overengineered abstractions will come and go, but people will still be using plain RPC in 5, 10, 100, and 1000 years.

The longer I do this the more I realize the part of engineering most of us enjoy is solving a problem in a novel way. Which means if left to their own devices engineers will recreate the entire tech stack every few years instead of using the shit we've already built 20 years ago cause it's too boring.

Re: GraphQL kinda sucks

#95

Post by vsareto »

grumple wrote: post #55
philliphaydon wrote: post #51

> It can save you bandwidth. Get what you ask for and no more I feel like this a false truth. Most people are building a web app, or a mobile app and consuming an api and displaying all the data they retrieve. If you have an rest api which returns an object with 6 properties. And a graphQl scheme which returns those same 6 properties. You’re not saving anything. Now if you have a website and a mobile app, where the m…

> If you have an rest api which returns an object with 6 properties. And a graphQl scheme which returns those same 6 properties. You’re not saving anything. You aren't thinking big enough. We have a graphql API where we have a bunch of enterprise users all wanting to pull out different types of data. They can decide what they want to get, and pull exactly that data. They want access to different tables, fields, and f…

I guess it works, but it still seems like an extra step compared to giving them DB access unless they're in some weird place where they can learn to use GraphQL but not Sql/NoSql

Re: GraphQL kinda sucks

#96

Post by vikR0001 »

jonhohle wrote: post #89
mLuby wrote: post #76

Having worked in big tech and small startups, I think GraphQL is a brilliant way to solve an organizational problem that massive tech companies have. It's that the team maintaining the API is different from the team that needs changes to the API. Due to the scale of the organization the latter doesn't have the access or know-how to easily add fields to that API themselves, so they have to wait for the maintainers to…

If that field isn’t populated aren’t you in the exact same spot?

Let's say you need to get a field back that is already in the database table, but that wasn't previously returned by the GraphQL endpoint. All you have to do on the front end is ask for it and GraphQL will populate it for you on the server.

Re: GraphQL kinda sucks

#97

Post by zmxz »

geuis wrote: post #28

It's not an unpopular opinion: it's true. Graphql is a terrible piece of software/paradigm. I've completely avoided it for years. If a potential new job contacts me and they use graphql, it's an immediate no from me. It's an immediate red flag that the engineering culture at the company is poorly run and would be a nightmare to work in. Run away, as fast as possible.

Yup, gotta trust the words from some unknown from internet, with 0 proof. As if we're all there, up in your head, able to hear every single thought you have and determine that what you say is pure, unfiltered truth.

If many manage to use GraphQL and be content with it, that should be an indicator to you. But, you chose it isn't and that you'll merely display how politely negative you can be.

Thank you.

Re: GraphQL kinda sucks

#99

Post by nawgz »

mccorrinall wrote: post #42
thdxr wrote: post #35

Be careful with anyone with a take that says some technology is 100% bad always. Given enough experience / skill you can make any technology fairly enjoyable so I've only ever seen mixed reactions at worst from people giving things a fair try. GraphQL is a way to describe not only your API but also the entities and relationships in it. This enables certain useful things for client heavy applications, like cache norma…

I love consuming graphql as a client. But writing resolvers and all that stuff on the backend? God, I hate it!

Hasura :)

Re: GraphQL kinda sucks

#100

Post by vlod »

NonNefarious wrote: post #81

I was psyched to hear about GraphQL, but when I looked at it and found no apparent way to do joins... I wondered what the big deal is.

I think the general idea is that it's a graph rather than relations.

You "join" by using the parent ID (e.g. employerID of parent container to get employees). This can (and often) introduces an n+1 problem unless you watch for it and use dataloaders.

Not saying this is great or anything. :)

Post reply on HN