Actix

Hi all!

I've been using Actix for some years now and I came across a lot of blog posts & videos on YouTube that cover Axum, at first glance it seems a very good alternative to Actix. I wanted to have more info about people who may have already used Acix and moved to Axum and the experience, pros & cons of both. I'm considering using Axum in the future but don't know if performance-wise could be the same or even better than Axum.

We are very pleased to announce v4.0 of Actix Web! Actix Web is a powerful, high-performance web framework used to create web services, from micro to monolith. You can rely on it to build your most mission-critical systems.

Key Changes

The v4 release have been a community-driven effort, with of over 600 commits by 57 contributors! We've come a long way together. Key changes include:

• Full compatibility with Tokio v1 ecosystem including #[tokio::main] support.

• Make actix-http more lean. This crate underpins Actix Web, containing our HTTP/1 implementation and lower-level HTTP handling.

• API refinements, generally to increase expressiveness and developer productivity.

• Reducing the number of paper-cuts and non-obvious behavior in specific APIs.

• Vastly improved documentation on a large number of key items.

The contains explanations and diffs showing how to update. It is worth reading at least the items marked with a warning emoji because these show behavioral changes and will not surface compiler errors. Changelogs for actix-http and actix-web contain the complete, exhaustive list (~400 entries) of changes.

Looking Forward

The team learned a lot while working towards this release. Expect shorter beta periods between releases.

The other crates in the actix-web ecosystem will be stabilized in the next few days.

The first couple of point releases for the v4 cycle are largely planned out. Many of the items slated for inclusion are already available in the crate.

Hello Rustaceans. I am always reading advices on the future of Rocket and it seems that no one is really certain of where it's heading. I have been using Rocket for over a year and it seems that I am convinced to move to Actix solely based on the future of Rocket. Please, your thoughts?

He tweeted and has moved actix-web and actix-net to his personal account with a postmortem left in the original repo: . I’ll leave the quoted text here as well:

Actix prject postmortem

Another day, another "unsafe shitstorm”, I guess I get used to it.

It is interesting how easy to move comment out of context and how hard to comment with very clear intention (especially if you are not native speaker) What was the patch? It was very strait forward, simple, uncreative change, intention was just to remove unsafe not to fix existing code. I believe software development is one of the most creative work we do, and creativity is part of why we love software development, why it is fun. Especially if you combine it with real world projects constraints. “creative constrains” could be source of very interesting solutions. Being on the edge of your abilities is super fun. So uncreative change felt boring (oh! And author gave up copyright claims for that patch (a bit irony and sarcasm)). I’ve never used unsafe unintentionally, I use it because I believe usage is safe. There was no any malicious intentions. I believed it held mutable aliasing invariant and I was very happy that someone found real problem. I wanted to solve the problem, just with a bit of creativity. And use RefCell solution only if it would be not possible to solve it with any other way. Btw, I like the solution I found, it is in master and solves the problem at least one from the issue. If you want to push boundaries you have to touch this boundaries and sometimes you push too hard.

Be a maintainer of large open source project is not a fun task. You alway face with rude and hate, everyone knows better how to build software, nobody wants to do home work and read docs and think a bit and very few provide any help. Seems everyone believes there is large team behind actix with unlimited time and budget. (Btw thanks to everyone who provided prs and other help!) For example, async/await took three weeks 12 hours/day work stint, quite exhausting, and what happened after release, I started to receive complaints that docs are not updated and i have to go fix my shit. Encouraging. You could notice after each unsafe shitstorm, i started to spend less and less time with the community. You felt betrayed after you put so much effort and then to hear all this shit comments, even if you understand that that is usual internet behavior. Anyway, removing issue was a stupid idea. But I was pissed off with last two personal comments, especially while sitting and thinking how to solve the problem. I am sorry for doing that.

