4 ms·
At this point you may as well expose SQL to the client?
by potamic 4y ago
At this point you may as well expose SQL to the client?
- piaste 4y agoGraphQL 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.
- jasfi 4y agoIf 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.
- ako 4y agoPersisted 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.
- deleted 4y ago[deleted]
- jasfi 4y agoTrue, but I was thinking from a web client. Perhaps if table and column names were aliased? Not that different from GraphQL.
- piaste 4y agoGraphQL 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).