Nicolas Martyanoff on Nostr: npub1fzx00…wt6h3 It is not a bad idea as long as your application is mostly a thin ...
npub1fzx00c36ny4whyuhg4ykx6987wxp885fmwmc784n27qcu6pavwzs3wt6h3 (npub1fzx…t6h3)
It is not a bad idea as long as your application is mostly a thin layer above stored data. If you start having to compose objects from a mix of data from the database and data computed from other sources (e.g. network calls), you'll end up having to build final objects in your code anyway.
I would also be concerned by how annoying it is iterate on PostgreSQL during development. In a traditional application, you can just modify the code, recompile and execute. With PostgreSQL functions, you'll need to drop/update the right functions/types all the time, and sometimes it gets really annoying (e.g. remove enum values). But I imagine one can build tooling to help with that.
It is not a bad idea as long as your application is mostly a thin layer above stored data. If you start having to compose objects from a mix of data from the database and data computed from other sources (e.g. network calls), you'll end up having to build final objects in your code anyway.
I would also be concerned by how annoying it is iterate on PostgreSQL during development. In a traditional application, you can just modify the code, recompile and execute. With PostgreSQL functions, you'll need to drop/update the right functions/types all the time, and sometimes it gets really annoying (e.g. remove enum values). But I imagine one can build tooling to help with that.