top | item 22101092

Access directly your SQL databases via HTTP. In full security

39 points| npomereu | 6 years ago |github.com

17 comments

order

user5994461|6 years ago

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

https://github.com/PostgREST/postgrest

http://postgrest.org/en/v6.0/

awb|6 years ago

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.

zozbot234|6 years ago

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

pklee|6 years ago

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.

alexandernst|6 years ago

What problem is this trying to solve?

mike_d|6 years ago

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.

1MachineElf|6 years ago

Exfiltration of back-end data from a shelled webserver?

npomereu|6 years ago

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.

kimi|6 years ago

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