ashkanahmadi

What do you need to do exactly? When someone is added to your Supabase database, they get added to your newsletter list as well? That’s much easier than you think. What you need: 1. trigger on your auth.users to run an edge function 2. Get an API form your newsletter platform like MailChimp and add it to your edge function secrets 3. Have a function that receives the database data and then sends their info to the newsletter platform’s API to add the user to the list automatically. If you need extra options, you can have a have a profiles table with their name, and another table with marketing permissions so you check if they should be added to the newsletter or no.

There are multiple problems with how people are using AI. The result is bad because the input is bad and the input is bad because the prompter has zero idea how proper backend and frontend separation works. The issue I constantly see is that these AI tools like Lovable include the Supabase project into the vercel project which is a very bad idea. You never mix frontend and backend projects together. That’s why slapping it with another patch or library will not fix it. It’s a bandaid solution. The AI is as good as the prompter’s knowledge of web development.

Thank you. I actually asked about it a few days ago and someone from your team told me about the new server library. I looked into it. It seems well done but I haven’t migrated yet

Great thank you. This seems like a much easier and less convoluted approach than what was introduced a few months so good job 👏 I see it's in beta mode. Is it safe to use on a production project or better to wait a few weeks/months for the stable version? Thanks a lot EDIT: is there any way to sandbox a cli version or use two versions at the same time (similar to `nvm` in Node) so that I can test the new system before committing to it?

I watched the video. It looks useful but I doubt I would personally use it since I can already do it manually quickly.

I genuinely don’t understand what is so complex or scary about RLS policies that is causing 10 new RLS inspections tools posted here weekly, 90% just being AI slop.

Depends on how many tables and files you have. You can easily push your Supabase local project to any project with “Supabase db push” or “Supabase db reset —linked”. Then push “supabase functions deploy” to push the functions. For the files, I assume you can download and upload unless you have tons of files. I don’t have a good solution for that. For the data, you can export the whole db and import it there. I do the same but I don’t care so much if all the files or data is there as long as I have example data (which I keep in the seeds file). What is your reason for having an exact one to one copy like every file and every row?

Haha yeah I always forget that everyone is a develope now but has no googling skills. Reminds me of the Buzz Lightyear meme in Al’s shop thinking he’s so unique but he’s just like the others 😆

Data APIs just automatically generate a REST API endpoint for your tables. Some tables like internal logs do not need any REST endpoint so you wouldn’t need it. It’s like using Express to create endpoints but Supabase does it by default (I saw in the future, you will need to enable it)

I see the same tool doing the same thing posted here every few weeks. People should google first or ask if anyone is interested BEFORE writing one line of code

I think you are doing it wrong. I am using SMTP to send out transactional emails with no issue with no code repetition. You need to use React to generate your email templates and body. Then make a few utility functions like generateOrderConfirmationBody(order) and sendEmail(user.email, body, headers). Like this there won’t be any boilerplate copy pasted anywhere. One function to generate the body, one function to send out the email, and one function to rule them all!! You need to have validation inside your functions like if there is first_name. Remember that if you allow anonymous users, user.email can be null. In that case you cannot send out an email. Also keep your from emails different. Send out transactional emails from no-reply@site.com and other emails from like marketing@site.com. Never mix them

Depends on your expected traffic. If you are going to have thousands and thousands of users a day placing order, you will need to think about tech debt and stack early on. if you are going to have a few orders to a few hundred orders a day, free Supabase will be more than enough for you. The simplest and cheapest way to start is this: - Buy a cheap domain if you don't have one already - Free Vercel account with DNS pointing to your domain (so you get website.com for free hosted on Vercel) - Free Supababase account with Edge Functions for crucial performances (handling orders, etc) - Free Upstash for rate limiting on all edge functions - Free Cloudflare Turnstiles for battling spam and bot activity on your website - Stripe to handle all your payments I have a similar platform with the same techstack I mentioned above and the only cost is the annual 20€ domain renewal. Everything else is free. I recommend going down a path like this or similar since all those are easily scalable and you never ever have to waste time on maintaining servers or self-hosting anything. If you dont want any of those, Shopify or WordPress might be an easier option for you.

Wow that’s great to know thanks for sharing 👍

Are you using US as your region on Supabase? I wonder if this is an US issue as usual since every time Supabase (AWS) is having issues, it's hitting the US servers only

It doesn't matter. Your config file is for local development. It does not define your remote projects. Your project_id and site_url are local values. They can be whatever you want. You can link your local project to any remote project (as long as you have access to them) without modifying your config file. You are mixing up the local and remote projects

Login from here: https://supabase.com/dashboard/sign-in

One project is staging and another is the production

I use one local config for 2 different projects on 2 different accounts. It doesn’t interfere really. I’ve never had any issues. What is your main concern?

