End-goal featureset, roadmap and goals

[dpc]

Hi!

In my free time I wanted to play with htmx in Rust, which turned out into usual spare-time yak-shaving, trying to glue together some personal "web stack".

I'm somewhat of an "async-sceptic" - in a sense that I believe that in its current form async brings more pain than benefit for majority of projects.

So for web server I seem to have two choices: there's rouille and now there's astra. I used rouille before, for similar reasons, it was OK. But I like astra's hyper-based yet-blocking model, and so far it feels kind nice to work with.

As I'm playing with different functionality, I feel some pain points. E.g. I now want to handle sessions, deal with cookies, possibly forms, etc. Hyper itself does not seem to help much with these.

So I wonder - if astra planning to remain rather bare minimum wrapper around hyper, or is the a room for some "conveniences" like cookie and form parsing, and possibly others - either directly, or in some companion/recommended libraries?

Do you have any plans already or are you satisfied with the current state?

[ibraheemdev]

I was planning on writing an axum-like web framework around astra, which I think could be greatly simplified due to being synchronous. If that does happen, I would likely leave astra as the hyper-synonymous library, and create a separate framework around it, but I'm not sure how much interest there was for such a framework. Your comment suggests that there is at least some :)

[dpc]

I know more people being a bit annoyed with the whole situation. Often they just work on very trust-sensitive software, and every dependency add up to the trust base, so it's important to them.

Axum web framework around astra would be awesome. I really like working with Axum, except for the async part. I mean - it doesn't have to be exactly the same, but I think axum got a lot of things right. Roille is well established blocking IO http server, but when actually using it... it just feels worse.

BTW. While looking more into tiny_http, it appeared to me that one feature that astra could uniquely well handle is some form of websocket/SSE/chunked body handling on the async executor by sending messages to a dedicated thread. tiny_http seems to work like that for most of the things, but under the hood it must be using threadpools. astra could actually have tokio poll on thousands of http connections at once, and demux them to one channel that can be handled by one or few threads. This way one would could get all benefits of async scalability, without the async DX baggage.

[dpc]

So, do you want to start working on axum-clone on top of astra? It could be a subdirectory in astra repo for time being. AFAIU, the goal would be staying as close to Axum as possible with blocking IO. I can't commit too much time to it, but I could submitting PRs with things I need as I need them, I think.

[dpc]

BTW. astrum seem free on crates.io . :D

[ibraheemdev]

I have some old prototypes that I can revive, I hope to have an MVP done in a couple days that you can play around with. I'm also not too strict about sticking to axum's API, there are a couple things I would prefer to change.

astrum is a fun name, but astra and moving the current crate to astra-server isn't a bad idea either.

[dpc]

Oh, that would be fast and awesome.

All sounds good to me, and up to you. astra is a good name.

I played a bit with: wrap, axum, rocket, rouille, and possibly other Rust web frameworks, and some were nicer, some less nice, but at the end of the day it's all: here are the routes, some middlewares, extract me request body/params, for this call do that and slap this response on the other side.

However, I think staying close to Axum (as a probably most popular async web framework) has lots of benefits, as the crate can be advertised "like Axum, but without async problems", and lots of tutorials and knowledge base would apply well, and there's also an important escape path for people who are afraid of trying blocking IO: "if you ever want to migrate to async, the conversion will be easier".

In addition actually debating the pros and cons when coming up with new designs is very time consuming, while "if something is missing submit a PR mimicking what Axum is doing" is a simple rule to follow.

[ibraheemdev]

I dumped an initial framework as /astra-web in this repository. It's missing most extractor/responder implementations, and there are a bunch of things that need to be cleaned up, but the main idea is there. The routing is greatly simplified from Axum's approach, but other than that it's mostly the same.

[dpc]

I'm yak shaving some stuff, but will get back to it sometime next week.

[dpc]

Finally found some time to look at it.

From the example:

fn main() {
    Router::new()
        .get("/", hello_world)
        .group(
            "/foo",
            Group::new()
                .get("/", get_foo)
                .get("/index", get_foo)
                .post("/new", create_foo),
        )
        .layer(layer_fn(logger))
        .serve("localhost:3000")
        .unwrap()
}

The fact that there's a serve on a Router is a bit odd.

Also I wonder if a group should just take ... a router? Seems like it would make it more composable, as one could nest routers in each other.

One thing that is like in Axum, but I miss over raw astra is ability to have routes as method on the state/service itself. I quickly grew to like it. BTW. It seems like currently State extractor is not implemented? Which is going to a blocker for me RN.

I wish axum and astra-web would allow both free standing and method on the state/service functions to implement Handler. Maybe it's possible?

Other than this it seems very small (awesome) yet quite complete for a starter framework. Of course more extractors etc. can be added (all the json etc. stuff maybe), but it all can be written manually when missing and added with time to the library.