ashkanahmadi

The word "steal" is an extremely negative word in the corporate/business world. Also, there are many grey area legal issues with how you are framing it. I could not figure out what your website really does. The main issue I have is the lack of explanation of how it does what it promises to do. > Discover your competitors’ customers and turn their product frustrations into your next deal. How do you find my competitor's customers?

Typical developer approach 😆

Because they are two different devices. The bouncer at the door scans the tickets. The user is standing at the door showing their ticket. So it’s two different devices

Thanks. I thought of that but about 200 people lining up at the door with their QR ready causing the app to send refetch requests every couple of seconds seems a bit excessive in this case.

That's definitely a valid point. Thanks. So what you are saying is that it's best to have the products table as a real time table so in case availability or prices change, it is reflected automatically and immediately on the frontend, instead of the booked tickets, right?

Seems to be the case, yes. The US servers seem to go down more often (not just Supababse. It seems to be a pattern across all platforms).

Thanks I downgraded to 2.62.10 (I remembered at that time, my CLI had no issues so I will continue with this version until I have free time to look into refactoring my code)

I did review everything but the documentation does not explain how to refactor an existing function with user validation code. It has a very rudimentary example (getting the name from the JSON body) but nothing substantial.

Thanks a lot. I tried that but I got an error about iss not being valid. Since I have to develop a feature asap, I cannot spend more time on this. I had to rollback the cli to version 2.62.10 (something a few months old) so I knew I wouldn't have any issues until I can work on it in the future. A clear dedicated video on YouTube would be very appreciated like a clear step by step showing how to do the whole thing on SB local since I see a lot of people are having an issue with this here on Reddit and on GH Issues. Thanks

Same. For me, it throws an error too

Thanks. I reviewed that in detail and also the code on GitHub but I'm still confused as how to refactor my existing edge functions to use the new asymmetrical JWT verification. I have this code in the beginning of my edge functions but looks like Supabase treats this as legacy code and I cannot tell what I need to replace it with: https://pastebin.com/v1nRVMf0 Do I just wrap the entire body of `Deno.serve` with `AuthMiddleware`? I find the documentation not that helpful in this regard. If you could help me out, that would be great. Thanks a lot

The issue is fixed. I just had to close everything (Supabase, Docker, ...) and restart my Mac completely and relaunch everything from scratch. Now having the line import "@supabase/functions-js/edge-runtime.d.ts" does not cause any issues.

Thank you. The issue is fixed. I just had to close everything (Supabase, Docker, ...) and restart my Mac completely and relaunch everything from scratch. Now having the line `import "@supabase/functions-js/edge-runtime.d.ts"` does not cause any issues.

Thanks. Yes, it's with Docker version 4.59.1 (217750). I updated my docker and supa cli to the latest version but still I get this error so I just have to remove the line `import '@supabase/functions-js/edge-runtime.d.ts'` for the function to work.

Thanks. This is totally absurd and unacceptable from Supabase. We shouldn't go through so many pages and links on GitHub and the official doc hoping the information is easy to find so we can update our local functions. What version did you downgrade to? If I downgrade, will it affect the linked production project as well? Thanks a lot

Amazing that was very helpful. I managed to find the error (some function in one of the migration files) was causing the issue. It's now fixed and back to working again. Thanks a lot

Thanks a lot. Do you mean the logs that are on Docker, not the ones on the Supabase Logs page, correct?

> But I can put all (tables,triggers,policies) into 1 file per domain. Yes, that's possible. The general idea is to keep it organized in a way that the future you and other developers can easily tell what's what. > we no longer need to manage the migration files That works and it's the new trend but it's the lazy way. The only case where you need the diff file would be to replicate multiple projects in the exact way with no minor differences, or to debug something. 99% of the time, no one needs that.

