[nawgz]

It's unironically true that GraphQL in combination with database introspection & query tools like Hasura is a far superior pattern to REST-based CRUD.

Additionally, as a UI developer, I understand you are trying to make it seem like GraphQL promotes anti-patterns, but being able to make a single query which is deeply nested and therefore can maintain state for an entire sub-tree of your app is a really good state management pattern. Less coupling, separation of concerns, and usually significantly reduced network activity since you just need to keep the GraphQL state aligned, which is actually specified unlike how to sync a REST resource.

Do you actually have any experience with this tool?

[handrous]

Hasura is great. GraphQL on its own, unless you're offloading all of it to something well-maintained and capable like Hasura which will (hopefully) automagically save you from the time cost and risk of GraphQL, is almost always a bad idea.

[nawgz]

"Using a protocol you don't understand without a tool that implements it is a bad idea"

Listen, I get it, we all want to hate on NIH and cutting-edge stuff, but what you've said is not an objection. GraphQL is a complicated protocol, but it offers a very clean interface between clients & servers, and when you put in a strong implementation you can generically access data that before you needed to specifically access.

I don't even know what else to say. There's a time cost and risk of every single thing you'll implement, you haven't given any insights into what tips GraphQL into a superbly expensive and risky area... Especially because Hasura is completely free and open-source...

[handrous]

> what tips GraphQL into a superbly expensive and risky area

The TL;DR is that implementing it without something that automagics away most of the work, does some clever stuff to save you from various pitfalls, and is very heavily battle-tested is approximately as bad an idea as exposing your SQL server directly to the web browser, except that you could do that for free. "Oh no I couldn't, I'd have to do so much work to make sure that access is safe—there's no way that would pay off, and I'd probably still manage to deploy DOS or data access vulnerabilities!" Yep, exactly.

It's also of dubious benefit vs. other options if you fully control both the front-end and back-end and aren't planning to allow lots of 3rd party users of your API—though even in that case Hasura, in particular, may still be a win despite GraphQL, not because of it.

[nawgz]

Well, a tl;dr that says implementing a heavy protocol poorly is a bad idea is once again a non-statement.

> It's also of dubious benefit

Laughable. Comparing to the silly comparison of "direct SQL queries", both have lots of dangerous pitfalls, sure, but direct SQL queries give you no wins in-and-of-themself. For implementing GraphQL on the other hand, you get schema definitions, discoverability, strict typing across a network call, a large set of tooling you can plug in that "just works" because GraphQL is a protocol designed to tackle modern web issues, and more. GraphQL is not just "exposing your database directly", I think it shows a lack of experience with it that you think that way

[handrous]

My assertion, broadly, is that GraphQL is incidental to the good things that have grown up in its ecosystem, that GraphQL is per se not especially good or interesting, and that attempting to replace a traditional REST interface with it, without also bringing in a large stack of supporting tech that you didn't need before, is almost certainly a bad idea that will end in tears, because it is heavily dependent on those things to not-suck. Nonetheless, the hype has companies burning money on it, as is always the way with hype.

I would agree that it's really, really easy to improve on JSON, which is a curse on our industry.

And yes, I have experience with GraphQL. I think it has very little useful or cost-justifiable place unless you buy in to a heavy and very capable 3rd party system to manage at least the server-side portions for you, automagically. It's similar to buying into Rails. Absent that, yes, it's very much comparable to letting browsers supply SQL queries to your server, in that only with incredible effort could you avoid creating a vulnerability gold mine when implementing such a thing, because you're starting at a scope of "everything" and narrowing it down, rather than starting at a scope of "nothing" and building up from there.

[EDIT] and on the topic of vulnerabilities, given what it does, it'd be a sucker's bet that several popular implementations aren't just waiting to be a key player in "someone downloaded the entire database of 100 major sites that use this library/framework" hacks in the not-so-distant future. It is very much a "use with care, only if you need it, and with both eyes wide open" sort of thing. Again, I agree that Hasura's temptingly-handy, and that JSON and other non-statically-typed boundary-crossing data structures are practically always god-awful.

[nawgz]

