Protected routes in frontend in Supabase - Time & Space Complexity
When using protected routes in a frontend app with Supabase, we want to know how the time to check user access grows as the app handles more pages or users.
We ask: How does the number of checks or API calls change as the app scales?
Analyze the time complexity of this simple protected route check.
// Check user session before showing page
const { data: { session } } = await supabase.auth.getSession();
if (!session) {
redirectToLogin();
} else {
showProtectedPage();
}
This code checks if a user is logged in before allowing access to a page.
Look at what happens repeatedly when users navigate protected pages.
- Primary operation: Calling
supabase.auth.getSession()to check user login status. - How many times: Once per page load or route change that requires protection.
As the number of protected pages a user visits grows, the number of session checks grows the same way.
| Input Size (n) | Approx. Api Calls/Operations |
|---|---|
| 10 pages visited | 10 session checks |
| 100 pages visited | 100 session checks |
| 1000 pages visited | 1000 session checks |
Pattern observation: The number of checks grows directly with the number of protected pages visited.
Time Complexity: O(n)
This means the time spent checking user access grows in a straight line with the number of protected pages visited.
[X] Wrong: "Checking the user session once means no more checks are needed for other pages."
[OK] Correct: Each protected page load usually triggers a new session check to ensure the user is still logged in and authorized.
Understanding how protected route checks scale helps you design smooth user experiences and efficient apps. This skill shows you can think about app behavior as it grows.
What if we cached the user session after the first check? How would the time complexity change?