This Supabase Feature is Dangerous...

{ts:112} they're moving in the right direction but initially it was sort of pitched as you have this client side SDK and you {ts:119} can communicate with your database directly on the front end and then the way that's secured is with row level {ts:124} security which is basically just a bunch of policies that define whether or not a user can successfully make a SQL query … {ts:150} going through and saying okay you can only read your own stuff we secure that one table that way and then we can go {ts:156} ahead and just read it from our front end we don't have to worry about spinning up a server on the back end it {ts:161} just works and the problem with this is that real applications and real databases are never that simple the {ts:167} project that I tried to use this architecture on was block and right now I think we have something like 20 tables {ts:174} and that's tame compared to most real applications all of those tables have tons of stuff on them they are a lot of {ts:180} very complicated relationships in there because we need to get all of the events working we need to link those to people … {ts:205} when you want to deal with stuff like relations and owners and all these different things it just gets so {ts:210} unwieldy and it's so easy to just let one little thing slip through and then your entire app falls apart it just {ts:216} isn't feasible and if you want even more proof that these direct access databases of service things are not a good idea go