GraphQL kinda sucks • Hacker News Board

Re: GraphQL kinda sucks

#211

Post by gedy » Sat, Aug 06, 2022, 6:04 PM UTC

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…

I'm not following if you think GraphQL is a bad fit still, but we used GraphQL with the BFF pattern, and it was nice to use from Frontend to BFF. The backend services would use REST or whatever appropriate behind the BFF.

Re: GraphQL kinda sucks

#212

Post by nrb » Sat, Aug 06, 2022, 6:04 PM UTC

InvOfSmallC wrote: post #182

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…

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

Do you care about the API being discoverable and the schema being well described? Being able to see the relationships between the data? The type-safety that comes from the tooling? The ability to expose the field once on an entity that allows consumers to use it in any variety of queries?

Re: GraphQL kinda sucks

#213

Post by the_mitsuhiko » Sat, Aug 06, 2022, 6:05 PM UTC

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…

In many ways you also need to be a massive tech company to not create a massive scalability problem. The first time someone ships a shitty query to a large user base on a mobile app you are now dealing with the consequences of a frontend engineer creating a bad query you can not kill quickly any more.

Making scalable, well performing queries work is nontrivial, particularly with the current ecosystem of GraphQL libraries. The main workaround for this provided appears to be directly mapping GraphQL to an ORM.

Re: GraphQL kinda sucks

#214

Post by koonsolo » Sat, Aug 06, 2022, 6:05 PM UTC

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?

In C++ you have to manage your own memory. Why would you want to do that when you're simply pushing data around.

I wouldn't choose VB myself, but when it's between VB and C++ for simple data pushing, I would indeed choose VB.

Let's say it like this: if you need to move stuff, would you choose a F1 car or a minivan. I would pick the minivan.

Re: GraphQL kinda sucks

#215

Post by alerighi » Sat, Aug 06, 2022, 6:06 PM UTC

To me is not that great either. I find it simpler and more robust a well designed REST API, where with well designed I mean that the semantic of the methods is respected and it works on resources.

The thing is that GraphQL is an RPC mechanism, contrary to REST that is a protocol to do CRUD operations on resources, and that has all the complexity associated with an RPC itself.

Re: GraphQL kinda sucks

#216

Post by koonsolo » Sat, Aug 06, 2022, 6:07 PM UTC

cudgy wrote: post #70

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…

You are right that this arrogant attitude is juvenile, but it is prevalent amongst humans in all areas. Unfortunately, there would be few developers to work with if you apply the policy of not working with arrogant, dogmatic developers.

For me it signals maturity.

When it's a junior, I remember myself and think they still need to learn.

When it's a senior, I know it's not a senior.

Re: GraphQL kinda sucks

#217

Post by adra » Sat, Aug 06, 2022, 6:07 PM UTC

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!

I don't know your language of choice, but in the JVM ecosystem, Netflix DGS is so damn simple to build new resolvers.

Re: GraphQL kinda sucks

#218

Post by aleclm » Sat, Aug 06, 2022, 6:07 PM UTC

We recently had to design an HTTP API, and we wanted to have as much automatic stuff as possible. I mean:

* Autogenerated documentation

* Autogenerated wrappers for scripting languages

* Autogenerated validator for requests and responses

For a REST API, you can get most of these things with swagger or stuff like that, but clearly it's an afterthought. If you have a schema, it's all much more natural and elegant.

But the most important thing you get with GraphQL is batching. For our use case (a decompilation pipeline) if you make 10 requests one after the other or 10 requests altogether it makes a huge difference in terms of performance.

If you need batching and design a REST API, for every nice endpoint you have you need to make a bulk version of the API. You're likely going to do that POST'ing a JSON. Now, once you're at that point, you're reinventing the wheel with six sides.

If your backend is in C/C++ and I suggest to make a C API for Python and use ariadne:

    https://ariadnegraphql.org/

Don't do GraphQL in C/C++.

Re: GraphQL kinda sucks

#219

Post by andrewingram » Sat, Aug 06, 2022, 6:12 PM UTC

_Context: I do front-end and back-end, so I'm usually the one who ends up maintaining the GraphQL server_.

The vast majority of people who've used GraphQL haven't used it with something like Relay; and in my mind that means they haven't used GraphQL in a way that really shows off its strengths. This isn't to say that GraphQL doesn't have any benefits without Relay, but rather that the cost/benefit scale only really tip heavily towards benefits if you're using it to solve the problems it was intended to solve -- that of reliably getting a component's data dependencies into the component.

Every time I use GraphQL without Relay I find myself questioning whether it's adding anything except complexity, every time I use Relay (other than the initial architecture build, on-ramp is steep) it feels great. Relay's learning curve and poor documentation is really unfortunate, because the difference is quite pronounced.

Re: GraphQL kinda sucks

#220

Post by rglover » Sat, Aug 06, 2022, 6:12 PM UTC

Having spent several years working with GraphQL (using it in multiple projects and teaching it to others), I've found that in the majority of cases just doing a plain JSON-RPC API is preferable and far easier to reason about for all skill levels.

When I built Joystick [1], this is why I implemented the API system [2] as a JSON-RPC model, but stole the idea of validating inputs (optionally) and then on the client, optionally specifying tailored output (also optional—like how you can request specific fields back in GraphQL but instead of a custom query language, just pass an array of paths like ['customers.creditCard.expirationMonth', 'customers.creditCard.expirationYear'] for the specific data you want returned).

What I learned implementing that is that the typing/querying for specific fields ideas is brilliant, but much better when it's flexible (i.e., I want it sometimes but not all the time).

[1] https://github.com/cheatcode/joystick

[2] https://github.com/cheatcode/joystick#api-1