It’s been three years since I started actix project (time flies). I learnt a lot, i meet new people, I found language that I really like and want to use it fulltime, I found fun job. But damage to the project's reputation is done and I don’t think it is possible to recover. Actix always will be “shit full of UB” and “benchmark cheater”. (Btw, with tfb benchmark I just wanted to push rust to the limits, I wanted it to be on the top, I didn’t want to push other rust frameworks down.) Everything started with actix, then actix-web and then actix-net. It took a lot of time to design api and architecture. Each of this projects was rewritten from scratch at least 4-5 time. I hope I expanded some boundaries and found few new patterns, I hope other developers will check source code and find inspiration to move even further. Nowadays supporting actix project is not fun, and be part of rust community is not fun as well.

I am done with open source.

P.S. I moved actix-net and actix-web project to my personal github account. I will make decision during next couple days what to do. I don’t want to see the project becomes ghost of what it was. Maintainers must understand how everything work, but don’t anyone who does and those who could are busy with other projects. At the moment I am planing to make repos private and then delete them (will remove benchmarks as well), unless others suggest better ideas.

Everything has to come to the end. It was fun trip but now is time to move on. Life should be fun.

There's an on Actix-net pointing out and presenting unsoundness. Yes, it's deleted, it still can be found on .

Issue history summary:

1. Found by Shnatsel

2. Closed as harmless to users by fafhrd91

3. Proven harmful to users by Nemo157 and reopened by JohnTitor

4. Fixed and closed by fafhrd91

5. Proven unfixed and proposed new patch by Nemo157

6. New patch commented "this patch is boring" by fafhrd91

7. Issue is deleted

8. Fix is reversed by fafhrd91, issue still present

I hope it's an objective summary. Any thoughts?

Edit: Now whole actix/actix-web is deleted. See fafhrd91's . He kept copy of Actix-web in personal repo .

One of the most famous rust web server frameworks Acitx-web now released 1.0 version.

Useful Links

Big Changes since 0.7

Actix-web obsolete actix from it's dependency, but you can still use actix ad-hoc. Now it's dependency looks like this: futures & tokio -> actix-rt (actix runtime) -> actix-net -> actix-web

If you want to learn more about this change, you can refer to this and see all the discussion below.

Hi!

I know that axum is based on hyper and actix web is completely different and does not share the hyper stack, from my understanding actix was the fastest web framework around.

I know that axum is a thin layer of abstraction over hyper but performance wise is actix more performant that axum?

I've searched on internet but couldn't find a good benchmarks

I know I can google but its nicer to hear from active developers. Any using this? Is it purely for high performance web server apps? Or can you dev platform agnostic front end ui/apps? Does it use wasm?

Thanks and merry christmas.

Hi friends, I am a beginner in rust web development, my question would be which backend web framework would you recommend me? Which one has an easy learning curve that is feature rich?

Things to consider:

• Speed

• Functionality

• learning curve

Hello folks,

I open-sourced a fast HTTP web server based on Hyper and Rust, under Apache 2.0 License. This module has been used internally in multiple large-scale, high-throughput, and low-latency projects in my organization for the last few years. It is proven to handle billions of requests per day with sub-millisecond latency.

Framework has almost zero overhead, unlike other frameworks such as Actix (earlier, we used Actix and faced performance challenges). Implementation is very lightweight and does zero-copy of request and response.

Features are

• Supports brotli, deflate, and gzip encoding for request and response

• In-built access logs and metrics for APIs

• Simple APIs to get current metrics - in JSON and Prometheus format

• In-built OOR (Out of rotation API) to take the server out of rotation

• In-built Server Health API

• Very simple and fast match pattern-based routing.

• It's much faster than Actix and other web servers out there.

• Support for optional daemon service that gets started on server start and stopped on server shutdown

• In-built server shutdown handling.

Looking forward to this community's valuable feedback. If you like the project, please `star` it to spread it further.

Thanks

Hey , thank you for creating Actix Web! It's a critical component of several production systems I work on that bring in significant revenue. The APIs are clear and well thought out, and performance is excellent. I suspect actix-web's excellent performance on the Techempower Framework Benchmarks game are also very beneficial for increasing usage of Rust. Apologies for speaking only in my self interest, but I hope you aren't too discouraged by the online negativity and continue your great work! Furthermore I suspect there are many other people like me, silently appreciating your work and saddened by the mob-like behavior the internet encourages.

