I was, but this approach makes it function as a single application, kinda. You're not exposing your underlying data storage directly to consumers.

The weird thing here is your interface is still SQL. Sometimes that's fine, but I think this API-schema approach really takes off when you use something like PostgREST, PostGraphile, or Hasura to automatically turn this API schema into a web API. Lots of nice benefits to those tools, and then you have a single service that is more what users might expect.

I actually discovered this API-schema approach from the docs of one of those tool...I just can't remember which one.

> I actually discovered this API-schema approach from the docs of one of those tool...I just can't remember which one.

Maybe from https://postgrest.org/en/v10.2/schema_structure.html

Yes, I think that was it! Interesting to see they have removed that page in more recent version of the docs.

It wasn't removed, just badly reorganized. It's here now: https://postgrest.org/en/stable/explanations/db_authz.html#s...

The problem I see is that tables and views are a poor general purpose interface: if you don't know what the indexes are, you can't guarantee reasonable performance.