Hacker News new | ask | show | jobs
by chadhutchins10 2112 days ago
One of the best use cases for this is say you have a backend/internal system and you want other things to start interacting with it. Instead of having to write the api to interface with it, you can just use something like this and with little effort you have an api and can talk with the database.
1 comments

I think the point he was making is: why the API if you just want to talk to the db? You can connect to a SQL db over the network and protect the data with views and stored procedures.
Because you can't (easily) connect to an SQL DB from any arbitrary client, like a web browser or mobile app.
That's actually exactly what we're trying to build at Splitgraph [0]. :) We're building a "data delivery network" (DDN), which is like a CDN, except instead of forwarding HTTP requests to upstream web servers, we forward SQL queries to upstream databases.

The premise of the idea is that we can cut out the middle-man for a lot of data distribution use cases. We give you a way to deliver your data in native SQL, using the Postgres wire protocol. We've decoupled authentication from the database, so we can do it in a gateway / LB layer using PgBouncer + Lua/Python scripting. Any SQL client can connect to the public Splitgraph endpoint (as far as a client is concerned, Splitgraph is just a really big Postgres database). You can write queries referencing and joining across any of the 40k datasets on the platform.

In fact, just this week we've been working on v0.0.0 of our web client. This lets you do things like share and embed SQL queries on Splitgraph, e.g. [1] (this query actually joins across two live data portals at data.cityofchicago.org and data.cambridgema.gov).

There's also an example here of using an Observable notebook with the Splitgraph REST API [2]. It also works with the Splitgraph DDN configured as a Postgres database, but that's only supported in private notebooks for now (since normally it's a bad idea to expose your DB to the public!)

In general, we like the idea of adding more logic to the database. Tools like OP's are useful in this regard. In fact, at Splitgraph we use Postgraphile internally (along with graphql-codegen for autogenerated types) and we have nothing but good things to say about it.

[0] https://www.splitgraph.com/

[1] https://www.splitgraph.com/workspace/ddn?layout=hsplit&query...

[2] https://observablehq.com/@mbostock/hello-splitgraph