> [I assert that] attempting to replace a traditional REST interface with it, without also bringing in a large stack of supporting tech that you didn't need before, is almost certainly a bad idea that will end in tears

I literally brought in Hasura, and completely replaced my REST interfaces with it. There is no "large stack of supporting tech", I added a docker container to my small set of services (which already included PostgreSQL). Again, Hasura is free and open-source, and incredibly powerful while still easy-to-use. Setting up authentication is also a breeze.

Further, to imply that a query GENERATOR is in any way comparable to a query RUNNER is just foolish. Cut it out. You can't claim that it's a "sucker's bet" the whole ecosystem is just exposing unsecured databases, especially not without a single link supporting this having happened.

To conclude, I guess I find that I would strongly disagree with your approach to things and your reasoning behind it, and I find your claims like "JSON and other non-statically-typed boundary-crossing data structures are practically always god-awful" hilarious when I just told you I can treat GraphQL data as a statically typed boundary-crossing data structure thanks exactly to the GraphQL & implementation thereof you rail against.

Take care, good luck with whatever solutions you are using.

[Oddskar]

I'm not praising REST at all. REST as it was de-facto used was in my opinion a hot mess that was poorly understood and had developers focus on the wrong things (e.g. pretty urls).

I still don't think GraphQL as state management is a good idea for anything surpassing moderate complexity. And yes I've worked with both GraphQL and Apollo. I can see the merits for sure; for instance discoverability and being able to generate types from the API are great. I don't like overcommitting to Apollo though and using the overly sized client. Something is wrong when your state management is bigger in filesize than the SPA framework you're using.

[nawgz]

> I still don't think GraphQL as state management is a good idea for anything surpassing moderate complexity

This statement is a bit hard to break down. What is "moderate complexity"? For example, I have implemented layers where GraphQL queries feed into mobx to manage some additional application state that never persists. I didn't even use apollo client for this, I just fired off a REST query.

Apollo client, on the other hand - I don't really know what you mean about "overly sized client", I am under the impression you can get it for 12-30kb, while React+DOM is 100-160kb (sorry not sure which numbers are gzipped here). I additionally think that it's a very light layer in terms of managing state, when I speak of "managing state via GraphQL" what I really mean is knowing when the client-side cache needs to update, and this is way easier than REST or for that matter anything else I've seen. In this regard, you can sync the server-side and client-side data easily and directly, and then use whatever state management solution you wish for your application.

Ok, besides it all, if you're just making fun of everything, that's fair, but it seems strange to mock something new / popular / powerful without any mention that it does things better than the old popular solutions

[Oddskar]

> For example, I have implemented layers where GraphQL queries feed into mobx to manage some additional application state that never persists.

Not sure what you want to say with this because it sounds like you used Mobx for state management in that case. Or do I misunderstand you?

> I additionally think that it's a very light layer in terms of managing state

According to bundlephobia:

React + DOM = ~42KB Gzipped

@apollo/client = 39KB Gzipped

For reference redux + redux thunk is like 2KB

Xstate is less than 20KB

> what I really mean is knowing when the client-side cache needs to update

Aha, and that sounds sensible. I agree. There are lots of other things in Apollo though that you apparently aren't using.

[nawgz]

> > For example, I have implemented layers where GraphQL queries feed into mobx to manage some additional application state that never persists.

> Not sure what you want to say with this because it sounds like you used Mobx for state management in that case. Or do I misunderstand you?

Yes, I kind of botched it, but it's my point - GraphQL as state management can mean a lot of things. It can mean Apollo, client-side cache invalidation, use of subscriptions, etc.. I think that I found your statement of GraphQL breaking down above moderate complexity confusing because it was unclear to me what way you meant this in.

RE: apollo client, it's interesting to see that it's large, I agree that contrasted to XState or Mobx or especially Redux it is quite large, I would be happy to see that number come down, but I also am not so scared of 40KB I can serve from cache given I'm rendering "dataflow editors" of some complexity

Finally, I agree I barely use Apollo, I find its graceful property to primarily be cache management but greatly prefer mobx for true application state management because it is blazing fast / the most efficient rendering strategy