And also Warp.

The two most prominent web frameworks in Rust are Actix-Web (which is the leader of the two) and Rocket. They are known for their great performance (and unsafe code) and great ergonomics (and nightly compiler) respectively. As of late, the folks at Rocket are to an async backend. So I thought it would be interesting to see how the performance of the async branch stacks up against the master branch, and agains Actix-Web.

Programs

We use the following hello world application written in Rocket:

#![feature(proc_macro_hygiene, decl_macro)]

#[macro_use] extern crate rocket;

#[get("/")]
fn index() -> String {
    "Hello, world!".to_string()
}

fn main() {
    rocket::ignite().mount("/", routes![index]).launch();
}

To differentiate between the async backend and the sync backend we write in Cargo.toml

[dependencies]
rocket = { git = "https://github.com/SergioBenitez/Rocket.git", branch = "async" }

or

[dependencies]
rocket = { git = "https://github.com/SergioBenitez/Rocket.git", branch = "master" }

The following program is used to bench Actix-Web:

use actix_web::{web, App, HttpServer, Responder};

fn index() -> impl Responder {
    "Hello, World".to_string()
}

fn main() -> std::io::Result<()> {
    HttpServer::new(|| App::new().service(web::resource("/").to(index)))
        .bind("127.0.0.1:8000")?
        .run()
}

I also include Warp:

use warp::{self, path, Filter};

fn main() {
    let hello = path!("hello")
        .map(|| "Hello, world!");

    warp::serve(hello)
        .run(([127, 0, 0, 1], 8000));
}

Results

Obligatory "hello world programs are not realistic benchmarks disclaimer"

I ran both applications with cargo run --release and benched them both with wrk -t20 -c1000 -d30s http://localhost:8000.

Rocket Synchronous

Running 30s test @ http://localhost:8000
  20 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     7.14ms   61.41ms   1.66s    97.97%
    Req/Sec     5.15k     1.45k   14.87k    74.03%
  3076813 requests in 30.10s, 428.40MB read
Requests/sec: 102230.30
Transfer/sec:     14.23MB

Rocket Asynchronous

Running 30s test @ http://localhost:8000
  20 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     4.34ms    3.06ms 211.14ms   79.00%
    Req/Sec    11.15k     1.81k   34.11k    79.08%
  6669116 requests in 30.10s, 0.91GB read
Requests/sec: 221568.27
Transfer/sec:     31.06MB

Actix-Web

Running 30s test @ http://localhost:8000
  20 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     3.82ms    5.58ms 249.57ms   86.55%
    Req/Sec    24.09k     5.27k   69.99k    72.52%
  14385279 requests in 30.10s, 1.71GB read
Requests/sec: 477955.05
Transfer/sec:     58.34MB

Warp

  20 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     4.23ms    8.50ms 428.96ms   93.33%
    Req/Sec    20.38k     6.09k   76.63k    74.57%
  12156483 requests in 30.10s, 1.47GB read
Requests/sec: 403896.10
Transfer/sec:     50.07MB

Conclusion

While the async Rocket still doesn't perform as well as Actix-Web, async improves it's performance by a lot. As a guy coming from Python, these numbers (even for synchronous Rocket) are insane. I'd really like to see Rocket's performance increase to the to point where as a developer, you no longer need to make a choice between ease of writing and performance (which is the great promise of Rust for me).

On a side note: sync Rocket takes 188 KB of RAM, async Rocket takes 25 MB and Actix-Web takes a whopping 100 MB, and drops to 40 MB when the benchmark ends, which is much more than it was using on startup.

You’ve heard the news. You might even depend on the framework for a personal project. Maybe even a work project.

It seems in my communication with Nikolay on Gitter that we won’t be seeing a return to the Actix org on GitHub. Maybe his concerns are valid. And maybe his reasons for exiling the code from @actix we’re warranted. It’s unfortunate, but we have an opportunity to take this amazing project onwards.

