Wow, these are very useful. Is there an example project that demos the best way to setup these features? edit: I see TFA links to the docs where most things are covered ( https://supabase.com/docs/guides/cli )
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)
Supabase Local Dev: migrations, branching, and observability
31–40 of 57 posts
Re: Supabase Local Dev: migrations, branching, and observability
#32Re: Supabase Local Dev: migrations, branching, and observability
#33Earlier quoted context omitted.
One killer feature from Firebase is anonymous authentication https://firebase.google.com/docs/auth/web/anonymous-auth This allows for a frictionless onboarding process for startups. Are there plans for Supabase to support that?
that's on the roadmap - definitely one of our most requested Auth features. I don't have a timeline yet, but I know it's somewhere at the top of the (kanban) list for the Auth team
Re: Supabase Local Dev: migrations, branching, and observability
#34Cool to see dev-ex improvements around local Postgres testing. At Graphite we use pg-mem for fast unit tests, but it's not ideal. It's extremely fast, but certain advanced queries aren't supported. Curious about what others do for unit testing Postgres operations? https://github.com/oguimbal/pg-mem
I've heard about testcontainers [1] before, which can be used for Postgres. I've used it a bit, but the Elixir library for it is still under development [2] so I haven't been able to try it at work. Elixir's Ecto library is pretty good at wrapping Postgres for tests though [3].
[1] https://testcontainers.com
[2] https://elixirforum.com/t/excontainers-throwaway-containers-...
Re: Supabase Local Dev: migrations, branching, and observability
#35Earlier quoted context omitted.
After being burned by other DaaS providers (looking at you AWS Amplify/Cognito), I've been skeptical to use anything other than rolling my own solutions. Supabase updates does continue to impress, and I do really appreciate these improvements to local development.
> rolling my own solutions I would love to hear what solutions you're choosing. one of our goals is to provide only the tools/tech/features that you'd choose yourself or need to build to get started. If you're skeptical based on our technology choices then it's useful to receive that feedback
Unrelated to DBs, I've been thinking about trying to roll my own system for magic links recently. Even though Supabase has some of the lowest costs for MAUs, they're still too high if you're only using magic links, especially considering the related email rate limits [1]. I don't even know if I'm reading that right. Is it 4 auth related emails per hour by default?
I can run a Cloudflare Worker for $0.0000005 vs $.00325 for a Supabase MAU. Assuming it would normally take 2 Worker runs to generate and auth a magic link, a user that signs up and never comes back would cost me 3250x more if I use Supabase.
Not all users are equal and, for low value users that probably never convert to paid users, I don't need to give them a full blown user account with MFA, etc.. Magic link based auth is adequate for what I need and I don't want to pay between 300,000% (for Supabase) and 15,000,000% (for Auth0) markup above the raw compute costs for someone that signs up and never comes back. For a user that converts to a paying customer, I don't really care about the cost as long as I don't have to eat it for every free user I have.
I know there are other costs, and that the requirements for magic links are more complicated than at first glance, but those costs are relatively fixed in the context of magic links, right? If the only major ongoing cost is for email, where I'm basically expected to bring my own provider, the MAU cost for a user that only uses magic links feels like a bad deal.
This isn't just a Supabase issue either. The entire auth industry is similar. I need the simplest part of the existing solution, but I'm forced to pay, in both cost and complexity, for the complicated, expensive part of the solution that I don't need or want to use. Does that make sense?
1. https://supabase.com/docs/guides/platform/going-into-prod#au...
Re: Supabase Local Dev: migrations, branching, and observability
#36Make 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 provide more details on our experience.
Re: Supabase Local Dev: migrations, branching, and observability
#37I 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…
The mentioned migrations for example, don't work if your database is not very simple (e.g. triggers typically won't work because the dependency order is wrong, custom types are not supported, etc.), and this has been the case for some time.
The documentation for the most basic functionality is also quite poor and requires digging through the TS source for detail. For example, here's the JS lib auth signInWithPassword function:
Log in an existing user with an email and password or phone and password.
Requires either an email and password or a phone number and password.
Parameters:
credentials (required) SignInWithPasswordCredentials [no link to what this is]
And an example is given: const { data, error } = await supabase.auth.signInWithPassword({
email: 'example@email.com',
password: 'example-password',
})
That's all. There is no explanation of what data/error might return, error conditions, whether it can throw, etc. Looking at the source, the are a variety of additional parameters (user meta data, captchaTokens ) that are not mentioned at all. The site has various articles, howtos, videos etc. that explain different bits of functionality, but the core reference is incomplete and it's a pain to dig through blog posts to discover basic functionality.To be clear, I think it's a great product, and the open source aspect and great communication from the team is a big plus, but I do think more time could be spent getting the basic product right before chasing 100s of new features.
Re: Supabase Local Dev: migrations, branching, and observability
#38I 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…
- 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 functions
Re: Supabase Local Dev: migrations, branching, and observability
#39For context, my local dev process is now as follows:
1. supabase db reset with seed.sql empty 2. run a preseed script that disables any triggers and removes default data that has been previously seeded in migrations 3. seed data 4. reenable triggers 5. execute any working migration files that I keep in a separate file
I've written a script that handles all this, so I have mostly solved this for myself - but this was mostly due to running into a bunch of challenges setting up my local env to work well. Very open to general comments on approach too - perhaps there is a simpler way
Re: Supabase Local Dev: migrations, branching, and observability
#40Earlier quoted context omitted.
> rolling my own solutions I would love to hear what solutions you're choosing. one of our goals is to provide only the tools/tech/features that you'd choose yourself or need to build to get started. If you're skeptical based on our technology choices then it's useful to receive that feedback
I'm not the GP. Unrelated to DBs, I've been thinking about trying to roll my own system for magic links recently. Even though Supabase has some of the lowest costs for MAUs, they're still too high if you're only using magic links, especially considering the related email rate limits [1]. I don't even know if I'm reading that right. Is it 4 auth related emails per hour by default? I can run a Cloudflare Worker for $0.…
It's unlimited emails per hour, as long as you BYO SMTP provider. The default email service is only for testing, and not recommended for production. I usually recommen AWS SES or Resend[0] for unlimited emails
> This isn't just a Supabase issue either. The entire auth industry is similar.
Agreed - the industry prices on MAU, which isn't a great heuristic. for social websites, 1M users might be a low number. For B2B SaaS even 1,000 MAU could be high. For Supabase, we simply try to be fair and transparent (and we're an order of magnitude cheaper than other Auth providers). There are a lot of other things that you're _not_ paying for which we have to price in - regular security audits, zero-day support, etc.