Skip to content

feat(middleware): implement onboarding step cache #2682

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

Open
wants to merge 3 commits into
base: dev
Choose a base branch
from

Conversation

ajnart
Copy link
Contributor

@ajnart ajnart commented Mar 23, 2025

This solution is very simplistic and does not rely on redis on purpose.
This is so that it saves another "round-trip" at every single request

This choice is because the middleware should be the fastest possible im my opinion

Decision taken

  • Keep using let to define a variable that lives in the middleware (kept alive by nextjs since we are not deploying our API to functions)
  • Switch to using redis to cache this value (increases round trip time but it should still be faster than trpc)

Tests

Reduced the time between each page switch by about 45ms on my machine

This solution is very simplistic and does not rely on reddis on purpose.
This is so that it saves another "round-trip" at every single request
This choice is because the middleware should be the fastest possible
@ajnart ajnart requested a review from a team as a code owner March 23, 2025 17:08
@ajnart ajnart changed the title feat(middleware): implement onboarding cache feat(middleware): implement onboarding step cache Mar 23, 2025
@ajnart ajnart added enhancement New feature or request decision A decision needs to be taken labels Mar 23, 2025
Copy link

deepsource-io bot commented Mar 23, 2025

Here's the code health analysis summary for commits 46c95e0..a53fa5d. View details on DeepSource ↗.

Analysis Summary

AnalyzerStatusSummaryLink
DeepSource JavaScript LogoJavaScript✅ SuccessView Check ↗

💡 If you’re a repository administrator, you can configure the quality gates from the settings.

Copy link

github-actions bot commented Mar 23, 2025

Coverage Report

Status Category Percentage Covered / Total
🔵 Lines 22.73% 10253 / 45093
🔵 Statements 22.73% 10253 / 45093
🔵 Functions 29.83% 426 / 1428
🔵 Branches 64.68% 1231 / 1903
File Coverage
File Stmts Branches Functions Lines Uncovered Lines
Changed Files
apps/nextjs/src/middleware.ts 0% 0% 0% 0% 1-72
Generated in workflow #5645 for commit a53fa5d by the Vitest Coverage Report Action

manuel-rw
manuel-rw previously approved these changes Mar 23, 2025
Copy link
Member

@manuel-rw manuel-rw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, please wait for @Meierschlumpf since he has more experience with Next.js.

Switch to using redis to cache this value (increases round trip time but it should still be faster than trpc

I think the roundtrip time should be pretty similar, no?

@ajnart
Copy link
Contributor Author

ajnart commented Mar 23, 2025

Switch to using redis to cache this value (increases round trip time but it should still be faster than trpc

I think the roundtrip time should be pretty similar, no?

I believe that redis cache interactions are near instantaneous since the connection is kept alive whereas trpc queries the DB again

@ajnart
Copy link
Contributor Author

ajnart commented Mar 25, 2025

@manuel-rw b7ba3c6 is an optional commit that tries to also cache the "Culture" attribute for a user. When making these changes in dev mode I saw a very significant change in the speed taken to switch pages. From ~450ms to < 50ms with the cached values. I believe this will also enhance prod significantly

@manuel-rw
Copy link
Member

lgtm, please wait for Meier

@Meierschlumpf
Copy link
Member

Meierschlumpf commented Mar 26, 2025

I would suggest that we use the new experimental feature for node-middleware. Because then we can directly query the db and don't need to use fetch for it.

For this you'll need 15.2+ which is available once #2701 is merged

https://nextjs.org/docs/app/building-your-application/routing/middleware#runtime

@Meierschlumpf
Copy link
Member

Then we'll probably also don't need a cache

@ajnart
Copy link
Contributor Author

ajnart commented Mar 26, 2025

I would suggest that we use the new experimental feature for node-middleware. Because then we can directly query the db and don't need to use fetch for it.

For this you'll need 15.2+ which is available once #2701 is merged

nextjs.org/docs/app/building-your-application/routing/middleware#runtime

I don't understand how that will fix this.. Currently our middleware is running on node, since we deploy as a standalone package we are never using an edge server. Querying the DB will still have a similar latency ± 100ms. We could however use an existing redis singleton connection to reach into redis directly
The main point is that this value doesn't need to be stored but instead cached

@Meierschlumpf
Copy link
Member

No middleware did not support node packages, so it will have quite an increase. Of course we can discuss if we want to cache it further once we tried the node middleware

@Meierschlumpf
Copy link
Member

Node middleware is currently only available in canary

@Meierschlumpf
Copy link
Member

Storing it with the csrf token will result in the stale cache still existing as long as you don't login / logout again. So not really a good way to cache it. I would consider waiting for nodeMiddleware and using unstable_cache to cache it with a tag which we can use to invalidate the cache. Because otherwise it will just return the wrong data. We could however add a custom env variable or something to cache it forever locally so we have better performance

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
decision A decision needs to be taken enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants