SergioBenitez
commented
7 years ago I believe the vast majority of this is possible today by taking advantage of launch fairings for each sub-application. Let me walk through a tiny example of what I have in mind with sub-applications dashboard and home.
-
First, we create a Cargo workspace. Each sub-application has its own crate with both a
libandbin. We also create one more crate with only abinto combine our sub applications. -
We write each sub-application as if it was a regular Rocket application with one caveat: all configuration is done via a function that takes an instance of
Rocketand some arbitraryConfigstructure and returns an instance ofResult<Rocket, Rocket>. That function is then used inmain. Each sub-application would thus look something like:extern crate rocket; use rocket::Rocket; use rocket::fairing::AdHoc; #[get("/hello")] fn index() -> &'static str { "Hello, world!" } // I use `mountpoint` here for illustration, but the idea is you'd pass any sub-app // specific config like this. pub fn app(rocket: Rocket, mountpoint: &str) -> Result<Rocket, Rocket> { Ok(rocket.mount(mountpoint, routes![index])) } fn main() { rocket::ignite() .attach(AdHoc::on_attach(|rocket| app(rocket, "/"))) .launch(); } -
Each sub-application is attached in the main application. As long as all apps use different types for their managed state (Rocket will error otherwise, so no concern of accidental collision is present), everything will work as expected. This would look like:
extern crate dashboard; extern crate home; fn main() { rocket::ignite() .attach(AdHoc::on_attach(|rocket| dashboard::app(rocket, "/dashboard"))) .attach(AdHoc::on_attach(|rocket| home::app(rocket, "/app"))) .launch(); }
I believe this accomplishes most of what you're looking for. The only missing feature from your request is a Redirect that's aware of sub-applications, though I'm not sure I understand what you're really asking for there. In any case, it seems that it would be pretty simple to build outside of Rocket, given how I've laid out the structure here.
In all, I don't think anything needs to change in Rocket to support what you'd like. It seems to me that launch fairings give you 95% of what you're looking for, and the other 5% could be a tiny set of types, functions, and methods that make things slightly nicer to use. All of those things could live outside of Rocket.
SuperHacker-liuan
Feature Requests
1. Why you believe this feature is necessary.
Single Port Multi-App (SPMA) is an important enterprise feature. For a large project in large enterprise, it is often need to split whole project into multiple sub-projects, each subproject will subcontract to another developing team. Each subproject has its own static files, templates, source codes, dependencies and etc, it act as an independent app, and provides some communication interfaces to other apps. The whole project will be a batch of apps work together with inter-app communication. Every app may be accessed from end-user, therefore they should share a same IP/hostname and HTTP port 80. Consider JavaEE supported by tomcat, A large site may be in the following directory structure.
Architecture and data in tomcat is as below.
Every app has its own data, static files, services, libs, pools(like redis) and etc. And they can also share a common used DBPool (like Oracle) in middle ware. Resource from middle ware can be accessed from each app, rosource from app are isolated to its own.
In this architecture, enterprise architectures can easily split whole project into multiple isolated apps, which can reduce a lot of cost and can prevent faliure cascade between apps.
2. A convincing use-case for this feature.
2.1 workspace style
A large project with many apps may be formed as a workspace. The directory structrue of the workspace may be as below.
In this style, architecture can collect apps from subcontract team, put them in
apps/folder, and write some deploy code inserver/src/orserver/Deploy.toml. Finally runcargo build --releaseinserver/dir to launch the project. The launce code maybe in following style.The
app::context()should mount Routes used by app own, and optional provide error catchers, farings and etc. It app::context() looks like aRocket::ignite(), except it won'tlaunch().ContextRoot() need two important information, web base url (app0 means https://xxx.xxx/app0/), and app resource files' path (relative to server dir or absolute path in filesystem). Respath is important in finding statics, templates, configs and etc. Base url is useful in Cookie path and finding root(Redirect) path in app. Apps’ Redirect should have two type, they should explicit distingushed. Like below.
This design is important to avoid path confusion when move app to other sites. This feature should be confirmed before rocket 1.0 release.
3. Why this feature can't or shouldn't exist outside of Rocket.
Rocket provides a whole solution to deploy a http server, and willing to become a middleware (From Fairings guide ). So the SPMA feature, which is heavily use in enterprise projects, should not lacked. Every app should provide a way to run in standalone mode(currently supported) and deploy mode(support by SPMA). Deploy mode is useful in many scence such as virtual host providers (they may not provides many ports to launch, therefore deploy mode is necessary). In my comprehention, Rocket will act as a middleware like tomcat. Features currently implemented (0.3.2) is standard like java servlet. Some commercial Rocket container can be distributed based on Rocket, more and more frameworks can be used, apps can be compiled into a dynlilb, and dynamically deployed into the Rocket containers(dynamic deploy maybe version 2.0 feature)