Access directly your SQL databases via HTTP. In full security | Hacker News Reader

Access directly your SQL databases via HTTP. In full security

github.com

39 pointsnpomereu17 comments

Look similar to postgrest, but younger project under (L)GPL license.

These tools like Postgrest are super fun but in the end, I always end up needing an API for secure business logic. At that point, these tools where "your DB is your API" just become another part of your backend rather than replacing the backend, and the value of that isn't clear to me.

It's awesome for hobby projects, but I wasn't able to figure out how to use it to build a SaaS app.

Even if it's not your only backend API, it still saves effort and repetitive plumbing.

Postgrest includes security(paired with PG's row level access). plus if you go the way of pl/python or other languages built-into PG(includes javascript, c, etc, etc), you can get very far before you have to go add more layers. But even if you do, it can still be pretty great.

Why not just set up a SPARQL endpoint, which seems to be the recommended standard for accessing data over Web platforms?

Where is this recommended ? Also SPARQL as a query language is about "how" you want to get to your data (the relationships you traverse changes your final result) as opposed to SQL which is about "what" you want, set algebra. Not to mention the super grotesque format and the performance.

What problem is this trying to solve?

Exfiltration of back-end data from a shelled webserver?

Seems like if you already have a shell it'd be easiest to just dump data directly over a pipe.

I guess SQL over HTTP could be used to directly operate on databases from resource constrained devices that don't support the full socket library for whatever database you're using?

>I guess SQL over HTTP could be used to directly operate on databases from resource constrained devices that don't support the full socket library for whatever database you're using?

Indeed. I think botnets could be an example of such "devices."

I've written a dozen internal dashboards where something like this would have been useful. Rather than writing server side code to craft queries and return results, you can add arbitrary queries easily to the front end. Just use a read-only DB account and you are golden.

Is it the right way to do it? No.

Is it something you can stand up in a few hours so you can work on the things that keep your startup afloat instead? Absolutely.

This sort of tool would be nice for PoC - but if you're using it for production anything and have any customer information (or really, any information of value) saved in that database... it would be terrible - even off an R/O connection.

Just a little clarification: the architecture is 3-tier, databases are not directly exposed; the software includes an authentication layer and firewalling rules: you have fine granularity on tables & columns access per user.

I suspect this would violate a bunch of privacy protection laws if done poorly. At least in my country "processing" private data also includes querying against it.

Some use cases & examples: 1) Allowing mobile App code to access directly remote data without programming intermediary Web services. 2) Python data scientists can crunch any SQL databases in their organization using standard PEP 249 API calls, even if the SQL engine is far away. 3) Data publishers can expose more easily and quickly their data, without having to export tables in tar.gz / zip files for download and create dedicated and documentated web pages for that.

This sounds like an awful bad idea, but for very quick prototyping.

rest and odata?

Reply on news.ycombinator.com