Gipetto

Snaplet still works, and works well, though I'm not discouraging your efforts. You don't mention data anonymization. How do you prevent production PII from landing on a local dev machine?

You need to start thinking in terms of ETL. A single process of uploaded file to insert at that scale is not tenable and will only drive you mad.

scanners, script kitties, and other malfeasance

SB told everybody to make this switch. If the docs still have tutorials with getUser then that’s a huge miss on SB’s part.

This is useful for initial signup metadata that you can pass through to other tables, but that’s it. Don’t modify the users table directly since that’s owned by the Supabase process. Make a user profile table in the public schema that you own and control.

The way I’ve found to keep LLMs in check is to know what you want from it at every level. You don’t just tell it “make this feature”, you plan (with the LLM, that’s fine) the development of the feature and break down in yo logical pieces. Then you tightly oversee the production of each piece. If you find surprises in code after merging it then you’ve put too much trust in the system or you’re still working in too large a chunk. Make sure you’ve also codified in the rules that the LLM is supposed to ask clarifying questions when it meets ambiguity. Man, coding with an LLM is pretty much like riding a junior engineer like you would a horse. You want to know where you’re going and be able to take corrective action on everything. They’re basically typing for you and can quickly do research to clarify questions or compare against other parts of the system. Zero trust, lots of review. It saves me time typing and ensuring consistency across a larger system. It doesn’t know what the best course of action is.

unrelated, but I really with their damn site theme would default to the system preference instead of forcing me to pick light mode every time I come back.

I got started using the Supabase JS client, but I’m now moving over to raw sql with the Postgres library. I have some deep fetches so being able to use iterators and cursors directly within the library, as well as full transaction scopes, was a huge boon. Deep pagination with the SB client adds a lot of latency.

This local key bug must be new. I’ve been working with functions on local lately to move some things around and I haven’t had an issue. I’ll have to see what I get later today.

If you’re smart enough to do your own db management, and just need a Postgres connection, you can run as much as you want on a single Supabase project. The only reason to have multiple projects on SB is if you’re all in on auth, functions, etc. But if you’re just using Postgres then go nuts with a single project.

For reads I wouldn't personally make any death threats if I found them used on the client side, but I'd ~prefer~ argue, rant, and yell loudly about putting them in an API layer. For writes I'd 100% put them in an API layer because: 1. input validation should not happen client side, JS is simply obsfucated when compiled, and someone can easily get in and bypass your validation logic 2. business logic/rules: again, js is merely obsfucated, so someone can easily get in and see your core business logic and find ways around it, or figure out the secret sauce that may differentiate you from your competitors 3. inference of your overall infrastructure. Someone can inspect the code and get more insight in to how your application is deployed, its dependencies, and vulnerabilities 4. general security: can you guarantee that you won't accidentally log sensitive data out in the open? Paranoia is your friend. Your display layer should be allowed to format data for display, and may enforce a few business rules in how users interact with data, but a closed off and protected back-end should be responsible for the business logic and be the line of defense between your application/data and any malicious actors. Even if you know the users personally, they're simply not to be trusted. RLS is a tool you can use in your overall security posture. It isn't a total solution in itself. I really wish Supabase would take more of a stance here, but I guess it helps them onboard people to tell them that it's OK to interact with your database from a computer that is 100% out of your control.

I have a similar setup, but don’t automate schema changes. Production account is paid. Staging is free. I’ve always been paranoid about schema changes being done automatically. I have a script to run them, and make sure that changes are always backwards compatible until after the code migration, the remove obsolete items, but even so having them automated just feels like asking for lazy problems to sneak in (I’m seeing that at my current job where breaking schema changes are deployed at the same time that the new code is, and naturally there’s a span of time where the old code is addressing schema that is no longer valid). Educating folks on proper hygiene is easier when there’s no temptation to have things auto applied in tandem with a code change. But now I’m starting to rant…

