Is there an industry precedent for SQL pass-through endpoints? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 1 year ago.

Improve this question

There is an increasing interest toward GraphQL and Falcor across the Web. Each time I see an article or discussion about those, I get reminded about SQL, at least its DQL part.

Obviously, sending raw SQL queries over the wire gives the client too much power; however, with the most recent versions of DB—Postgres could be an example—we could limit which users could invoke which stored procedures, and even which rows could they see.

Sorry if I'm missing something obvious, but it seems to me that with carefully designed query complexity control, with row-based auth and with well-separated per-user privileges, one could just pass a client-formed SQL query straight to the DB engine, and be safe, thus replacing GraphQL with just SQL, and saving one conversion layer in our app.

Has there been any such prior experience in the world?

Answer 1

one could just pass a client-formed SQL query straight to the DB engine, and be safe

Nope. Let's assume that your security is perfect. I can still write a long running query that locks your tables.

saving one conversion layer in our app.

Unlikely. User management, auth tokens, serialising, versioning, fail over etc mean that you are probably going to be unable to completely remove the api layer

Answer 2

The last 20-40+ years of systems development can be seen as largely trying to manage the tension between the fact that users want freedom to do what they want in a system, but the owners of the system are more particular. The owners don't want the database screwed up, they want some things secret and some things not, things that are secret are only secret to some users but OK for others to review (but maybe not to edit), they want some users to do some things but not others, and they want the database resources to remain available (not to crash, degrade, or chew up tons of expensive computational/electrical/storage resources).

The thing is, the better the database is at giving some power-users what they want (like developers), the worse they are at serving the needs of other users. It is not a question of whether or not the functionality exists to batten down the hatches and encode security in complex database systems - it is that if you try to do it, you will find it sucks.

Just ask a database administrator of a modest-sized system how hard it is to keep databases working and available even when the system is only used by carefully authorized users who are supposed to know what they are doing, and who are not supposed to be expected to have ill intent. Its a full-time job for a reason! Databases which serve the needs of an organization (i.e. management) and the needs of developers are already hard to work with as it is!

And developers of the database systems themselves seem to understand this well. They don't particularly try to design the systems to be exposed to end-users directly, largely because they know it won't work out. The system prioritizes the needs of other users, and that means if the system is to be good for some it must be inaccessible to others.

Instead, you can try to design a system for users to access directly, but this will involve different trade-offs in what functionality is safe and what isn't. Or, Option B - create a pass-through layer!

Layers work precisely because each layer can be designed with a small subset of users and functionality in mind, and thus you can have a world-facing layer, an application-developer only layer, a data-management layer, etc.

It exists because it, well, works.