2 ms·
In a few projects where we had a specific experiment we needed insights from we ran PostGrest[1] Basically you create your tables and run PostGrest. Bam! You h
by Just1689 7y ago
In a few projects where we had a specific experiment we needed insights from we ran PostGrest[1]
Basically you create your tables and run PostGrest. Bam! You have an http interface / api for your database. We would then create light wrappers around those that took on specific responsibilities - security, audit etc. The wrapped apis is what we exposed publicly.
This may not sound all that helpful but it made the bit we implemented unbelievably tiny. As a plus, we found that a Java application that exposes an endpoint and calls an endpoint is fast to start / stop because it doesn't mess around with DB connection pools.
[1] http://postgrest.org/en/v5.2/ http://postgrest.org/en/v5.2/
- nprateem 7y agoThat sounds like a good balance. I've looked at postgrest in the past but the thought of writing my auth logic in SQL and relying on row-level perms made me sweat too much.
- royjacobs 7y agoHow do you handle versioning? If you add a new required field to one of the tables (perhaps even a field that doesn't have a default value), how do you make sure the consumers of your old API keep working?
- steve-chavez 7y agoYou can handle versioning with PostgreSQL schemas. You can have v1, v2, etc. These usually contain views and stored procedures.
- krueger71 7y agoI've also used PostgREST successfully. It was first meant as a tool for rapid prototyping, but it worked so well that we kept it. We ended up separating the database into a schema called api, consisting only of views of the core domain tables available in the data schema. PostgREST exposed the api-schema only. This way we could model a stable interface and vary the low-level details of the domain tables. Writes were handled by instead-of triggers on the views. So far this has been the quickest way of building an API that I know of.