Update integration with support for axum 0.7

[dgsantana]

This updates the axum integration to use axum 7. This is a breaking change, since axum api as some changes. One of the major changes is Body, which now handles all types of bodies, and how the server is started, since now it takes a listener, making it more composable.

[dgsantana]

Missing axum sessions example, which is pending a PR I'm preparing for axum_sessions and axum_sessions_auth.

[dgsantana]

Missing axum-js-fetch update, that requires gloo-net update to http 1.0.

[rakshith-ravi]

@gbj is this something that we can backport to 0.5? Or will this strictly be for 0.6?

[gbj]

@gbj is this something that we can backport to 0.5? Or will this strictly be for 0.6?

Given the breaking changes no, it can't be backported to 0.5 because that would break cargo's understanding of semver. If there's enough demand the best idea may be to unsynchronize the versioning between leptos_axum and the other crates, i.e., to release leptos_axum 0.6 that supports the combination of leptos 0.5 and axum 0.7, and then leptos_axum 0.7 when leptos 0.6 is ready.

Updating the whole Leptos world a minor version for this wouldn't make sense from my perspective because it requires all other packages that use Leptos to also release new versions (so leptos-use, Leptonic, etc.) The ecosystem is getting large enough that this level of churn takes a couple weeks and leaves some packages behind, so I don't think bumping leptos (and leptos_dom, leptos_reactive etc.) another version makes sense.

The notes from @dgsantana are also important here: for example the chain of gloo-net needing http 1.0 so that axum-js-fetch can support axum 0.7 etc. etc. etc.

[dgsantana]

I agree with @gbj, backporting this into 0.5.x, would create havoc. I will keep updating the PR as the main branch gets new stuff. In the long term this should be merged into the 0.6.x branch when it appears.

@rakshith-ravi you can still use this PR directly if you set the cargo toml to point to this PR or my branch, but keep in mind that you need to point all leptos_* to it. You can do that with a [patch.crates-io], so it's easy to remove later on, without changing the main dependencies.
Something like this:

[patch.crates-io]
leptos = { git = "https://github.com/dgsantana/leptos" , branch="axum_7" }
leptos_axum = { git = "https://github.com/dgsantana/leptos", branch="axum_7" }
leptos_config = { git = "https://github.com/dgsantana/leptos", branch="axum_7" }
leptos_dom = { git = "https://github.com/dgsantana/leptos", branch="axum_7" }
leptos_macro = { git = "https://github.com/dgsantana/leptos", branch="axum_7" }
leptos_reactive = { git = "https://github.com/dgsantana/leptos", branch="axum_7" }
leptos_router = { git = "https://github.com/dgsantana/leptos", branch="axum_7" }
leptos_server = { git = "https://github.com/dgsantana/leptos", branch="axum_7" }
leptos_meta = { git = "https://github.com/dgsantana/leptos", branch="axum_7" }
server_fn = { git = "https://github.com/dgsantana/leptos", branch="axum_7" }

PS: @gbj may tag PR this as for 0.6 or something?

[rakshith-ravi]

If there's enough demand the best idea may be to unsynchronize the versioning between leptos_axum and the other crates, i.e., to release leptos_axum 0.6 that supports the combination of leptos 0.5 and axum 0.7, and then leptos_axum 0.7 when leptos 0.6 is ready.

Okay yeah that doesn't make sense. Axum currently does this (with axum-extra and stuff) and it creates a lot of confusion in the community in terms of what version is what. I think we'll keep this for 0.6 and make sure that all official leptos crates are on the same X.Y version, while each one of them can independently have their own patch version, so that they're not tied down

[sebadob]

What we could do instead of backporting is to hide this behind a feature flag maybe, like actix-web did it for rustls 0.21.
With leptos 0.6 it could become the default then.

I have not looked at the changes though and I guess this would mean a lot of overhead and #[cfg(...)] now, right?

[dgsantana]

What we could do instead of backporting is to hide this behind a feature flag maybe, like actix-web did it for rustls 0.21. With leptos 0.6 it could become the default then.

I have not looked at the changes though and I guess this would mean a lot of overhead and #[cfg(...)] now, right?

Yeah, it would require a lot of duplicate code just to handle axum 0.6 and 0.7, even with cfg gating. We could write some wrappers to ease, but its just creating more overhead to maintaining. I think is just easier to use cargo crate.io patch to point to either this PR. I will keep updating this as new commits are add to main.

[mi4uu]

cant wait for this one, good luck guys!

[gbj]

In #2114, @Heliozoa suggests a possible way to release this without breaking semver: Using a prerelease version by releasing something like leptos_axum 0.6.0-alpha that supports Axum 0.7 on Leptos 0.5, and then later releasing leptos_axum 0.6.0-beta and so on that support Axum 0.7 and Leptos 0.6.

This seems like a good idea to me, but I'm curious to hear from others if there's a reason you can think of not to go ahead and do that.

[dgsantana]

Too me sounds a good way to allow a early release. The gloo (net) still isn't updated, there some conversation on either dropping http or not, I have a pull request there.

My question is how do you solve the example that use fetch?

[rakshith-ravi]

I mean, honestly, how big of a problem is it to just stay on axum 0.6 for a while? I mean, it's not like there's a security vulnerability in the older version or anything. I honestly believe it's okay to wait till we wrap up leptos 0.6 and then release that with axum 0.7.