> I need to do this for each table No. You can have everything in one massive migration file but that would be **very bad practice**. In general, you want one migration file to do one thing, or a few related things. It's okay to create a table and enable RLS and set up RLS policies all in one migration file since they are related. But you don't want to create multiple tables and triggers and functions in one file. Keep it organized. > in the correct order Yes. The migration files run sequentially and the sequence depends on the timestamp. When you run `supabase migrations new update_orders_rls`, you will get something like `20260120000221_update_orders_rls.sql`. There is nothing special about that timestamp. You can manually change it to go before or after any other migration file. Just remember that they ALWAYS run from the oldest to the newest so they need to be in the correct order. If you are referring to a table that you are creating in the next file, you will get an error and the migration will stop. > I also have triggers and functions so i need to run this for them too separately Again, it's about staying organized. You can keep them in one file, or separate ones. Just make sure you can tell what a file does. What's very important is not to use `db diff`. Think of migrations as taking a taxi. You would say "Take me to the airport". You wouldn't say "Take the first right. Then turn left at the stop. Then go on the highway. Then change lane. Then, ........." What the database does behind the scene is not our concern. You need to say "create a table with these columns". You dont need to instruct it with every single step along the way. That what the `db diff` is.

You should never use supabase db diff. It’s not best practice. You need to use migrations using “supabase migrations new DESCRIPTION” like “supabase migrations new add_profiles_table”. Using Supabase db diff is like reading binary code and saying “I don’t know what’s happening here”.

Yeah this is the state of the current web development world. People prefer building another half ass tool instead of googling for 3 minutes to see that already a tool like this exists. Also there are so many open source projects that would benefit from devs contributing to them. But no, let’s add more to the noise. Also, any serious developer would keep all that test data in a seed file and run the seed file to populate the db.

Why not use mockaroo.com?

I don't understand. Let's say now I want to find a developer to work on a project with me. I have to go through all the one-liners and try to see which one stands out? Also no way to contact them through the website? I have to open each dev's GH page to review? It seems like a very clunky way to find developers

Thanks. I didn’t think the ai suggestion had any problem but I was trying to collect more ideas. The thing with AI is that sometimes it sounds very convincing like there is no alternative way of doing things so that’s why I usually try to ask real people for some extra suggestion. Regarding the cascade/restrict, ChatGPT’s reasoning is that we should be able to delete an event but not an artist. In my opinion, both can be CASCADE

Yes that’s safe. But make sure you use a db trigger to automatically add users to tables

You should have asked the Supabase team. They told me not to share any tips or ways to bypass the 7-day limit as it could put strain on their services.

Unless you have 2000 tables, I fail to see how it’s difficult to create a checklist and go through all the tables. Also, you create the RLS when you create the table. Nothing else is done until that table is secure right after it’s created. Honestly, I feel like many developers just lack discipline and organization

Yes all the code I provided is runs on the backend. Originally it was on the client but that seemed absurd to me so moved them to the backend. Thanks

That was very helpful thanks. So as you said, instead of logging in, verifying and then revoking, it's best to check in the database if the user with that email is an admit first or no, if not, reject immediately, if yes, then attempt to log them in. Correct?

Thanks I need to learn Zod since I see it recommended all the time. I will look into it.

RLS is a Postgres feature, it's not a Supabase feature. Supabase however really emphasizes on it as a way to make interacting with their API easier. Usually there is the API between the client and the database. However, since here the client communicates directly with the database, the concept of RLS becomes more important. RLS is nothing but a verbose `if` statement. If you return `true` in any of your conditions, access is permitted. If not, then no. > If I'm only accessing my db server side (with connection string), do I need RLS? If yes what is the pg role used when queries are run anon, authenticated or service_role? Or something else? If you are using connection string, then you are bypassing all RLS checks and in general, you will connect with the role postgres or admin. With connection string, you are above everything else. The lowest role is anon which involves no log in session. > The code I'm working on will always access data from the server. Is it better to use direct access or Data API with service role key ? If you are connecting to the db directly, then I'm wondering why you aren't using something like Neon. But I personally recommend using direct access instead of the service role but I dont have any specific reason for it. Just make sure you are not hardcoding any of the sensitive data. > Policies examples use `auth.uid()`. I'm pretty sure this is coming for Supabase Auth service right? Yes, this is coming from Supabase's auth schema.

