3 ms·

I’m talking about the stack as a whole, which happens to be built on PostgREST. The OP’s goal was to simplify their stack, which they did do. However, they can

by nwsm 6y ago

I’m talking about the stack as a whole, which happens to be built on PostgREST. The OP’s goal was to simplify their stack, which they did do. However, they cannot run this stack without managing a database, as the database and REST API are run in the same container. My point is that another way to lower a project’s required effort is to offload database management. Sure, OP now only has two layers in the stack instead of three. But now they are locked into managing the database entirely, including updates, backups, and scaling.

nvader 6y ago
Okay, I think this idea has legs. There's a proven market for Serverless offerings, so how would people react to a SaaS product that: a) Did database management for you, a la Amazon RDS (perhaps later supporting BYO Cloud Database) b) Provided a software programming layer that simplified coding, versioning, deployment and rollbacks of Stored Procedures c) Perhaps provided a language environment that lets you program with an SDK in your language of choice, and then "lifted" that into stored procedures My first thought when faced with this is, how do I do application monitoring, logging, exception handling, paging? Perhaps this is a solved problem, but I'm curious.