Passwords should be something that can be changed and be unique from anything used to identify a user. Using a student ID as a password is like using your social security number, or drivers license number. It is something that can't be easily changed and is written down for others to discover. In short, its a bad idea. The student ID can be the username to log in with, but don't make it the password.

It is hard to tell what exact advice you are talking about, but I’d present it in a different way. You should be thinking about your database in code in two separate parts (yes, there’s more, but start here). You have the database schema which you manage via migrations, and you have the database queries that you have in your code. These should be kept and managed separately. The schema migrations are for managing your database structure. In general your schemas should be just that. Managing tables, functions, types, etc… and should not contain any data unless specifically needed. Your queries then, well, query these tables by doing selects and updates. It is very easy to break the relationship between the schema and your queries, so when making schema changes always think about making them in a way that doesn’t break your queries, so that you can apply the migrations first and then deploy the code that uses those changes. You’ll never be able to deploy them in a way that they both magically update in sync, there will always be lag between the two, and you’ll trigger errors. This will often times means that you’ll push a schema change, then deploy new code, then push another schema change that removes obsolete parts of the schema.

I’ve never noticed the squash command before and it sounds terrible. There’s no real documentation or best practices around it from what I can tell. I believe what you have found there is what we like to call a foot gun. Congratulations, you just shot yourself. Best I can tell is that squash’s sole purpose is to trick people in to thinking that they’re doing something useful where in fact you’re just lighting a fuse on your code base.

I’ve never noticed the squash command before and it sounds terrible. There’s no real documentation or best practices around it from what I can tell. I believe what you have found there is what we like to call a foot gun. Congratulations, you just shot yourself. Best I can tell is that squash’s sole purpose is to trick people in to thinking that they’re doing something useful where in fact you’re just lighting a fuse on your code base.

I use supabase’s hosted service. I also don’t let ai write code or scripts as it creates more problems than it solves. I ask ai questions, but that’s it.

I use supabase’s hosted service. I also don’t let ai write code or scripts as it creates more problems than it solves. I ask ai questions, but that’s it.

I simply followed the local development instructions on the Supabase website. I don’t pull data or schema from remote Supabase. The DB is built solely from schema updates. This means I can reset the database at any time. I have a script that can generate dummy data. Supabase also manages an NPM project called Snaplet that can pull and anonymize data from a remote Postgres database, this is handy for when you need prod sized data. Developing functions specifically is, again, just following he instructions. You need to start the functions service directly to develop them. While they run locally when you start Supabase, they don’t hot reload or give you useful logs. So run the functions service directly. I turn off SSL locally when developing. Requiring SSL for a local dev environment is not worth it. I don’t know how you’re using proxies, but the more you can remove network/remote dependencies from you local dev workflow the happier you’ll be long term (this is true of any project, not just those using Supabase). I don’t have a problem when the containers update. The DB instance should store the data locally. The only thing that should reset that local database is specifically running ‘supabase db reset’. So if you’re losing data when containers update then you’ve got something very weird happening in your process.

I simply followed the local development instructions on the Supabase website. I don’t pull data or schema from remote Supabase. The DB is built solely from schema updates. This means I can reset the database at any time. I have a script that can generate dummy data. Supabase also manages an NPM project called Snaplet that can pull and anonymize data from a remote Postgres database, this is handy for when you need prod sized data. Developing functions specifically is, again, just following he instructions. You need to start the functions service directly to develop them. While they run locally when you start Supabase, they don’t hot reload or give you useful logs. So run the functions service directly. I turn off SSL locally when developing. Requiring SSL for a local dev environment is not worth it. I don’t know how you’re using proxies, but the more you can remove network/remote dependencies from you local dev workflow the happier you’ll be long term (this is true of any project, not just those using Supabase). I don’t have a problem when the containers update. The DB instance should store the data locally. The only thing that should reset that local database is specifically running ‘supabase db reset’. So if you’re losing data when containers update then you’ve got something very weird happening in your process.