A fork is not the most ideal approach in my opinion but I believe that this project doesn’t deserve to be abandoned and that some of us can do that.

A few months ago myself and probably about 30 others joined the @actix/contributors team on GitHub. There are people willing to help. How about it?

Edit: :)

I am currently working on a project where performance is absolutely critical. The server should be able to handle 1500 requests/s. Actix and Warp are the two options that I am considering. The database I am using is mongodb, which needs Tokio or async-std ig? And my paths are basically get requests, with a path that changes every time and must be extracted by the server. e.g. /[String]. Memory safety is also a top priority.

Currently, accordingly to me, each option had the following advantages and disadvantages:

Advantages of Warp:

• runs in the Tokio runtime

• easy to extract variables from paths

Disadvantages:

• consistently low performance in benchmarks

• complicated filter system

Advantages of Actix:

• Much faster

• More straightforward routes

Disadvantages:

• Actix had a memory leak recently, so I don't know if I should use it

• Will it run with mongodb?

If I do end up choosing Actix, I am having some trouble understanding how to extract variables from get requests. I need help with that.

Which one should I use?

UPDATE: Ditching MongoDB maybe. My use case involves counting the number of times the server receives certain strings (plural).

UPDATE: Thank you to everyone who has replied so far. My final decision is ditching a DB all together and storing data as JSON. As for the server, I might wait for Rocket v0.5, or use Actix. Thanks, once again.

Apistos get its 0.2.0 release today with the introduction of multiple UIs to expose the API documentation.

Apistos now natively supports Rapidoc, Redoc and SwaggerUI.
In addition to these options, you can also add your own UI using `apistos-plugins`.

Version 0.1.x was about improving Apistos to be a good replacement for Paperclip. We hope version 0.2.x will allow us to go further and provide a FastAPI-like experience for Actix-web.

Github:

Hello everyone!

I'm stoked to announce the . It is an implementation of the distributed consensus protocol in Rust using the actor framework. The intention here is to provide a backbone for the next generation of distributed data storage systems ― systems like SQL and NoSQL databases, KV stores, streaming platforms &c.

Along with the initial release, there is a with code examples, discussion, and recommendations on how to build a robust data store using this Raft implementation. Of course, the are up on docs.rs as well.

This implementation of Raft is fully asynchronous, driven entirely by actual Raft events. All interfaces for sending input to and receiving output from Raft are well defined, along with implementation guides.

Give it an eye, let me know what you think. I'm excited to see what we can build.

Hello everyone, I've decided to create a personal blog using the Yew + Actix-web stack. I thought someone might find it useful to see an example with the latest versions.

I found that Actix-web's handler does not require Send, but Hyper does. I want to know how Actix-web resolves this. I thought of a simple solution by using spawn_local to bind the handler to a specific thread, but I'm unsure if there are any issues with this approach.

async fn hello(_: Request<hyper::body::Incoming>) -> Result<Response<Full<Bytes>>, Infallible> {
    let a = 10;
    let p = &a as *const i32;
    tokio::task::yield_now().await;
    println!("{:p}", p);
    Ok::<Response<Full<Bytes>>, Infallible>(Response::new(Full::new(Bytes::from("Hello World!"))))
}

#[tokio::main]
pub async fn main() -> Result<(), Box<dyn std::error::Error + Send + Sync>> {
    pretty_env_logger::init();
    let addr: SocketAddr = ([127, 0, 0, 1], 3000).into();
    let listener = TcpListener::bind(addr).await?;
    println!("Listening on http://{}", addr);
    loop {
        let (stream, _) = listener.accept().await?;
        tokio::spawn(async move {
            tokio::task::spawn_local(async move {
                if let Err(err) = http1::Builder::new()
                    .serve_connection(stream, service_fn(hello))
                    .await
                {
                    println!("Error serving connection: {:?}", err);
                }
            });
        });
    }
}