RE: https://hachyderm.io/@conjured_ink/115572573996228576

Hey so you wanna work on a cool Rust project? Like an actual webapp that's seriously taking advantage of Rust's abilities not to scale up, but to scale DOWN?

#Rust #RustLang #Axum #IndieWeb

RE: https://hachyderm.io/@conjured_ink/115572573996228576

Hey so you wanna work on a cool Rust project? Like an actual webapp that's seriously taking advantage of Rust's abilities not to scale up, but to scale DOWN?

#Rust #RustLang #Axum #IndieWeb

First rough prerelease of @conjured_ink 's eshop software is up on codeberg: https://codeberg.org/conjured/silverfish/releases/tag/v0.0.1

It's so tiny. That's the whole binary. There's no external dependencies. There's only a single binary in it, and it has both the database and the job queue software embedded right in it.

For folks familiar with hosting mastodon: Imagine if that was literally your hosting experience, and the entire thing barely used 80mb to serve thousands of requests per second on a single-core vm. No need to set up and manage mysql, or sidekiq. You just run the executable.

Silverfish (what we're calling this tiny thing) is still in very early stages and only really has a CMS with custom theming support so far, but new features are rapidly being added, and the guts of the thing are really featureful, with light/dark theme support, i18n, and a literal 1kb JS bundle where the entire admin interface works with JS completely disabled and is still super snappy.

I'm very excited

#ConjuredInk #IndieWeb #SmallWeb #ECommerce #Rust #RustLang #Axum

First rough prerelease of @conjured_ink 's eshop software is up on codeberg: https://codeberg.org/conjured/silverfish/releases/tag/v0.0.1

It's so tiny. That's the whole binary. There's no external dependencies. There's only a single binary in it, and it has both the database and the job queue software embedded right in it.

For folks familiar with hosting mastodon: Imagine if that was literally your hosting experience, and the entire thing barely used 80mb to serve thousands of requests per second on a single-core vm. No need to set up and manage mysql, or sidekiq. You just run the executable.

Silverfish (what we're calling this tiny thing) is still in very early stages and only really has a CMS with custom theming support so far, but new features are rapidly being added, and the guts of the thing are really featureful, with light/dark theme support, i18n, and a literal 1kb JS bundle where the entire admin interface works with JS completely disabled and is still super snappy.

I'm very excited

#ConjuredInk #IndieWeb #SmallWeb #ECommerce #Rust #RustLang #Axum

So over at @conjured_ink, we've been seeing some annoying compilation times issue on the webapp we're working on (Axum based), and we're looking at trying to split it into crates and see if that helps with the issue.

The problem is, we're not really sure how to split it: should it be by feature? By function? Should each view+model+controller combo have its own crate? Or should all views go in a single crate, then all models, then all controllers? Or maybe every one of those should get an individual crate to themselves (since we actually have TWO webapps and they're gonna reuse code from one another)?

Do y'all have experience doing this kind of split? Are there any examples or wisdom you can share?

#Rust #RustLang #Axum

Dear #Rust#RustLang folks doing #Axum

What's your preferred way of having a single handler for multiple form submission types?

That is, let's say I have a settings page, and there's different "sections" to the settings, which all get handled differently, but I want the Form to get deserialized per usual?

Unfortunately, serde_html_form doesn't support deserializing enums for something like this? At least not out of the box?

Dear #Rust#RustLang folks doing #Axum

What's your preferred way of having a single handler for multiple form submission types?

That is, let's say I have a settings page, and there's different "sections" to the settings, which all get handled differently, but I want the Form to get deserialized per usual?

Unfortunately, serde_html_form doesn't support deserializing enums for something like this? At least not out of the box?

Excellent. Got this working in the #ConjuredInk#Rust#RustLang #Axum server.

If you just wrap any plain

Without JS, you get the some whole page back, just like normal. With working JS, you only get the "patch", and then overwrites the matching nodes.

This is a hybrid of htmx and htmz that uses a web component instead of a global thing with odd attribute annotations, and unlike htmz, lets you have programmatic lifecycle hooks, set that header so you can share the exact same endpoint, etc.

And it’s still just a tiny, plain, standalone Web Component with no deps. It's a couple of kb mingz, and I'll probably golf it around a bit to make it smaller.

#WebDev

Haven't used it for anything huge yet, but it should handle your bullet points and I'm happy enough with it in Tyck. (https://codeberg.org/natkr/tyck)

Dear #rust#RustLang folks who use #axum

Do you have a nice router crate you recommend? My use case here is that I have a lot of situations where I want to actually resolve routes (to generate links and the like) and I really dislike how untyped/unverified those random strings are.

https://crates.io/crates/axum-routes seems good, but it's somewhat low usage. Still, it's pretty small and seems to do exactly what I need (lets me keep separating route definition from handler definition, lets me do reverse lookups, does static route typing, etc)

I did a RIIR again and:

Two apps nearly-identical in functionality now. On startup, before processing anything:

#Rust + #Axum: 3.5MB RES
#Elixir + #Phoenix: 75MB RES

Literally 20x difference, and I haven't even benchmarked throughput/perf. For a use case where a big goal is extremely low resource use, this is huge.

(both of these are running in release/prod mode btw)

I did a RIIR again and:

Two apps nearly-identical in functionality now. On startup, before processing anything:

#Rust + #Axum: 3.5MB RES
#Elixir + #Phoenix: 75MB RES

Literally 20x difference, and I haven't even benchmarked throughput/perf. For a use case where a big goal is extremely low resource use, this is huge.

(both of these are running in release/prod mode btw)

Hey rustaceans, I need to plug my #axum server which uses the tracing crate for logs to our elasticsearch logging service, which uses ESC I believe?
It seems there's no off the shelf tracing_layer to talk to elasticsearch , and trying to write my own I'm running in the issue of needing to use an async method to send the message from a sync context (on_event() of tracing::Layer). Anything I've missed to make my live easier? #rustlang #tokio #elasticsearch