Hot take, but I feel like it's the itch that people have - to upgrade to the latest version - that pushes us to go out of the way to support it rather than an actual necessity. I think we should be fine if we wait till we release 0.6 to support axum 0.7. After all, shouldn't our users be able to continue to use leptos with an older version of axum and upgrade once we're good to go with 0.6?

Unless I'm blind and am not seeing something that's right in front of me (very possible). Do enlighten me if I'm missing something

[dgsantana]

I think it's mostly because it's a stable release of http and hyper, which are used by axum. Also http and hyper are now split into more crates, to separate the experimental features s they do not polute the stable crates. And since axum uses the stable versions, it's more about stability then using the greatest latest, but this is my take on this. I'm ok with waiting for leptos 0.6, gloo-net should hopefully have a PR merge soon with the update to use http 1.0.

[rakshith-ravi]

I completely agree with you. But leptos in itself is anyway not stable (by that I mean we're not 1.0 yet), so unless we're pushing towards leptos 1.0, would we lose out on anything by just waiting for a small duration until leptos 0.6 comes out?

In my humble opinion, not upgrading shouldn't be a deal breaker. After all, we as devs should be focusing on features in our applications, and if axum 0.6 is able to satisfy that, the rest I feel is just people wanting to scratch the itch of upgrading to the latest and greatest version haha.

[sabify]

Pre-releases are very useful. You don't have to wait for stable releases to play with new features and test them out!

This will also eventually build a test-driven community that can test features before any stable releases and help with a more stable rollout in stable releases.

This is going to be a standard way to deal with new features, migrations, and access to real-world test suites sooner without hacking around in forks and branches! Leptos can drive more people to test new fixes, features and breaking changes by adopting separate and compatible pre-releases/releases for each workspace crates.

[rakshith-ravi]

@sabify indeed. That's how we did the 0.5 release. We had a bunch of alphas, betas and RCs before we launched it. I'm sure we'll go through a similar process for 0.6 as well. Additionally, you can always add the main branch as a git dependency and use that to test unreleased features as well.

Unless you mean keeping the main branch always published as an alpha version?

[sabify]

I believe this has already been discussed by @gbj and @Heliozoa, having separate and compatible pre-release/release candidates for each workspace crate that will eventually introduce new features, bug fixes and API changes independently without relying on unified workspace versioning.

[rakshith-ravi]

Axum does this. They have a axum, axum-extra and a bunch of other things each with it's own version. Causes a lot of confusion for users imo.

Independent patch versions, I'm completely onboard on! As long as someone refers to 0.5 and all versions of the crate are at that version, albeit with different patch versions, that wouldn't cause any confusion. Each independent crate can have it's own patch version.

Been meaning to put up an RFC for something along the lines of:

version.workspace = true
version.patch = 5

So that major and minor can be shared across all workspace crates but patch versions can be independent to each repo. Never got around to putting up the RFC lol. One day...

[sabify]

As a Rust developer, you are already dealing with many other dependencies and their versioning in every single project. A library may not take on that responsibility. The Rust toolchain and some other Cargo extensions are pretty handy in resolving conflicts and confusions.

Decoupling/less coupling of workspace crates avoids blocking changes and introduces better maintainability, and independent changes in those crates may not lead to unnecessarily publishing releases of others. Not just Axum, but many other libraries also follow this principle.

[Heliozoa]

Generally speaking, only the latest versions of crates are supported by the developers, so I think it's nice to keep up with them. In this case, not only axum is held back but related crates like tower-cookies and tower-http.

I happened to hit this issue when updating dependencies after not doing so for 4 months and I was surprised to see an issue had been up for a few weeks already, since typically dependency updates like this propagate through the ecosystem quite quickly. At least in my case, that's the motivation for trying to resolve this issue instead of just waiting. It's of course not a dealbreaker to wait, I don't think anyone has said that, and even if it was they can always use a fork.

FWIW I also think decoupling the version numbers would be the best way forward. The ability to develop the supporting crates independently without making superfluous breaking releases to other crates or holding releases back until all the other crates are ready is more than worth the tradeoff in my opinion. Especially since I would argue that any confusion regarding compatibility could be entirely mitigated with version metadata and documentation.

There are also third party crates like the aforementioned leptos_use that already don't follow the same versioning (as it would be impractical to do so), and hopefully in the future there will be more and more such crates in the ecosystem.

[gbj]

Ok crew so I just released this as leptos_axum 0.6.0-alpha, which is compatible with the 0.5-series of Leptos.

leptos = { version = "0.5", features = ["nightly"] }
leptos_axum = { version = "0.6.0-alpha", optional = true }
leptos_meta = { version = "0.5", features = ["nightly"] }
leptos_router = { version = "0.5", features = ["nightly"] }

just works with the Axum 0.7 stack.

Given that the axum_js_fetch story still needs to be finalized, I'm going to leave it as a prerelease for now.

I think agree with the argument above that we should not wait for Leptos 0.6 to be ready to make a formal release of this. I will plan to keep the version numbers of the core Leptos packages in sync with one another for consistency/simplicity, and I can do that because I basically control semver on them all. The server integrations are subject to other people's APIs, so I agree it makes sense to let them bump ahead over time.

tl:dr; leptos_axum 0.6.0-alpha available now, will wait for the axum_js_fetch to support http 1.0/Axum 0.7 and then decide whether to do a 0.6 release or keep this in prerelease.

Thanks for all the feedback.

[benwis]

Thanks @dgsantana for the lovely PR updating to Axum v0.7! Merging this into a new branch to work on releasing leptos 0.6 with new and improved server functions and this support