search

Hirevo / alexandrie

An alternative crate registry, implemented in Rust.
https://hirevo.github.io/alexandrie/
Apache License 2.0
495 stars 54 forks source link

Consider switching to tokio/axum/hyper stack #159

Closed Noah-Kennedy closed 1 year ago

Noah-Kennedy commented 1 year ago

Alexandrie currently uses an async-std/async-h1/tide stack for it's runtime, HTTP implementation, and HTTP framework. Unfortunately, this pool of crates has been largely unmaintained for several years now.

I'd like to propose instead that Alexandrie migrate to the tokio and hyper ecosystem. This actually shouldn't be much work so long as axum is chosen for the HTTP server framework, as axum is easy to migrate to from tide.

This also has the advantage of opening up a larger and more supported middleware ecosystem for future use (tower), and adding support for HTTP/2. H2 support in particular would be a significant benefit for Alexandrie's performance, especially once the sparse registry support is added.

Noah-Kennedy commented 1 year ago

If time is an issue here, I'd be willing to help with this.

Hirevo commented 1 year ago

Hi !

While I really like Tide's design as a web framework (from a DX perspective), I completely agree that keeping it has quite a few downsides, in terms of features as you mentioned, and also in terms of compile time and dependency count (due to runtime duplication).

Alexandrie has some dependencies that require running Tokio as a runtime anyway (aws-sdk-s3 for S3 storage and reqwest for external auth), so switching away from Tide would allow to drop async-std and only ship Tokio as the single async runtime.

Also, I was also considering using something like Leptos to allow for a more dynamic frontend for Alexandrie (instead of the .hbs templates, which can be impractical), but this was impossible as of now with Tide, and switching to Axum would make that a possible endeavour.

As you mentioned, I don't think migrating would take that much time and would most likely be a quite straightforward process.
Even session management can be migrated without much trouble, with axum_sessions also being based on async-session, just like tide's sessions.

I think I can get around to it rather soon, but if you wish to have a go at it yourself, I'd be happy to review and accept a PR.

Noah-Kennedy commented 1 year ago

I might have a go at it this weekend.

Noah-Kennedy commented 1 year ago

A question: as part of this migration, is it alright if I move the repo to workspace dependencies, to make it easier to track things here?

Hirevo commented 1 year ago

You mean extracting declarations of dependencies that are common to multiple crates into the worspace's Cargo.toml ?

Noah-Kennedy commented 1 year ago

yes

Hirevo commented 1 year ago

Yeah, I'm on board, it would indeed be better organised that way.

jcgruenhage commented 1 year ago

Just to mention that: We've already done this migration while alexandrie was in a hiatus. If you want to take that as a base, we can provide that code to y'all once gitlab is back up.

Hirevo commented 1 year ago

The migration is now complete and has landed, thank you all for having started this initiative.

@jcgruenhage Thank you for your proposition.
I think writing this migration from scratch has helped me learn the Axum framework in more detail than if I were to use an existing base, which is good to be able to maintain it more effectively later, so I think it worked out for the better that way.