Build-time state can be user or "segment" specific, and it's actually easy to setup about perseus HOT 3 OPEN

This is a really nice pattern, and one I've considered in the past as well, but the problem is that static content is hosted by frameworks in opaque, but accessible, URLs. To do this, you would have to add authentication middleware to block access to certain parts of the .perseus/static/ section of your site. While possible, this is hardly ergonomic as-is, but I'd be very willing to look at a library that would extend the Perseus servers to support this more ergonomically!

Do you have another way around this? I don't see that issue mentioned in your article (which was great by the way!).

from perseus.

Glad you liked it!
In the article I hide the logic in the isPaidUser function, however you are right that it's the hard part, for instance in Next.js the Edge middleware runtime is so limited that you can't establish a TCP connection to a db, so most often you can't check current user state reliably, unless you also use an HTTP-ready serverless database.
However, it's conceptually not much different from redirecting to for an A/B test, or towards the right language, the difference between those use cases only lies on how complicated is the logic that selects your "segment" and how many segments it creates. Either way you indeed need a dispatching middleware.
In an earlier version, this lead me to call this pattern the "unicorn architecture" or "rainbow rendering", as the magic is provided by adding a tiny proxy server, like the horn of the unicorn, and then you can render your site statically in as many colors as you want :)

from perseus.

Understood, right now Perseus doesn't have good support for middleware beyond customising the server used to host the app, but v0.5.x will include this, and I'd be happy to look at something then to make this approach more ergonomic at a framework-level, maybe even with first-class support --- this would certainly be possible by checking a JWT in a cookie or similar, although that limits the auth patterns this could be used with. This will probably be a plugin or otherwise separate crate, but we'll see how the final middleware API ends up looking! I'll leave this open for now.

from perseus.