Thanks. In my file, I actually have multiple checks like IP rate limiting and also Google reCAPTCHA and form data validation. I didn't include those so the file here isn't too long since the main question for me was checking if the user is admin or not and if not, signing them out immediately.

Thanks. I also have some validation before that like email and password format and length. I didn't include it here so it's not super long but I assume Supabase automatically sanitizes the input

Thanks. Regarding sanitization, I actually have a few checks in my file to validate length and format but I removed that so the file doesnt get too long here since my focus was primarily on the is_admin = true but thanks. I will actually change my code to also be `profile?.[0]?.is_admin === true` as it's clearer what it's checking for exactly

For the confirm email template just use it on Supabase. For the welcome email, I asked about it a few weeks ago and the Supabase team told me that they are working on an auth email confirmation hook so in the future we can hook the welcome email to the auth hook but for now I’m also doing it through invoking an edge function to send out the welcome email to the user after confirming their email

Haha thanks I’m glad that was helpful. My last suggestion would to learn the important commands -“supabase link” to link your local Supabase to a remote one (you need this so you can push changes to production) - “supabase db reset” to reset the local database and run all the migration seed files - “supabase db reset —linked” same as above but do the same to the linked remote Supabase - “supabase migrations up” to run the latest un-run migration files You can pass the flag -h after each command to see help and available optional flags.

Exactly. You got that right. You need to tell the database to create a table with X/Y columns or create a trigger.. What the database needs to do along the way in the background to get that done is not our concern. When you do `supabase diff`, the database tells you every single step it has taken to get it done but this is totally irrelevant to us. The `diff` output is ideal for debugging or ensuring many databases on different machines are exact replicas of each others with no minor differences but that's very edge case and 99.9999% of developers (including myself) would never need to look into it. The other thing is that the source of truth is your migration files, not the database. YOU tell the database what needs to be done. Not the other way around. If you feel comfortable writing SQL statements (insert, create function, RLS policy, ...) then do them in your migration files by hand and then push. If not, do them in the database and then copy the code and put it in your migration files. I have found that a balanced mix of the two works best. If you need any help, let me know.

> I just don't understand the results. That's my point. You dont need to understand that because it's not supposed to be done like that. It's like if someone looks like a Javascript code converted to binary and say "I dont understand all the 10101010101 code"! For example, if you create a table on the dashboard, click on Definition and copy-paste your code to the migration file. Delete the table and then run the migration file. I understand it seems like more work, but that's the standard and best way of doing it. What the database actually looks like in the background shouldn't be our concern

Easy. Never ever use the diff feature. Just add your code to the migration files and then run them. This is really bad practice that I constantly see happening in this subreddit.

The most convenient way is to use Upstash Ratelimit. They have a very generous free tier. It’s good enough and super fast for starting projects

Good job thanks a lot. I’m not sure if noticed any issues with the types but I’m glad someone is improving it.

Yes the anon key is called the publishable key now. It’s a much better name than anon. Most websites call the public client key the publishable key. The secret key is still the service key

Supabase is like a restaurant. They just put different elements together so that’s it’s very convenient. Yes, you could buy all the ingredients one by one but it would take a lot of time and energy so instead you use Supabase. The interface is easy and intuitive (there are some things to improve) and the documentation is pretty good. The local development process and cli is pretty decent too

Definitely. I always recommend doing what people feel comfortable with. However, make sure it does not get out of control. For me, I'd rather do it in a messy way but stay organized in the long run

Thanks. What I have is an app. I think we should be fine with the free version in the beginning until we see that we need to upgrade. I’m using the official Supa JS SDK. Not using Prisma. Do you have any specific reason for using Prisma? Curious to know

That works but too messy for me in my opinion. Moving forward, create your table on Dashboard. Then copy its Definition and all your RLS to a new migration file. Delete the table you created on Dashboard. Then run the migration file to create it using the file. Remember this: your database reflects your migration files, not the other way around.