search

framesurge / perseus

A state-driven web development framework for Rust with full support for server-side rendering and static generation.
https://framesurge.sh/perseus/en-US
MIT License
2.15k stars 89 forks source link

Allow for customization of path_prefix_server by setting Turbine field. #292

Open giacomocariello opened 1 year ago

giacomocariello commented 1 year ago

Currently only a single Perseus app can be served by a single server backend. While Perseus already allows for customization of app base path, this customization is activated by setting PERSEUS_BASE_PATH environment variable, which means that the same path prefix is applied process-wide, so it's not possible to create a non-standard server implementation "mounting" two Turbines on different URL mountpoints. This means that the only way to have multiple Perseus apps running under the same origin is to use a reverse proxy to forward requests to different Perseus servers. This PR is meant to allow setting a path_prefix_server on a Turbine, while leaving the default behavior of resolving PERSEUS_BASE_PATH environment variable if a custom value is not set.

arctic-hen7 commented 1 year ago

Hey, sorry for the late reply, I've been really busy lately, but I am back now! I think this is a good idea in theory, but I don't love the idea of moving this into the code. From my perspective, the base path is very much a configuration value, and implanting that into an app's code isn't amenable to the philosophy of keeping configuration that can change easily (e.g. an app should be able to be hosted wherever you like once the code is ready). Also, to clarify, your use-case for this is running two turbines in the same server? Is there any particular reason you can't run the two as separate processes?

giacomocariello commented 1 year ago

I get your point, however several other "configurations" are currently available for customization in code. I believe this is for good reason: instead of wiring the developer onto a specific way of managing configuration (environment vars), the developer should be free to decide for, say, a configuration file. That said, my use case is to split the client-side wasm part into sub-apps for different areas of the site, to keep load time low. On the server-side this split would require an unnecessary larger footprint with multiple server processes and some front-end proxying.

arctic-hen7 commented 1 year ago

Okay, I certainly accept that, and your use-case is far less niche than I was expecting! Let me think about this some more and review your code in greater depth.

arctic-hen7 commented 11 months ago

@giacomocariello would you mind resolving the conflicts with main? Then this is good to merge.