Allow running middleware on-request for prerendered pages

[lilnasy]

Summary

For prerendered pages, the middleware runs during build-time, and only during build-time. Some middleware may need to run on-request for all pages.

Background & Motivation

There is no straightforward way to password-protect prerendered pages in a hybrid site. This comes up frequently from starlight users, and users naturally gravitate towards middleware only to find out that it only runs at build time for these routes.

We have implemented the internals for this feature as part of the edge middleware feature used by the netlify and vercel adapters.

• ⚠️ Issue - On demand rendering for protected page docs#6884

Goals

• allow prerendered pages to be protected by auth implemented in a middleware
• maintain current behavior unless this behavior opted-in to; default should remain build-time execution only

Non-goals

• Skipping middleware during prerendering so that it only runs on-request. Provide a way to opt-out middlewares from running at SSG #867

It would likely require creating a distinction between build-time SSR code and runtime SSR code, which is an unsolved problem of its own.

As a workaround, users can check for a runtime environment variable that is different across the two environments, and make the middleware act differently based on it.

Harmony

How might this proposal interact with other in-progress proposals?

• Reroute API #681 - would also need middleware to run for prerendered pages so that the request can be served by a different prerendered or on-demand rendered route.

Example

export default defineConfig({
    ...
    middleware: {
        // naming subject to bikeshedding
        runForPrerenderedPages: true
    }
    ...
})

export default defineConfig({
    adapter: {
        name: "example-adapter",
        hooks: {
            "astro:config:done"({ setAdapter }) {
                setAdapter({
                    name: 'example-adapter',
                    // currently astro's ssr code may not even run before the static html is served
                    // we may need a flag to co-ordinate the new behavior in a backwards-compatible way
                    supportedAstroFeatures: {
                        // alternatively we could co-opt the exisiting "edgeMiddleware" flag
                        runsMiddlewareForPrerenderedPages: 'experimental',
                    }
                })
            }
        }
    }
})

[ematipico]

allow prerendered pages to be protected by auth implemented in a middleware

I read this goal, and it seems this proposal wants to add some authentication in the middleware for prerendered pages.

[lilnasy]

A good authentication story is the goal, allowing middleware to run for prerendered pages is the means.

[ematipico]

The goal is to make the middleware run in prerendered pages, and an use case is authentication (carried by third party integrations)

[lilnasy]

Sure, that's one way of looking at it if that helps.

[eric-burel]

Hi, cross-posting an issue I've opened in the doc, which appears more appropriate here: withastro/docs#6884 (comment)
And a discussion regarding i18n routing, which can be handled using such middlewares: #795

To put it in a nutshell, middlewares in front of static pages allow to implement a "static personalization by redirection", which is an umbrella for a massive amount of patterns:

• i18n (picking the language based on Accept-Language + cookies)
• A/B test (picking a bucket based on a cookie or other props)
• paywalls (reflecting unpaid users)

For some patterns, additional ingredients may be needed:

• using an URL rewrite instead of a redirection, when you don't want the personalization segment to be known to the end user. For instance for i18n showing the language in the URL is ok and even recommended, for A/B test it's the exact contrary users should never know their bucket
• calling a database, if you want to use payment/authentication as the discriminatory factor. This can be tricky infra-wise because if your middleware is an Edge middleware, the middleware and the db can be farther apart than the core app and the db => your perf become worse than basic per-request SSR, not better, despite using static rendering, because the middleware check becomes the bottleneck

The caveats: this work has been receiving mitigated feedback over the years.

• static advocates think any request processing is not static anymore. I think they are wrong, but that's my opinion
• for secure data, if you happen to misconfigure your middleware, your up to trouble. Checking authorization when fetching data is still the safest approach for any website, meaning that dynamic rendering for paid/auth content is probably the safest approach, even if it means losing some perf due to not using static rendering

In addition, I'd like to mention that a much bolder move would be refactoring "getStaticPaths" so it thinks in terms of request and not just dynamic URL params. Static rendering = caching renders for requests. Currently all frameworks use dynamic route params as cache key, which for instance makes Next.js terrible at handling search params (you can't statically render common search params unless you use a hacky setup with a rewrite to a URL param).

