mattbrown7531

I will try out pg-delta. Didn’t know about it. Thanks!

I think you're trying to push the human-ai boundary to a place it doesn't need to be. You're talking about AI generated specs. Doesn't seem like a good application of AI.

I get that the harness becomes more difficult as the requirements get more complex. Your RLS example is straightforward but I understand what you're saying. I think AI does have the capability of generating the tests, especially if you provide clear, specific acceptance criteria. Like any LLM-generated output, the tests still need to be reviewed and validated. The acceptance criteria should be written in plain English by a human and validated before asking AI to implement them. Maybe we're talking about something similar. Human define the expected behavior and AI and other tooling automate the test implementation

It almost sounds like you're suggesting the AI uncover requirements? Or at least infer them from existing procedures. Then you skip the step of defining expected behavior and writing acceptance criteria in plain english. I think AI can help with automate test implementation like pgTAP boilerplate but it shouldn't be responsible for uncovering expected behavior.

My first question is how are you handling migrations? Supabase Declarative Schemas could help by keeping the current definition of function in schema files rather than creating a new migration file every time a function changes. Supabase can then generate the migration from the schema changes. Then the AI doesn't have to sift through versioned migration files. You could create pgTAP tests around stable public contracts and important side-effects, rather than writing tests for each migration file.

You should always define or validate the business logic of the tests. If you avoid this step, you are taking yourself out of the loop. I'd be too nervous to let AI handle everything.

I'm thinking about the pros and cons of something like AppGrape studio. My first thought is that I always use AI to build the UI. And if the UI is too complicated to use AI, then it would also be too complicated to use a UI builder. If I'm repeatedly building a specific type of product like a Restaurant Management SaaS. Then I could build a software framework and not rely on a UI builder. I'm trying to understand what the market is here. It's a cool idea but curious what type of customers have been using it?

You gotta say a bit more. Hard to understand. Are you saying that you can't preview the changes before deployment? That's what dev and test and environments are for.

I don't quite follow. Are you referring to declarative schemas or using standard versioned migrations?

So then for the manual list for views, grants and policies, it seems like it would be better to put in a repeatable file. That way you’re not constantly creating new files when you make small changes to views. What do you think?

Will definitely use declarative schema in the future. Squashing can help when taking over existing projects to simplify the migrations. I know it does stabilize over time but on complex projects, schemas continue to evolve.

The main thing I disliked about that workflow was creating a new file for each change to a view. I update views constantly, and it was annoying to have to find the most recent version. The same went for RLS but to a lesser extent. Also, I just want everything in my codebase to be clean and clear. It makes me much more efficient. I also want a new developer on the team to get up to speed faster. Being able to view the organized migration files helps with that.

Yeah on my first project. I jammed everything in one file. It was a nightmare to work on. Next project I was much more deliberate on design.

Cool! I'm exploring the declarative schema now. In the docs, it mentions RLS is in the caveats as a place where the diff could fail. I'm wondering if a hybrid approach could work supabase/ \-schemas/ \--001\_tables.sql \--002\_views.sql \--003\_functions.sql \-security/ \--001\_rls.sql \--002\_grants.sql \--003\_storage.sql This way, the security is kept in a separate workflow that runs after the migrations. It keeps the security -related SQL consolidated in one place, making it easier to audit. And the history is still preserved by git so we don't lose it. I'm still thinking through the tradeoffs, though. Maybe it's okay to keep RLS in the schema folder and review the migrations carefully?

Love it! I think it can be reframed as practical advice. I broke it down into four steps. **Review Supabase Security findings** Make sure that RLS is enabled for all exposed tables. Supabase will highlight a lot of configuration issues but you need to be aware and implement the fixes **Evaluate RLS to ensure that it’s not too broad.**  Supabase can flag some RLS policy issues but it can’t fully determine correct RLS boundaries because that depends on your app’s business rules. If RLS is enabled and no policy exists, the request would fail. This risk is a broad policy like this one. A policy like this would make the app work, but would open up that table to all authenticated users. create policy "Authenticated users can do anything" on todos for all to authenticated using (true) with check (true); Generally, users should have access to their data and data from teams they belong to. **Don’t use the service role key in the frontend** Use the publishable/anon key in the browser. Secret/service-role keys are for trusted backend code only. For the new sb\_secret\_... keys, Supabase added a runtime protection: if a secret key is used from a browser, it returns 401 based on the User-Agent header.  **Be careful with the service role in backend routes** Not necessarily wrong but if the route is called by user requests, it would need to perform it’s own auth check

I think I should have been a bit clearer. Yeah the choices are between auth at the edge and auth in Python. Everything else would be in Python in both patterns. But it seems like over-engineering to have a separate layer just to verify JWT. Maybe there's something else?

Yeah definitely. Let me know how I could submit.