[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.