Feather: A Rust web framework that does not use async

by todsacerdoti • 1 year ago

44 47 1 year ago

Could be confused with Feathers, a Javascript web framework.

Not a Rust expert by any means, but what does it bring that there is no async in the framework? Wouldn’t most of the libraries use async anyway, connecting to queues, databases, external services via HTTP? It’s hard to imagine a backend that still won’t need async, so I wonder if it is even worth trying… (please do let me know if it is)

roude404• 1 year ago

It seems it goes more in the direction easy to use and quick setup of small endpoints and if you need some more you could integrate the tokio runtime (or any other async runtime) on top of it.

dochtman• 1 year ago

Async is a language feature to enable scalability, but an alternative approach is just to spawn a bunch of threads and block threads when waiting for I/O to happen. That is the approach used by this framework.

watermelon0• 1 year ago

In most cases, you have both an async and blocking/sync approach, sometimes even in the same library.

sodality2• 1 year ago

A large application, maybe, but sometimes you have a very small scope application that won't otherwise use async, so you value binary size, compile time, etc over theoretical XXX ops/sec

wint3rmute• 1 year ago

This is especially true for newcomers, but async Rust has significant mental overhead. You quickly run into things like the Pin marker, Tokio runtime, complex compiler errors related to ownership, basically each "normal" component of the language get some additional complexity due to async.

If you're new to Rust and you want to "just make a web app", the view at the async Rust landscape could be a turnoff for novices. I speak from experience, having started a couple Rust projects in Python/C++ teams. After writing in Rust for 3+ years I can navigate async contepts without troubles, but for someone coming from the usual popular languages (Python/C#/Java/C++), there are simply too many new things to learn when jumping straight into an async Rust codebase.

IMO this framework is going in a good direction, assuming that it will only be used for small/educational projects.

For the async Rust landscape, things are improving every year, IMO we're around 5-10 years until we get tooling which will feel intuitive to complete newcomers.

refulgentis2• 1 year ago

I'm curious, in this example, what does MiddlewareResult::Next do?

  use feather::{App, AppContext, MiddlewareResult,Request, 
  Response};

  fn main() {
      let mut app = App::new();
      app.get("/",|_req: &mut Request, res: &mut Response, _ctx: &mut AppContext| {
              res.send_text("Hello, world!");
              MiddlewareResult::Next
      });
  
      app.listen("127.0.0.1:3000");
  }

Given my lack of experience, I'm sure it's needed, it's just unclear to me what purpose it would serve in a server app.

IshKebab2• 1 year ago

Why does it not look lightweight? I think you might be seeing "middleware" and thinking that it enables a load of middleware by default, which is unlikely to be the case?

Qwuke6• 1 year ago

When you have 20 routes each being terminated with redundant `res.json(success);\n MiddleWare::Next` I think you can imagine why someone might see it as not lightweight in terms of unnecessary boilerplate - which most Rust webframeworks, async or not, don't require you to write out.

Qwuke6• 1 year ago

You're right, it doesn't really seem necessary and makes the responses of the route end up as side effects rather than part of the return type of the route functions.

Most web frameworks in Rust don't make responses a side effect and keep them as a response return type since that's better devex and much less boilerplate.

shmerl3• 1 year ago

What is DX?

firejake308• 1 year ago

Developer experience

shmerl3• 1 year ago

Thank you!

ianbutler• 1 year ago

Developer experience, like how nice it is to work with

shmerl3• 1 year ago

I see, thanks

tczMUFlmoNk• 1 year ago

The fact that a request can happily get a mutable reference to a shared context felt suspicious to me, so I ran a quick test, and it seems like the whole server is single-threaded:

    $ cat src/main.rs 
    use feather::{App, AppContext, MiddlewareResult, Request, Response};
    use std::{thread, time};

    fn main() {
        let mut app = App::new();
        app.get(
            "/",
            |_req: &mut Request, res: &mut Response, _ctx: &mut AppContext| {
                res.send_text("Hello, world!\n");
                thread::sleep(time::Duration::from_secs(2));
                MiddlewareResult::Next
            },
        );

        app.listen("127.0.0.1:3000");
    }

    $ cargo run -q &
    [1] 119407
    Feather Listening on : http://127.0.0.1:3000

    $ curl localhost:3000 & curl localhost:3000 & time wait -n && time wait -n
    [2] 119435
    [3] 119436
    Hello, world!
    [2]-  Done                    curl localhost:3000
    real 2.008s
    Hello, world!
    [3]+  Done                    curl localhost:3000
    real 2.001s

