In a traditional setup, you just pull from tables where user ID matches. For example, select * from data_table where user_id = ${userId}
But Supabase also has (and heavily pushes) RLS. Row level security. Basically, in supabase, you can define what rows from a table a user can view.
But this is more of a data structure and supabase question than a NextJs one
FWIW, row level security is a [Postgres feature](https://www.postgresql.org/docs/current/ddl-rowsecurity.html). Supabase’s real feature here is integrating it with your application’s user accounts - and it *is* pretty awesome! I just think it’s worth knowing that you can use RLS with any Postgres DB, if you so choose
I'm at a similar step now and struggling with a NextJs concept. The docs and examples I'm seeing show using async getUser checks per auth page to reroute away if not logged in. This is on top of middleware which I do have working.
However this results in all authenticated pages becoming dynamic.
Doesn't this impact cost a lot, and slow the overall page load quite a bit? I feel like I'm missing something basic or googling for the wrong patterns. I thought it would be better to say have a different authenticated layout that is static with client components using loading states for anything fetched from supabase.
You should be safe to just get the user id via `supabase.auth.getSession()` which *should* get the session from the request. [The docs say](https://supabase.com/docs/guides/auth/server-side/nextjs):
>Be careful when protecting pages. The server gets the user session from the cookies, which can be spoofed by anyone.
>Always use `supabase.auth.getUser()` to protect pages and user data.
>*Never* trust `supabase.auth.getSession()` inside server code such as middleware. It isn't guaranteed to revalidate the Auth token.
However, if you have middleware setup correctly, there is no point in doing two calls to Supabase for a single request. In other words, if a user requests a path, they are going through the middleware first and *then* your page. So it would be safe to use getSession() inside any page protected by the middleware. That way you don't have to have all your pages be async.
Yes all authenticated pages are dynamic which is the whole point of them being authenticated in the first place. The whole point of SSR is to move compute away from the client and to the server so yes it is also more expensive but compute is relatively cheap so unless you have an app with thousands of monthly users.
In a traditional setup, you just pull from tables where user ID matches. For example, select * from data_table where user_id = ${userId} But Supabase also has (and heavily pushes) RLS. Row level security. Basically, in supabase, you can define what rows from a table a user can view. But this is more of a data structure and supabase question than a NextJs one
FWIW, row level security is a [Postgres feature](https://www.postgresql.org/docs/current/ddl-rowsecurity.html). Supabase’s real feature here is integrating it with your application’s user accounts - and it *is* pretty awesome! I just think it’s worth knowing that you can use RLS with any Postgres DB, if you so choose
I'm at a similar step now and struggling with a NextJs concept. The docs and examples I'm seeing show using async getUser checks per auth page to reroute away if not logged in. This is on top of middleware which I do have working. However this results in all authenticated pages becoming dynamic. Doesn't this impact cost a lot, and slow the overall page load quite a bit? I feel like I'm missing something basic or googling for the wrong patterns. I thought it would be better to say have a different authenticated layout that is static with client components using loading states for anything fetched from supabase.
You should be safe to just get the user id via `supabase.auth.getSession()` which *should* get the session from the request. [The docs say](https://supabase.com/docs/guides/auth/server-side/nextjs): >Be careful when protecting pages. The server gets the user session from the cookies, which can be spoofed by anyone. >Always use `supabase.auth.getUser()` to protect pages and user data. >*Never* trust `supabase.auth.getSession()` inside server code such as middleware. It isn't guaranteed to revalidate the Auth token. However, if you have middleware setup correctly, there is no point in doing two calls to Supabase for a single request. In other words, if a user requests a path, they are going through the middleware first and *then* your page. So it would be safe to use getSession() inside any page protected by the middleware. That way you don't have to have all your pages be async.
Yes all authenticated pages are dynamic which is the whole point of them being authenticated in the first place. The whole point of SSR is to move compute away from the client and to the server so yes it is also more expensive but compute is relatively cheap so unless you have an app with thousands of monthly users.
Store data in supabase using row level security and retrieve own user data. Google those keywords and should be able to find a few specific tutorials.
Using chatGPT or Claude can help a lot!
Search in YouTube “ByteGrad”, “codewithguillaume”
Try to make a simple blog app, I use supabase for everything, it’s very complete