This is my "bold static rendering framework" architecture (the JIT thing is mostly to look fancier than it needs ignore that ':)) :

Bibliography:

• Segmented Rendering, a formalization of this idea
• How Plasmic handles A/B test with middlewares
• A static paywall
• Similar discussion for Qwik
• Similar discussion for Perseus ( a Rust Next-like)
• Similar PR at Next.js (yeah that's the fight of a lifetime)
• The maths that lead me to this conclusion, also proposing to use more information than the url parameter to setup statically rendered content

(all this can be done today using Edge Middlewares or any similar host-provided feature, or even a separate proxy server, the point here would be more a deeper integration in Astro)

[delucis]

Amazing, thanks for kicking this off @lilnasy!

One question about the API: would this have to be global flag? Or could it also be something like export const prerender = false for individual middleware? Or maybe that’s not really possible?

[lilnasy]

The exact API and their merits would be a topic of discussion post-stage 2, but yes, it is possible for it be per-route without much more effort.

[janus-reith]

I wonder how much this would align with platform specific middlewares.
The simple usecase that brought me here was a quick BasicAuth protection for prerendered sites on Vercel, which, due to the aforementioned different expectations, took me longer to get right than anticipated.

I could only use the server mode, or have the build create static html pages which would not have the middleware in front of it.
I ended up using the default Vercel middleware instead, which could run in front of static pages aswell.

What I'm wondering now: If the above was implemented, would the (presumably non-platform-specific) middleware function run and simply pick up the static html from the fs? Or since filesystem might not even work on all platforms, in some other serializable format it can import?
Leaving the actual serving from file to the CDN and having some small platform-specific middleware in front of it is probably the more performant and also cost effective choice, not specific for Vercel but e.g. also AWS Cloudfront.

It would still be nice to define such middleware in a generic Astro shape and then delegate that to the adapters which would use the platform-specific middleware and also warn/throw for platform limitations.
Or, maybe, if that turns out to create more confusion, maybe considering to actually create separate Middleware and PlatformMiddleware constructs? These could be chained and tightly integrated for certain use cases, but maybe make it less of a headache to maintain across multiple adapters, and might also help create more expected deployment results.

I noticed that the Vercel Adapter already has some edge middleware integration, but that one actually created more confusion at first when I explored how it might work for my usecase. (It doesn't, simply bypasses static pages aswell by default)

[davidturissini]

Redirecting users away from paywalled content has been discussed extensively here. I want to add another variation of this use case.

Today, when users come to our homepage we do 1 of 2 things depending on the users state:

1. If anonymous, show them the homepage
2. If authenticated, but still going through the onboarding funnel, show the homepage
3. If authenticated and finished onboarding funnel, 302 to web app.

Use case 2 and 3 are somewhat tricky because we have to make an API call to check user authentication. In these cases, creating a dynamic route for the homepage might be an acceptable trade off. As mentioned elsewhere in this thread, the bottleneck in this case likely becomes the middleware itself.

Use case 1, however, accounts for a huge portion of our homepage traffic and in the majority of cases, these users don't even have an authentication cookie set. When this happens, we can skip calling our authentication API entirely. In this case, returning static HTML should be faster than dynamically rendering our homepage. Speed is especially important for these users because they are new users who are interested in our product. We want to show them our homepage as soon as possible.

We do have some options for workarounds, but would love to see "native" Astro support for this.

For more context, we are serving Astro via Docker on AWS. We are not using vercel, cloudflare,, netlify today.

[eric-burel]

Note that without any specific infrastructure, having a middleware will certainly bring convenience but I would not expect a huge performance impact. You will certainly shave off a few ms and that's great, but rendering is not supposed to be very costly (usually).
For instance Vercel is now pushing a similare middleware redirection + static rendering pattern for feature flagging, but only because it is backed by a new Edge Config infrastructure that makes the middleware redirection very fast, faster than a Node.js computation.