That is: when the request handler takes 2 seconds, and you fire two requests simultaneously, one of them returns in 2 seconds, but the other one takes 4 seconds, because it has to wait for the first request to finish before it can begin.

It feels like this has to be the behavior from the API, because if two threads run `ctx.get_mut_state::<T>()` to get a `&mut T` reference to the same state value, only one of those references is allowed to be live at once.

It doesn't quite seem fair to call this "designed for Rust’s performance and safety". One of the main goals of Rust is to facilitate safe concurrency. But this library just throws any hope of concurrency away altogether.

Qwuke6• 1 year ago

Yes, if you want a mature web framework that doesn't force you to use async then Rocket already exists, which is multithreaded and quite performant - and now allows you to use async if you want to.

Feather seems fundamentally single threaded and requires more boilerplate for something pretty simple. So I'm not sure the claim about developer experience holds up to scrutiny here either.

gfs2• 1 year ago

Reading the latest stable documentation [0], it appears that you have to use async?

[0] https://rocket.rs/guide/v0.5/upgrading/#stable-and-async-sup...

cirego2• 1 year ago

I noticed the same thing. I would have expected an Arc<Mutex<…>> or something similar for safe concurrency. Not sure what value is delivered by a single threaded, blocking web server.

koakuma-chan3• 1 year ago

This framework does thread per connection, but all requests go into a global request queue, and when you call `listen`, it enters an infinite loop which pops requests from the queue and processes them synchronously (one by one).

ivanjermakov• 1 year ago

Single threaded web server? Is this a joke?

7bit• 1 year ago

A single threaded Facebook server would have saved humanity.

ivape3• 1 year ago

Do we know if a Rust webserver can provide just more pure raw metal performance? I believe I've heard the case to be true for Go. What use case do we have for this, high performance chat/game servers?

Qwuke6• 1 year ago

Rust typically beats Go web frameworks on tech empower performance benchmarks, if you're curious where languages typically rank up in terms of web framework performance. https://www.techempower.com/benchmarks/#section=data-r23

What does "pure raw metal" performance mean? Go has a garbage collector, which I usually hear causing GC pauses negatively affecting performance compared to C/C++/Rust.

ivape3• 1 year ago

pure raw metal

It means exactly what it means. If I get a pure bare metal server, will that computer simply handle more requests than a Go or a Node server (assuming the same single-threaded paradigm)? That's the only reason I'd ever consider moving away from the ergonomics of something like Node or Python, if my bare metal server can save me money by simply handling more requests with less cpu/memory.

Edit:

Thanks for that link though, just got turned onto this:

https://github.com/uNetworking/uWebSockets/blob/master/misc/...

koakuma-chan3• 1 year ago

I wouldn't cite tech empower since they only benchmark HTTP/1.1

M4v3R• 1 year ago

After creating two non trivial desktop apps with Tauri framework which is Rust-based I would not consider using a Rust web framework. Web development is too dynamic and messy in my opinion, and Rust slows you down too much.

It’s for the same reason that some people are leaving Rust behind when it comes to game development after the initial excitement fades and problems start.

Now I do understand that there are cases where this might be viable (for example if you already have a team of experienced Rust developers) but I think in majority of cases you would not want to use Rust for web development.

Klonoar• 1 year ago

You're talking about a very different type of application than what the thread is discussing (server development, not overall web development - i.e not Tauri/Leptos/etc).

satvikpendem2• 1 year ago

This is a backend framework not a frontend/fullstack one like Tauri.

Feather: A Rust web framework that does not use async

Related Stories