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

181–190 of 448 posts

Re: GraphQL kinda sucks

#181

Post by Justsignedup »

Personally I've used JSONApi

Pros:

- front-end implementation is near-trivial. I re-wrote half of my framework because I wasn't happy with it in a few days.

- can use some cookbooks for some good front-end patterns

- overall very easy to use, and very easy to extend front-end stuff

Cons:

- Poor back-end implementations. JSONApi Resources kinda sucks. Graphiti might be significantly better.

- No clear pattern for submission of data. You don't want your front-end to contain operational logic, dumb front-ends are the way to go (front-ends do what they are told, they don't make decisions).

- Not the "IT" thing, so not too much big corporate money backing it. :( This is actually kind of a big deal.

Re: GraphQL kinda sucks

#182

Post by InvOfSmallC »

I admit I never seen a use case that justify the complexity of usage. Let's say you have a native app and a web app. I don't see these 2 changing that much in terms of data so a an API middlelayer is just simpler.

At work we have a use case like: well we create the data layer that you can query the way you want and the field you want with many clients involved. So like an API where you can make composable queries.

To me that sounds like an API with query parameters, do we really need to use GraphQL?

Let's see!

Re: GraphQL kinda sucks

#183

Post by cletus »

hamandcheese wrote: post #174
cletus wrote: post #153

My usual experiene is that people use GraphQL wrong. GraphQL's primary use case is to homogenize access to a bunch of heteregenous backend services. If you find yourself just taking your Postgres database and creating a 1:1 mapping between your tables and GraphQL, this probably isn't a good fit as you'r ejust adding another layer for no reason. > No clear path for Api versioning GraphQL came about as a way for mobile…

My company has many backends federated together, but a monolithic, web-based frontend. It’s actually really easy to remove a field from graphql. 1. Remove all uses from the frontend. 2. Deploy. 3. A day later, delete it from the schema. If deleting it causes relay compiler errors, go back to step 1. (The less lazy way to do it would be to actually pull some stats about how long-lived frontend bundles are) Not being a…

That affirms my point: you have complete control over the front end.

Re: GraphQL kinda sucks

#184

Post by crispyalmond »

dragon-hn wrote: post #180
vikR0001 wrote: post #96

Earlier quoted context omitted.

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.

If your GraphQL schema is just a mapping of database tables, in my experience you are in for a world of hurt in the future.

At my workplace they made this decision before I started and I can fully agree with this. It's essentially a typed REST without any of the benefits. No joins, everything is multiple calls away to perform a "full" query.

I don't even want to think about undoing this mess.

Re: GraphQL kinda sucks

#185

Post by eurasiantiger »

OmarIsmail wrote: post #17

Yes, graphql does indeed suck. Or rather it is not the best solution for all client-server communication that people treat it as, so it ends up being used in a lot of situations where it does suck. Backend to backend communication is almost never graphql (is that changing in a big way?) which would indicate the main reason for graphql in a client-server situation is data saving but at the cost of complexity and other…

Does Apollo really have cache bugs? Usually it’s the data itself which doesn’t have a unique id field, or the client hasn’t been configured to know about the proper id field.

Granted, it’s a problem to have to do that. But such is life with entity-level caching.

Re: GraphQL kinda sucks

#186

Post by no_wizard »

makeitdouble wrote: post #179
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 used to see GraphQL (and to an uglier respect Soap like interfaces) as complicated solutions to that problem you describe. But more and more, I think Backend For Frontends solve this issue in a much better way. And of course that idea isn’t new and Yahoo for instance had that kind of architecture. Frontend teams get to adjust by themselves a simple interface to their needs, and backend teams can provide more info t…

Do you have any reference material for the Yahoo architecture?

Re: GraphQL kinda sucks

#187

Post by toolz »

grumple wrote: post #61
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,…

Curious as to why you hate it specifically. Because what you could be doing is exposing every table / field automatically based on permissions (which you could set up a system where you don't even have to be involved).

because either the boilerplate is massive or the libraries do so much for you that you have to specialize in understanding the libraries magic - front-end plus back-end code for graphql is almost always more than a traditional REST api and I mean a lot more code, not just a bit more, so more code is strongly correlated with more problems. The exception is when you use heavy libraries that have magical APIs. Then you end up with teams who understand the API and have no idea how graphql actually works, which is probably an even worse problem.

Re: GraphQL kinda sucks

#188

Post by infinitezest »

Ive used GQL on several projects for work and its been _OK_ to work with but not really worth the hassle in our cases. It ended up costing us lots of time to onboard new devs and hasnt given is much in return aside from type safety between the front and back ends. Im sure there are good use cases for GQL but I have not personally run into them.

Re: GraphQL kinda sucks

#189

Post by E2EEd »

I built an app with a REST API a long time ago, now a defunct startup. In an effort to save API calls, the front end devs requested that I add various other resources in new endpoints, often a subset of another endpoint's response fields. The API spec ended up being fairly unwieldy.

I've often thought that this would be a great use case for GQL. Seems like a good choice if your front end wants to specify exactly what data to get.

Re: GraphQL kinda sucks

#190

Post by mechanical_bear »

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.

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