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)

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.

What is DX?

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.

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?

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.