Use “supabase projects list” to see what accounts you have access to and which one you are correctly connected to. Then use “supabase link” to link to the one you want to migrate too. Then run “supabase db reset —linked”. WARNING: this will entirely reset your database data and tables so any info you have will be lost. Then it will run all the migration files if you have any followed by seeds if you have any. In the future, to run new migration files, run “supabase db push” to run any migration that hasn’t run on Supabase. I do this all the time for testing and for switching back and worth between our staging account and production account (the reason is Supabase’s limitation where access can be given to the entire account instead of individual projects so I don’t want the other developers I work with to have access to the production database). Also separating production and staging completely is the safer option. Tip: when you are done, always run “Supabase unlink” to disconnect from any remote account you are connected too so you don’t accidentally run commands on production.

Day 746383 in the software development world where people spend 2 months automating something that takes 10 seconds to do manually

Hi. Honestly, it's very hard to tell without any context like what the app is about, what are the expectations, etc. But here are some basic things you could look for: **The proper development stages:** The developer first develops locally, then pushes to a staging project to do any tests and once everything is good, push to the production. Anything else is a red flag. **Migrations:** Database structures are done through migrations and not the SQL editor on Supabase (that would be a major red flag). migration files are basically a record of changes to the database (add a table, add a column, create RLS policy, remove an index, etc). Without migration files, there will be no record or memory of the changes. **Version control:** Changes are version controlled and pushed to Github properly. Even if he is the sole developer, there are minimum standards to meet (separate development and production branches, incremental Git commits with proper descriptions, etc). If you see 1 commit with 15 files changes, then that's just laziness. **Normalization:** Normalization is one of the basic features and requirements of any SQL database especially Postgres. Simply put: Normalization reduces data duplication by organizing data into separate tables with proper relationships. For example, let's say you have a table of employees who work in different departments. In each record, instead of storing the department's name, you store them in a separate dedicated table called `departments` and then in your `employees` table, your `department_id` would have the `id` of the department the employee belongs to. For example, if HR has the id of 1 on the `departments` table, your `employees.department_id` would say 1 instead of "HR". To get the name of the department, you would do an SQL join. **Using correct data types**: When you add a column to a table, you have to pre-define its type. There are many like: int4, text, jsonb, boolean, timestampz, etc. If everything is stored as text but inside it there is a timestamp or true/false or number, that is a major flaw in the system. **Security**: This one is key and there is zero tolerance for any laziness. "Oh don't worry nothing is going to happen" isn't enough. On every public table, you will see an RLS button. RLS defines who has access to what table: what they can see, what they can update, what they can delete. If this is not done right, not only you are risking leaking users' data, you are risking ending up getting a serious lawsuit. **Clear communication:** This is key. You shouldn't go snooping around like a paranoid person micromanaging everything, however, you have the right to ask for explanations. You could ask something like "hey I was going around the tables and I noticed that the data X is stored like Y. I was wondering why or what would be the benefit of that". If the developer cannot explain it in very simple terms, then they dont really know what they are doing. If this project is a small basic project that is temporary or you are unsure of its future, then if the project isn't structured properly, that's okay. If you have long term goals for this project, you better make sure things are not done in a lazy haphazard manner. **Access:** If the developer refuses to give you access to anything like Github, Supabase, Cloudflare, ... anything that is implemented, you need to be very cautious since they can lock you out or go rogue and demand a ransom. Unfortunately, without much information about the project, I can't give specific info about the work or its quality, but I hope these are enough to get you started. If you need any further help, let me know. You can DM me too.

Can you explain more? What do you mean exactly by "offline" and "online"? Show us what you have exactly because I can't create a picture in my head what's what to help.

If you want to send out an email when something in the database changes (insert, update, etc) then you need to add a database webhook that calls an edge function. This video from Supabase should help you get started: https://youtu.be/dJk2wbdLDpE?is=YcKWH1GlxchRFL9x

Just an extra note that if I add data in a migration file, it would be to have a record of it and usually it comes with specific info like having a specific id in the database to ensure the data is consistent across the local, staging and production projects

Usually yes but it needs a bit more context. Migrations are usually used for structural changes like new tables, columns, dropping things, etc. not for adding data unless the data is core to the functionality of your app. I have a combination of both. I add some data with migration files and also by pasting directly in the SQL editor. The data I add via migration files are core data like all the roles I have in my app, the cities, the payment types, etc. anything extra via sql editor

