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

141–150 of 448 posts

Re: GraphQL kinda sucks

#141

Post by hn_throwaway_99 »

spywaregorilla wrote: post #126
hn_throwaway_99 wrote: post #60

Earlier quoted context omitted.

> It's an immediate red flag that the engineering culture at the company is poorly run and would be a nightmare to work in. Well, at least I'm glad I know I'll never be working with you! I'm not giving you shit because you don't like GraphQL, I'm giving you shit because of your asinine "if you use GraphQL your company is poorly run and a nightmare" comment. Whenever I see a comment from any developer that says "If yo…

I felt pretty confident about my conclusions of my first dusty old bank job that used a custom shittier homebrew of google web toolkit and no source control.

But that's very different. "No source control" means they aren't following or don't understand the very basics of software process management. That's very different from "If you use SCM system X, Y or Z you're an idiot."

Re: GraphQL kinda sucks

#142

Post by jasonhansel »

IMHO the biggest issue with GraphQL is that it's often used in a way that effectively breaks encapsulation. When you use GraphQL, it's hard to limit the API surface of a service to avoid exposing implementation details. This means it's difficult to modify the internals of a service without breaking its clients, and it can make things like testing and versioning more of a challenge.

Re: GraphQL kinda sucks

#143

Post by gorjusborg »

GraphQL isn’t a panacea. It has strengths and weaknesses.

This is true of any technology, so if you think the tech you are using doesn’t require a trade-off of some sort, you are likely missing something.

I’ve yet to select GraphQL over straight RESTful APIs, but I also don’t work in an ecosystem where disparate client needs are important.

Re: GraphQL kinda sucks

#144

Post by TheAceOfHearts »

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.

It depends on the kind of application and scale. Consider a large and complex application like Discord or Figma. Past a certain point, it's hard for anyone to know how every single detail works.

You should probably be comfortable enough to work with both ends of the spectrum, but specialization allows you to do a much deeper dive into complex subjects.

A backend engineer probably has a much deeper understanding of every little nuance of their prefered database. A great backend engineer can make sure that you're getting near-optimal performance from every important query.

A frontend engineer probably knows about various UX techniques along with how to avoid unecessary reflows and repaints. A great frontend engineer can implement a UI toolkit as well as advanced techniques such as windowing.

Re: GraphQL kinda sucks

#145

Post by enahs-sf »

My main gripe with it is it’s an added level of indirection that makes debugging just a little more difficult.

Back in the good old days, you could open up the network tab, see the request made by the client and copy as curl to debug it.

Now with SSR and graphql, such a workflow is out the window.

Re: GraphQL kinda sucks

#146

Post by 4dregress »

Being a good engineer (in any domain) means you have the experience to can pick the correct tools for the job and then explain why you have chosen those tools.

It all depends on what the end goal is.

Re: GraphQL kinda sucks

#147

Post by diarrhea »

NonNefarious wrote: post #88
hn_throwaway_99 wrote: post #60

Earlier quoted context omitted.

> It's an immediate red flag that the engineering culture at the company is poorly run and would be a nightmare to work in. Well, at least I'm glad I know I'll never be working with you! I'm not giving you shit because you don't like GraphQL, I'm giving you shit because of your asinine "if you use GraphQL your company is poorly run and a nightmare" comment. Whenever I see a comment from any developer that says "If yo…

Yep. I worked at a place that fired almost its entire programming staff because they insisted on using Visual C++ to build a CRUD app, while a team of contractors built a prototype in Visual Basic. Needless to say, the VB app worked fine and became the product.

If you don't mind, would you explain this more? I don't understand the implications; VB does sound "worse" than Visual C++ for such a job, from an outsider perspective?

Re: GraphQL kinda sucks

#148

Post by sebnukem2 »

I'm happy to read this. I had to use GraphQL once in an old job and I hated, hated the freaking thing with a passion, but there was so much hype about it I concluded the problem with it was caused by myself, a getting older and more close minded self. I see now that GraphQL may not be that wonderful, after all.

Re: GraphQL kinda sucks

#150

Post by danabrams »

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…

100% agree that it’s about dependence on other teams. That said, I’d much rather that we were communicating across a well defined api boundary, rather than a graphql api. You could, of course, very easily do this with an api layer in the middle.
Post reply on HN