-
Notifications
You must be signed in to change notification settings - Fork 48
Refactor content page rewrites #34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
ben-fornefeld
merged 8 commits into
main
from
improve-latency-for-landing-page-rewrites-e2b-1892
Apr 5, 2025
Merged
Refactor content page rewrites #34
ben-fornefeld
merged 8 commits into
main
from
improve-latency-for-landing-page-rewrites-e2b-1892
Apr 5, 2025
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…le to rewrite it inside catch-all rewriter
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
ValentaTomas
approved these changes
Apr 5, 2025
Member
ValentaTomas
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me—we went over the details together.
ben-fornefeld
added a commit
that referenced
this pull request
Apr 6, 2025
#34 introduced a catch-all route handler that acts as a fallback rewriter for our content pages. It had implementations of caching mechanisms, but these did not seem to work as expected in production. This pr introduces the use of `generateStaticParams` to cache route invocations for the paths present in our `sitemap` on build time, which results in instant server responses on our rewritten pages.
kitchenbeats
pushed a commit
to kitchenbeats/botlink-dashboard
that referenced
this pull request
Oct 20, 2025
kitchenbeats
pushed a commit
to kitchenbeats/botlink-dashboard
that referenced
this pull request
Oct 20, 2025
e2b-dev#34 introduced a catch-all route handler that acts as a fallback rewriter for our content pages. It had implementations of caching mechanisms, but these did not seem to work as expected in production. This pr introduces the use of `generateStaticParams` to cache route invocations for the paths present in our `sitemap` on build time, which results in instant server responses on our rewritten pages.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After #18 we were using NextResponse.rewrite to rewrite our content pages inside
middleware.ts. The exact reasons are unclear but this had some massive latency overhead on every rewritten route which was not ideal. This pr adds a catch-all route handler which catches all paths that are not defined by the next router. Here we do our content page rewrites & add cache policies to the fetches & responses with revalidation after 15 minutes. Since we use a catch-all handler, we need to manually handle our root 404 page as well. Returning nextjs'snotFound()did only send a 404 status to the browser, but we want to render our custom not-found page. Hence I added a new route just holding our not-found component and rewrite accordingly in the catch-all handler.This results in much faster performance of our content pages & separates the rewriting process from the middlewares business logic for clearer separation of concerns.