Join Data from PostgreSQL Declaratively in GraphQL Without Writing SQL | Hacker News Reader

Join Data from PostgreSQL Declaratively in GraphQL Without Writing SQL

stepzen.com

33 pointshwhelan12 comments

At this point you may as well expose SQL to the client?

GraphQL and REST are safer for the backend. You can trivially hog up a server with a single SQL query, even without any permissions.

Or, more innocently, you can write some hilariously wasteful queries in SQL (join on string replacements? create absurdly unnecessary temp tables? seen both). GraphQL queries have a much more limited ability to fuck up the server.

If persisted GraphQL queries are safest and likely more performant, then persisted SQL would have the same benefits. Not that I'm advocating for that, but there's not much difference once you've accounted for all factors.

Persisted SQL is used quite a lot, and best practice in many case: stored procedures containing the query returning just a ref cursor for example, or sql (materialized) views where users don't get direct access to the underlying tables.

True, but I was thinking from a web client. Perhaps if table and column names were aliased? Not that different from GraphQL.

GraphQL is safer than SQL, but it can't be more performant, as it gets translated to SQL server-side.

That said, you don't have to choose only one of the two. At my company we use a GraphQL backend for simple SELECTs which are the vast majority of front-end queries - no reason to involve a backend engineer for them. However, traditional backend calls are used for data modification commands (to enforce business rules server-side) and for performance-critical queries (to tune the raw SQL query/ies as necessary).

Postgraphile let's you do it all

Postgraphile is indeed our GraphQL backend.

How is it declarative when you literally declare how you build the data iteratively

"Use our tool's language instead of the other tool's language because you don't understand the other tool's language well enough to use it effectively and efficiently."

Uh, what?

SQL allows you to do many things more effectively and faster than in-code. It's more than just a persistent store; it uses the power of math to do things faster. As an example, aggregation can be faster in the DB if your data is the correct shape (via group by).

Since "@dbquery" is attacker controlled, isn't that @exfiltrate?

The examples use Int! for params, so it's unclear how the framework/product deals with interpolation. While looking up the docs <https://stepzen.com/docs/custom-graphql-directives/directive...> I noticed that your blog uses "$1" and the docs uses ordered "?"

Then, I saw this one <https://stepzen.com/docs/custom-graphql-directives/directive...> and wondered what happens if I send `@rest(endpoint="http://169.254.169.254")`

Love how they condensed the first SQL query example onto one line and then gave their example over multiple, deliberately making the SQL hard to read and obscure.

What about N-N relations? How hard has doing LEFT / INNER / OUTTER JOIN become - is learning SQL really to much for the modern dev (Somewhat sincerely asking)?

Reply on news.ycombinator.com