[steve-chavez]

> If my DB structure changes, I have to force new app versions on every platform because I didn't insulate back-end changes with an API.

To avoid the above problem, it's a standard practice in PostgREST to only expose a schema consisting of views and functions. That allows you to shield the applications from table changes and achieve "logical data independence".

For more details, see https://docs.postgrest.org/en/v12/explanations/schema_isolat....

[DidYaWipe]

Thanks. If you're writing functions, though, it seems like nearly as much work as writing traditional endpoints, no?

[steve-chavez]

Not really, the work is much reduced.

1. If your function returns a table type, you can reuse all the filters that PostgREST offers on regular tables or views [1].

2. The SQL code will be much more concise (and performant, which leads to less maintenance work) than the code of a backend programming language.

3. The need for migrations is a common complaint, but you can treat SQL as regular code and version control it. Supabase recently released some tooling [2] that helps with this.

[1]: https://docs.postgrest.org/en/v12/references/api/functions.h...

[2]: https://supabase.com/docs/guides/local-development/declarati...