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

221–230 of 448 posts

Re: GraphQL kinda sucks

#221

Post by pphysch »

YZF wrote: post #192
danabrams wrote: post #150

Earlier quoted context omitted.

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.

Nobody seems to get the idea of building software out of pieces with well defined APIs any more . I would say it's not possible to build large software without adhering to this principle but I seem to be proven wrong. You can build large poor quality software and just throw more people at it. The other part about team dependence is very true but it also shows a lack of knowledge/thinking/care by whoever formed the te…

This is one of the strengths of gRPC, it forces and centralizes the (mostly type safe) API design from the get-go.

Also tends to use a lot less bandwidth.

Re: GraphQL kinda sucks

#222

Post by NonNefarious »

diarrhea wrote: post #147
NonNefarious wrote: post #88

Earlier quoted context omitted.

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?

No problem. At the time, Visual C++ lacked several important OCX controls that were included with VB, so they had to be hand-coded.

If you were building an application that does little more than populate forms with data from a database and then update the database, VB was totally adequate. The most important part of the job was the DB and query design.

Re: GraphQL kinda sucks

#223

Post by jddil »

Guid_NewGuid wrote: post #138

Hmm, I feel weird reading all this criticism of GQL. It reminds me of when our place switched to it and I was constantly slagging it off until my friend/colleague said "do you actually hate it or you just don't understand it?". Default hostility to new concepts and frameworks can save a lot of time, energy and mistakes in software but sometimes for some use cases the new (variation of an old) solution can be superior…

You haven't actually described any of the unique parts of GraphQL though. Generating a typesafe API whose schema is defined in a single place is trivial with an OpenApi spec and a client generator

What I've noticed is people get their first taste of a type safe api and automatic client creation via GraphQL and don't understand that exists without it.

Re: GraphQL kinda sucks

#224

Post by NonNefarious »

mechanical_bear wrote: post #190
NonNefarious wrote: post #88

Earlier quoted context omitted.

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.

Why is this “needless to say”, as if it should be apparent to anyone?

Because a CRUD app doesn't require any serious computing performance from the application, making C++ unnecessary. If another implementation won the race to functional completion, then... needless to say... it was the one to go with.

Today you'd probably just use browser-based UI.

Also if you've spent time in corporate development (rather than a software company), I think this scenario is a common one. If you show management a prototype that works, they're going to ask why we don't just make that the product. And if you don't have a good reason... you don't have a good reason.

Re: GraphQL kinda sucks

#225

Post by NonNefarious »

vlod wrote: post #100
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. :)

Thanks. The issue is what if I want to pull all the employees from the table of all customers, to determine how many employees have made purchases under our employee-discount plan?

I just made that up as something that would likely require a join without really thinking it through too much...

Re: GraphQL kinda sucks

#226

Post by masklinn »

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…

I think an other thing with graphql is it reduces friction when trying to discover what your API should be.

So what you can do is some sort of generative graphql thingie when doing your initial iteration, with the client hitting whatever is convenient (in that situation you'd just expose the entire backend unprotected).

Once the needs have gelled out you strip it out and replace the graphql queries by bespoke API endpoints.

Re: GraphQL kinda sucks

#228

Post by NonNefarious »

mdaniel wrote: post #156
vikR0001 wrote: post #107

Earlier quoted context omitted.

You can do something like this. This query can be created and run on the client: ``` const SAMPLE_JOIN_QUERY = gql` query ($main_data_id: String!) { mainData( main_data_id: $main_data_id) { id main_data_field_1 main_data_field_2 main_data_field_3 related_data{ related_data_field_1 related_data_field_2 related_data_field_3 } } } `; ```

https://news.ycombinator.com/formatdoc may interest you const SAMPLE_JOIN_QUERY = gql` query ($main_data_id: String!) { mainData( main_data_id: $main_data_id) { id main_data_field_1 main_data_field_2 main_data_field_3 related_data { related_data_field_1 related_data_field_2 related_data_field_3 } } }`;

Thanks!

Re: GraphQL kinda sucks

#229

Post by adra »

x86x87 wrote: post #154
datalopers wrote: post #54

GraphQL's primary feature is enabling data exfiltration for bad actors

This nails it. Had the "proviledge" of needing to secure a GQL endpoint and it's a mess. AuthZ? What's that? + Runaway queries that kill the database? check! + Caching? Lol. Setting aside security and scalabilty for a second: Ifeel like GQL is at its best a complicated database driver, with the data types being defined and implemented twice: once in the DB layes, once in the backed.

If you're testing gql as anything remotely similar to a database facade, you've already lost. GQL is meant to provide functionality that generally happens to be data backed. If you want to push all your work to the frontend and treat gql as a db shim, you're solving the wrong problem in the wrong ways.

Re: GraphQL kinda sucks

#230

Post by jayd16 »

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,…

To me it's a weird way to go about this decoupling. Another way is you can just keep your own view-model client side and abstract the backend data with that.

FFBs and GraphQL is a way to tightly couple to a backend system and then have that backend system loosely coupled.

I guess its all 6 of one, half-dozen of the other, but I usually prefer to just handle things client side. You can maybe get less data transfer optimization but that's down the road from the fast development stage, anyway.

Post reply on HN