Thanks. I meant validating the JWT tokens by using something like jose. If I'm not wrong, this was introduced in version 2.71 and a lot of my edge functions stopped working in local. After a lot of research, I found out that I need implement it myself to validate them and it seems very complex. As a result, I had to downgrade to version 2.62.10 and stay until I find a way to do it. Unfortunately, I still haven't found a good example and the docs don't seem to explain how to migrate from the code below to the new system (even though my local and production are using the new publishable keys) ``` const AuthorizationInHeader = req.headers.get('Authorization') if (!AuthorizationInHeader) { return new Response( JSON.stringify({ success: false, error: { message: 'Missing Authorization', }, }), { status: 400, headers: responseHeaders, } ) } // First get the token from the Authorization header const token = AuthorizationInHeader.replace('Bearer ', '') if (!token) { return new Response( JSON.stringify({ success: false, error: { message: 'No token', }, }), { status: 400, headers: responseHeaders, } ) } const supabaseAdmin = createSupabaseAdmin() const { data: { user }, error: errorGetUser, } = await supabaseAdmin.auth.getUser(token) if (!user || errorGetUser) { return new Response( JSON.stringify({ success: false }), { status: 401, headers: responseHeaders, } ) } ```

You need three: local, staging and production. You never ever test anything on production. You develop in local. Test on staging and then push the production and then make sure everything is good. I personally prefer having two different projects in two different accounts: one for staging and one for production. The problem is that on Supabase. You cannot give access to somebody to just one project, you have to give them access to the entire account. Thats why I use two different accounts. Like this, you can give access to staging to other developers but never to production. This is one of the limitations of Supabase account management. I prefer not to use branches.

That’s amazing and I look forward to it. I’m still staying at CLI v2.62.10 just because I found upgrading my edge functions to use the new custom jwt a major pain in the neck and not worth the trouble. It would be great if this just works out of the box

https://preview.redd.it/wb1i0r9xpizg1.jpeg?width=625&format=pjpg&auto=webp&s=acbfce1081ea1a7d6aaaff8c1f077793f8d6e6f7

Why good? You thought banning a database management system is going to have any impact on the oligarchs?!!! Oh no! Now the oligarchs cannot buy their 7th yacht because Supabase was very important to them!!!

URGENTLY change your API publishable key. I created an account in your project now: https://ibb.co/hx1CGX8f

I just created an account on his project: https://ibb.co/hx1CGX8f That's why people should learn not to share information like this even if it's public

I agree

Sorry I don’t think reads update the index. My bad.

Postgres has no issues with 1m or 10m rows as long as things are set up properly. Do not index things if they don’t need to be indexed really since every read and write has to update the index and that can slow down the table if you have 10m rows with a lot of reads and writes per second. You asked if it makes sense. That depends on your db structure. Do you really need 10m rows? Is it a large application? For example I have a coupon code table with 1m rows (unique codes) and it has no issues with almost no latency but if you have 10m rows with a lot of pieces like triggers, db functions, etc then you might need to ask in the Postgres subreddit for more specialized advice. With RLS, just allow the minimum the user needs to achieve something (see, update, etc).

Thanks for sharing. Good to know. I have a few edge functions but not so much traffic to worry about it yet. I'm still on the free plan. Thanks

> you should not be running your migrations scripts manually in the Supabase Dashboard Wait, people do that? 🤣 what’s the point of migrations if someone runs them manually?

Thanks for sharing. Good to know. Luckily, my OCD has prevented me from having this issue since i have to check things 10 times before I feel comfortable enough to publish stuff haha

why do you think it's AI generated?

Perfectly fine. There is no way around it. Make sure your tables have proper RLS set up. If you dont know anything about RLS, check out this video: https://www.youtube.com/watch?v=vZT1Qx2xUCo

I’ve heard that recaptcha isn’t EU/GDPR compliant and should be avoided and since I operate in the EU, I’m not sure I can use it

Thank you. Create clear and straight forward. I noticed that Turstile is web-only since it loads external JS to render and solve the challenge. Do you know any alternative for a mobile app?

I've never used Turnstile. Is it free and easy to implement?

Thanks for sharing. I'm bookmarking this. > Turns out: Supabase Auth allows direct access to /auth/v1/signup using the public anon key. Obviously the JS SDK calls API routes for everything. Every table you create by default has an API route. You can use Bruno (or any other HTTP client) to do all operations without needing the JS SDK. I use it to test things before putting it into code. These are some of the endpoints: ``` Confirm user: /auth/v1/verify { "email": "email-to-confirm-here@test.com", "token": "123456", "type": "email" } Log in: /auth/v1/token?grant_type=password { "email": "email@gmail.com", "password": "password" } Recover/Reset password (sends out the password reset confirmation) /auth/v1/recover { "email": "email@gmail.com" } Get a ticket and all the order data based on ticket ID /rest/v1/tickets?select=*,orders(*)&id=eq.9b623012-41b7-4d7b-ba6b-021aa1292fd8 ``` You can always see what URL any Supabase request is calling using by console logging the request without `await`. For example: ``` const query = supabase.from..select(....) console.log(query) // query.url will have the full URL on Supabase ```

Good info. Also, worth mentioning that unless you have tens of thousands of rows and a LOT of traffic, indexing doesn't do a much better job than having no index at all. There is no point in having an index if you are adding 5 rows in a week and have 500 rows in total!!