Redirect and rewrite rules in Firebase - Time & Space Complexity
We want to understand how the time it takes to apply redirect and rewrite rules changes as we add more rules.
Specifically, how does the number of rules affect the processing time when a user requests a page?
Analyze the time complexity of applying redirect and rewrite rules in Firebase Hosting.
"hosting": {
"rewrites": [
{ "source": "/old-path/**", "destination": "/new-path/index.html" },
{ "source": "/blog/**", "function": "blogHandler" }
],
"redirects": [
{ "source": "/home", "destination": "/index.html", "type": 301 }
]
}
This configuration applies multiple rewrite and redirect rules to incoming requests.
When a request comes in, Firebase Hosting checks each rule in order.
- Primary operation: Matching the request URL against each redirect and rewrite rule.
- How many times: Once per rule, until a match is found or all rules are checked.
As the number of rules increases, the system checks more rules one by one.
| Input Size (n rules) | Approx. Rule Checks per Request |
|---|---|
| 10 | Up to 10 checks |
| 100 | Up to 100 checks |
| 1000 | Up to 1000 checks |
Pattern observation: The number of checks grows directly with the number of rules.
Time Complexity: O(n)
This means the time to process a request grows linearly with the number of redirect and rewrite rules.
[X] Wrong: "Adding more rules won't affect request speed because they run in parallel."
[OK] Correct: The rules are checked one after another until a match is found, so more rules mean more checks and longer processing time.
Understanding how rule checks scale helps you design efficient configurations and shows you can think about performance in real systems.
"What if Firebase Hosting used a tree structure to organize rules instead of checking them one by one? How would the time complexity change?"
Practice
Solution
Step 1: Understand redirect behavior
A redirect sends the user to a new URL and updates the browser address bar to show this new URL.Step 2: Understand rewrite behavior
A rewrite serves different content but keeps the original URL visible in the browser address bar.Final Answer:
Redirect changes the browser URL, rewrite does not change the URL shown. -> Option AQuick Check:
Redirect updates URL, rewrite keeps URL same [OK]
- Confusing redirect with rewrite behavior
- Thinking rewrite changes browser URL
- Assuming redirect does not update URL
/old-page to /new-page?Solution
Step 1: Identify redirect syntax
Redirects require a source, destination, and a type (like 301 for permanent redirect).Step 2: Check options for correct syntax
"redirects": [{"source": "/old-page", "destination": "/new-page", "type": 301}] correctly includes source, destination, and type 301. Others miss type or use rewrites incorrectly.Final Answer:
"redirects": [{"source": "/old-page", "destination": "/new-page", "type": 301}] -> Option DQuick Check:
Redirect needs type code like 301 [OK]
- Omitting the redirect type code
- Using rewrites instead of redirects for URL change
- Placing type in rewrites block
{
"rewrites": [
{"source": "/app/**", "destination": "/index.html"}
]
}What happens when a user visits
/app/profile?Solution
Step 1: Understand rewrite with wildcard
The rewrite rule matches any URL starting with /app/ and serves /index.html content without changing the URL.Step 2: Apply to /app/profile
Visiting /app/profile triggers the rewrite, so content from /index.html is served but URL remains /app/profile.Final Answer:
The browser URL stays /app/profile but serves content from /index.html. -> Option AQuick Check:
Rewrite serves content without URL change [OK]
- Thinking rewrite changes the URL
- Expecting 404 error for unmatched files
- Assuming redirect happens instead of rewrite
{
"redirects": [
{"source": "/home", "destination": "/index.html"}
]
}But the redirect does not work as expected. What is the problem?
Solution
Step 1: Analyze the redirect behavior
A redirect requires a type (301 or 302) to work properly. Missing the type causes the redirect to fail.Step 2: Identify the likely expectation and fix
Adding the redirect type (301 or 302) will fix the redirect. Using rewrites is an alternative if you want to serve content without changing the URL.Final Answer:
Missing the redirect type (301 or 302) in the redirect rule. -> Option CQuick Check:
Redirect requires type code [OK]
- Using redirects instead of rewrites to preserve URL
- Confusing redirects with rewrites
- Using relative paths incorrectly
/app/ show index.html content without changing the URL, but also redirect /old-app permanently to /app/. Which config snippet correctly achieves this?Solution
Step 1: Redirect /old-app to /app/ permanently
Use a redirect with type 301 from /old-app to /app/ to update browser URL.Step 2: Rewrite all /app/** URLs to serve index.html without changing URL
Use a rewrite rule matching /app/** to serve /index.html content while keeping URL unchanged.Step 3: Verify option correctness
{ "redirects": [ {"source": "/old-app", "destination": "/app/", "type": 301} ], "rewrites": [ {"source": "/app/**", "destination": "/index.html"} ] } correctly combines a 301 redirect and a rewrite for SPA support. Others misuse rewrites or redirect types.Final Answer:
{ "redirects": [ {"source": "/old-app", "destination": "/app/", "type": 301} ], "rewrites": [ {"source": "/app/**", "destination": "/index.html"} ] } -> Option BQuick Check:
Redirect updates URL, rewrite serves SPA content [OK]
- Using rewrite instead of redirect for URL change
- Missing redirect type or using wrong type
- Rewriting to wrong destination path
Ready to prove it?
Pass the test and this pattern moves unknown
