Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Supabase Local Dev: migrations, branching, and observability

supabase.com

Post reply on HN
Print view View original

41–50 of 57 posts

Re: Supabase Local Dev: migrations, branching, and observability

#41

Post by kiwicopple »

daniel-ash wrote: post #39

Something I'd like to see with local development and the Supabase CLI is timing around inserting seed data, handling triggers, default data. I ran into a bunch of issues getting a nice local dev setup. For example seeding data after migrations is not helpful (and will fail) if your latest migration is destructive - you want to seed data and then run the next migration. For context, my local dev process is now as foll…

> I've written a script that handles all this

Would you mind sharing this in a gist? We can add this functionality to the CLI

Re: Supabase Local Dev: migrations, branching, and observability

#42

Post by fulafel »

kiwicopple wrote: post #2

hey hn, supabase ceo here a few months ago one of customers migrated away from supabase and they wrote a blog post about it. That blog post appeared here[0] on hacker news. many of the issues they encountered were related to local development. we made several promises to improve based on that feedback and the various comments in the HN thread today’s launch delivers on many of those promises. We’ve added better suppo…

In the original posting from Val Town I didn't quite catch why in lieu of local dev they did't use dedicated dev dbs (possibly per developer) in the Supabase service.

Anyone have perspectives on pros and cons of local dev vs cloud dev environments with Supabase?

Re: Supabase Local Dev: migrations, branching, and observability

#43

Post by kiwicopple »

theultdev wrote: post #31
kiwicopple wrote: post #19

Earlier quoted context omitted.

Here is an example project: https://github.com/supabase-community/vercel-ai-chatbot You'll see there is a "supabase" folder inside it so you can clone it and run "supabase start" to get started immediately. You can also hit the blue deploy button and you'll have a full application deployed in ~1 minute (frontend on Vercel, backend on Supabase)

This doesn't include any of these newly announced features...

these newly announced features are all inside the CLI, so i'm not how else to show an example project. After installing the CLI, you can run `supabase start` and it will pick up all the Migrations[0]. The CLI starts a local dashboard to see the logs[1]. After pushing to production you can run a backup[2], etc.

from your edit above, perhaps you were just looking for the docs but let us know if there is anything else you need

[0] Migrations - https://github.com/supabase-community/vercel-ai-chatbot/tree...

[1] Logs - https://supabase.com/blog/supabase-local-dev#local-logging-a...

[2] Backup - https://supabase.com/blog/supabase-local-dev#easier-backups

Re: Supabase Local Dev: migrations, branching, and observability

#44

Post by kiwicopple »

vendiddy wrote: post #36

I love the innovation coming out of Supabase and want use it, but I feel like the team ought to focus on polishing what is already there before investing so much in R&D. Make the platform SDKs to feature parity, make RLS easier to use, improve auth (for ex add anonymous users and native login), polish file uploads, etc. Supabase has a ton of potential, so hopefully this is taken as constructive feedback! Happy to pro…

> focus on polishing what is already there before investing so much in R&D

fwiw, this post is exactly that. Everything in this release is an improvement to existing functionality within the CLI, as response to similar feedback we received here[0].

There are a lot of "behind the scenes" improvements which don't get visibility on HN - only new features tend to get upvoted so I think we have a reputation which isn't representative of our day-to-day focus.

That said, we know there are a lot of shortcomings remaining (as you point out, and the comments below). Please do continue to share details on your experience, in the github issues preferably, so that we can focus on the most important tasks first.

[0] https://news.ycombinator.com/item?id=36006018

Re: Supabase Local Dev: migrations, branching, and observability

#45

Post by daniel-ash »

kiwicopple wrote: post #41
daniel-ash wrote: post #39

Something I'd like to see with local development and the Supabase CLI is timing around inserting seed data, handling triggers, default data. I ran into a bunch of issues getting a nice local dev setup. For example seeding data after migrations is not helpful (and will fail) if your latest migration is destructive - you want to seed data and then run the next migration. For context, my local dev process is now as foll…

> I've written a script that handles all this Would you mind sharing this in a gist? We can add this functionality to the CLI

Not at all: https://gist.github.com/Daniel-Ash/0ddf135cc0d9341d9d13dadba...

Re: Supabase Local Dev: migrations, branching, and observability

#46

Post by [deleted] »

cjonas wrote: post #38
vendiddy wrote: post #36

I love the innovation coming out of Supabase and want use it, but I feel like the team ought to focus on polishing what is already there before investing so much in R&D. Make the platform SDKs to feature parity, make RLS easier to use, improve auth (for ex add anonymous users and native login), polish file uploads, etc. Supabase has a ton of potential, so hopefully this is taken as constructive feedback! Happy to pro…

