I’m interested in your thoughts on this @mmmrrr because the more I think about it the more it seems to make sense to me to build web apps directly in Postgres, particularly using Supabase.
You mention in your Nov/2021 post that the main problem you saw with using row-level security in Postgres is that when you take this approach you end up coupling business logic with the datastore.
From my perspective, business logic ought to be coupled with the datastore because this prevents data corruption and enforces business rules. So I would be interested in learning about some of the practical drawbacks you saw in taking this approach.
As far as I can tell, Supabase is just a Postgres database, so you can fire up a Phoenix app and connect to it just like you can connect a Phoenix app to any Postgres database. This means that you can use Ecto with Supabase from Phoenix because all Ecto needs is a database connection.
I don’t see a conflict between using row-level Postgres security and Supabase as the datastore for a Phoenix app – in fact, since auth is moved out of the Phoenix layer and into the datastore layer, it makes it easier to write multiple different front end clients, thereby making the application more flexible by allowing multitenency.
So the question is why use Phoenix at all if you’re just going to have Supabase handle the data and the API generation and the auth and the business logic and basically everything except the UI widgets on the front end? I think this is in fact a very good question, and it does seem to me that most people would just be better off building their app using Supabase and some lipstick to paint a face on it with.
You make the point in your Dec/2021 post that while you think Supabase uses “the right tool for the right job”, you think it is a more complicated setup to operate than a majestic monolith in Phoenix – but this assumes that a person building an app using Supabase wouldn’t just pay $25/month to have the Supabase people operate everything, which seems to me to be the sensible way to go.
So where does that leave Phoenix? I personally think it still makes sense use Phoenix LiveView as a front-end framework for Supabase, but the particular business concern would be the determining factor here – you’re going to want a BEAM program for situations in which you need massive concurrency, or a way to hold open long connections, for some particular aspect of the business application.
