3 ms·
> 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 pro
by steve-chavez 1y ago
> 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_isolation.html https://docs.postgrest.org/en/v12/explanations/schema_isolat....
- DidYaWipe 1y agoThanks. If you're writing functions, though, it seems like nearly as much work as writing traditional endpoints, no?
- steve-chavez 1y agoNot 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.html#table-valued-functions https://docs.postgrest.org/en/v12/references/api/functions.h... [2]: https://supabase.com/docs/guides/local-development/declarative-database-schemas https://supabase.com/docs/guides/local-development/declarati...