FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Allow for customization of path_prefix_server by setting Turbine field. by giacomocariello · Pull Request #292 · framesurge/perseus · GitHub

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

Open
giacomocariello wants to merge 2 commits into
framesurge:mainfrom
giacomocariello:feature_path_prefix
Open

giacomocariello wants to merge 2 commits into
framesurge:mainfrom
giacomocariello:feature_path_prefix

Conversation

Copy link
Copy Markdown

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.

from free function to Turbine public method. This way,
path_prefix_server can be customized in order to build non-standard
combinations of multiple Perseus apps.

Copy link
Copy Markdown
Member

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?

Copy link
Copy Markdown
Author

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.

Copy link
Copy Markdown
Member

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 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Very minor wording change in one comment, otherwise this is good to merge!

I've thought about it a bit more and I think, given this is such an important configuration element, it's probably a good idea to increase the flexibility of things by having it be an option that can be specified in the code. Thanks very much for the suggestion and the PR!

Comment thread packages/perseus/src/turbine/mod.rs Outdated
Co-authored-by: Sam Brew <arctic.hen@pm.me>

arctic-hen7 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Looks great, thank you so much!

Copy link
Copy Markdown
Member

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

This branch has not been deployed

No deployments
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants


Back | FazBrowse Home | New Git URL