100% agree... I've been using super base for a new project for a few months and while overall I'm impressed, there are just too many bugs and partially rolled out features. Here's my current gripe list: - features/ui missing from local development - more secure triggering of edge functions from database (currently have to hardcode key in SQL) - template URL support for edge function - source maps are broken in edge f…

[deleted]

Re: Supabase Local Dev: migrations, branching, and observability

#47

Post by laktek »

cjonas wrote: post #38
vendiddy wrote: post #36

I love the innovation coming out of Supabase and want use it, but I feel like the team ought to focus on polishing what is already there before investing so much in R&D. Make the platform SDKs to feature parity, make RLS easier to use, improve auth (for ex add anonymous users and native login), polish file uploads, etc. Supabase has a ton of potential, so hopefully this is taken as constructive feedback! Happy to pro…

100% agree... I've been using super base for a new project for a few months and while overall I'm impressed, there are just too many bugs and partially rolled out features. Here's my current gripe list: - features/ui missing from local development - more secure triggering of edge functions from database (currently have to hardcode key in SQL) - template URL support for edge function - source maps are broken in edge f…

Hey @cjonas, I'm a developer on Supabase Edge Functions team. We do have plans to improve the current database trigger behavior. Will share more updates on this in the coming months.

Can you explain what do you mean by template URLs? Do you mean route params like `/v1/functions/users/:id`? If so, you can use a framework like Oak[1] to handle them. Edge Functions will make the full path including querystring available to the router.

Also, you can use URLPattern API to match paths. Here's an example of RESTful API built using that: https://github.com/supabase/supabase/blob/master/examples/ed...

Source maps, is it broken during local dev or when you deploy the function? Also, by broken you mean in a stack trace the file / line numbers aren't accurate?

[1] https://github.com/oakserver/oak

Re: Supabase Local Dev: migrations, branching, and observability

#48

Post by sweatybridge »

daniel-ash wrote: post #39

Something I'd like to see with local development and the Supabase CLI is timing around inserting seed data, handling triggers, default data. I ran into a bunch of issues getting a nice local dev setup. For example seeding data after migrations is not helpful (and will fail) if your latest migration is destructive - you want to seed data and then run the next migration. For context, my local dev process is now as foll…

> if your latest migration is destructive - you want to seed data and then run the next migration.

We have added supabase migration up [0] command that runs only pending migrations (ie. those that don't exist in local db's migration history table). You can use that to test destructive migration locally with data from seed.sql.

After testing, you want to update your seed.sql with a data-only dump [1] from your local db. That would make CI happy with both the new migration and the new seed file.

> 2. run a preseed script that disables any triggers and removes default data that has been previously seeded in migrations

It sounds like the default data is no longer relevant for your local development. If so, I would suggest running supabase migration squash [2] to remove the default data.

To disable triggers before seeding data, you can add the following line to seed.sql [3]

SET session_replication_role = replica;

[0] https://supabase.com/docs/reference/cli/supabase-migration-u...

[1] https://supabase.com/docs/reference/cli/supabase-db-dump

[2] https://supabase.com/docs/reference/cli/supabase-migration-s...

[3] https://stackoverflow.com/questions/3942258/how-do-i-tempora...

Re: Supabase Local Dev: migrations, branching, and observability

#49

Post by daniel-ash »

sweatybridge wrote: post #48
daniel-ash wrote: post #39

Something I'd like to see with local development and the Supabase CLI is timing around inserting seed data, handling triggers, default data. I ran into a bunch of issues getting a nice local dev setup. For example seeding data after migrations is not helpful (and will fail) if your latest migration is destructive - you want to seed data and then run the next migration. For context, my local dev process is now as foll…

> if your latest migration is destructive - you want to seed data and then run the next migration. We have added supabase migration up [0] command that runs only pending migrations (ie. those that don't exist in local db's migration history table). You can use that to test destructive migration locally with data from seed.sql. After testing, you want to update your seed.sql with a data-only dump [1] from your local d…

Thanks, appreciate this. A few comments:

I like being able to call supabase db dump (data only) and not touch code in the file at all - I get that adding SET session_replication_role = replica; is one line, but still my preference is to avoid. But like I said I already disable triggers ahead of the seed script running.

I currently use supabase db reset quite frequently as I make changes in development. Using supabase migration up would mean moving the latest migration out of the migrations folder, running supabase db reset, moving the file back in and then calling supabase migration up. Which is not the worst idea, I'd still be looking to automate those steps with my own script atm tho.

Re: squash I have been a little cautious to use it since I first noticed it in the CLI docs as I wasn't really sure what the actual outcome would look like If I have something like this in a migration script:

--set initial permissions INSERT INTO rbac.permissions(name) SELECT unnest(enum_range(NULL::rbac.permission_name)) except SELECT name FROM rbac.permissions;

what would squash do to handle this data?

Post reply on HN