-
-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: embed webui assets into the binary #385
Conversation
I really like this! And awesome work on awatcher btw! A few things:
What do you think @johan-bjareholt? :) |
The build would fail because the macros requires the specified path to exist compile-time, even an empty directory. Is this a normal scenario during a compilation though? If so, there could be
Is your suggestion only for testing aw-webui with the server? Maybe the separate feature or something like that would target your use case more precisely while reducing UX complexuty, because it would remove otherwise useless |
I have implemented this for these reasons:
Please, correct if I'm wrong in my assumptions. |
Going to try and merge this today. Not sure why CI isn't running, as with #396. Excuse me for opening a new one to get CI to run. |
Now checks are running, some kinks to iron out: #420 |
Thanks, I'll fix this soon 👌 |
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## master #385 +/- ##
==========================================
+ Coverage 72.16% 73.37% +1.20%
==========================================
Files 45 45
Lines 2831 2794 -37
==========================================
+ Hits 2043 2050 +7
+ Misses 788 744 -44
☔ View full report in Codecov by Sentry. |
CI is fixed with The important consequence of this would be not forgetting to have aw-webui compiled before building the complete rust server. As I understand, it should be already ok now in the build script https://github.com/ActivityWatch/activitywatch/blob/master/.github/workflows/build.yml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The executable grows only a bit in disk space, but not RAM.
This doesn't sound right. How did you measure this? Did you only start the application or did you let it run for a while, using the web-ui etc?
If you only start the application and don't use the web-ui, it will likely only use the same amount of memory that it used before because that's all memory will be required to map. However, if you use all assets bundled in the executable, it will be required to map that memory as well. Exactly when the OS will unmap that memory is hard to tell, but most likely it will hold on to that mapped memory for quite some time, likely until the OS runs low on memory.
Regardless, it's probably not a huge issue since the web-ui is only a few MB right now, but if that ever grows we will need to keep that in mind. The pros probably outweigh the cons. Could also be optimized in the future by bundling compressed versions of the files, which then get uncompressed on demand.
aw-server/src/endpoints/mod.rs
Outdated
} | ||
|
||
#[macro_export] | ||
macro_rules! embed_asset_resolver { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is it necessary to have a macro for this?
Can't you instead have a single struct that includes the whole "dist" folder?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If __ProjectAssetResolver
is not behind the macros, then rust-embed's own derive macros always runs compile-time, which requires always having ../aw-webui/dist
relative to this rs file regardless the dynamic dispatch by trait.
Regarding the overall abstraction instead of always embedding ../aw-webui/dist
. I don't know about the strategy of this server development, hence I've made the more conservative, least prohibitive choice to allow more freedom and easier use of the server as a crate library, like in the some past instances
- https://github.com/ActivityWatch/aw-tauri/blob/master/src-tauri/Cargo.toml#L19 (where I found out about the crate's lib)
- https://github.com/2e3s/awatcher/blob/main/Cargo.toml#L39 (implemented a lighter approach than Tauri)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another way I thought about is interpolate-folder-path
feature on, which allows #[folder = "$CARGO_MANIFEST_DIR/aw-webui/dist"]
and hence this directory structure can be replicated elsewhere. I had disregarded it because it's not a maximized flexibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another way I thought about is interpolate-folder-path feature on, which allows #[folder = "$CARGO_MANIFEST_DIR/aw-webui/dist"] and hence this directory structure can be replicated elsewhere. I had disregarded it because it's not a maximized flexibility.
That's a pretty cool idea.
A variant on that would be to have a "AW_WEBUI_DIR" variable and if the variable is unset you can set it to "../aw-webui/dist" in build.rs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My initial suggestion with interpolate-folder-path
turned out looking pretty awkward when implemented, but your improvement has made it acceptable. 👍
You're right, I only meant that it doesn't load the data on the application start. There is a compression option for the crate, but it doesn't affect RAM consumption, only the size on disk. |
I think it's fine as is for now, no need to dig deeper into this right now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, let me know when you feel it is ready to merge @2e3s! :)
I have re-reviewed the code and found a minor bug/typo. Otherwise it's good to go. |
Just in case, it's fixed and ready I think 🙂 |
Awesome, merging! 🚀 |
Massive thanks for getting this together @2e3s! 🏅 This is a great QoL improvement, and now that I think about it will massively simplify some parts of aw-android (when we get it building again...) where we before had to unzip the webui and make a mess. Huge win right there, that you didn't even know about! If you want to get paid, just send me the results from the script. And thank you @johan-bjareholt for the thorough review! |
Hi!
When I was playing with the server, I noticed the inconvenience to distribute. I was able to overcome some problems with things like
cargo-deb
and manifests, but it's limited to deb. There is also a Tauri subproject but it is very bulky.The proposed change takes the content of the root's
aw-webui/dist
and embeds into the aw-server-rust binary. This can make the distribution much easier, and less prone to problems with filesystem locations, and maybe even more secure as the served files cannot be changed anymore. The executable grows only a bit in disk space, but not RAM.The trait and macros allow to continue using
lib.rs
easily and flexibly. It uses this crate: https://github.com/pyrossh/rust-embedWhat do you think about this idea?