Hacker News new | ask | show | jobs
by TjZkxkxeky 1016 days ago
It's certainly not a new idea, however. Every product that allows backdoor access into their database directly has effectively done this. Hope you have your schema correct when your customers build a mountain of cards on top of your database schema.
1 comments
jampekka 1016 days ago
How does this differ from them building a mountain of cards on top of your API?

The schema used by the public API doesn't have to match the database layout itself. E.g. views can be used for this.

A lot of APIs are quite straightforward mappings typically from REST/GraphQL to a database, often via some sort of ORM or other abstaction. These extra layers mostly amount to needless complexity, more surface of bugs, lots of busywork and worse API usability.

link
TjZkxkxeky 1016 days ago
It differs dramatically. Your API is likely much much smaller than the inherent API of SQL tables. It's a difference in degree that is a difference in kind.

Anyways, every old idea must be retried.

link
jampekka 1016 days ago
I don't see much difference between a set of SQL tables to a set of API endpoints that let you list a set of "objects". At least in read-only cases with no sensitive data.

Of course there's the big difference in that with SQL you can compute and join tables server side, sparing a lot of traffic of doing this manually (or coming up with ad-hoc ways of doing it). It's not like the SQL itself is gonna substantially change.

The schema can be restricted or kept compatible with e.g. views as mentioned before (although I'd go more for the consenting-adults philosophy here too). Too heavy queries can be limited with e.g. query timeouts, quotas or query priorities. And you usually have to do such things somehow anyway.

I have hard time seeing major concrete problems with the approach that don't have existing straightforward solutions. I do see a lot of unfounded FUD.

For writes and sensitive data it gets trickier, but for many cases it would be probably easier to secure the database interface than to do it ad-hoc on a "business layer".

I haven't heard the idea of public facing SQL querying floated around much in at least over 20 years. When it's proposed, the response is usually knee-jerk no, as seen in most comments in this post.

Also I'm not much of a fan of SQL itself but I'm against the current software development philosophy that computing should be made as restricted, layered and inflexible as possible.

link