Actix vs rocket and my needed

I need to a web framework, I found actix and rocket.
I need to the following features:

  1. REST
  2. auth in mongo
  3. static page and using template engine such as ninja.
    Which is better?
2 Likes

I suspect you'll get roughly the same mileage from both frameworks when it comes to these requirements. With that said, one thing I've read people say consistently who used both is that Rocket has better documentation.

I've not tried Rocket, because of the long time to release the 0.5 version. Something to catch up on.
In Actix I don't like the API breakage. It has always been hard work down to architecture to update my code for new Actix releases, although it is not only the cause by ActixWeb but sometimes also by its used dependencies.
You stick with tokio. I don't like this strange async "construction area" in Rust with incompatible runtimes.
The repositories of Actix are organized by a group of people (about 20) and Rocket repository is a private one by Sergio Benitez (PhD Stanford and MIT with good experience in performance optimization), but sure you could always fork.
Both frameworks have no problem with your feature requirements and are very similar for them.
I'd give Rocket a chance in a new project, seems to be more accessible for newcomers.

As far as I can tell both Rocket and Actix can meet your needs.

I'm a happy Rocket user. Mostly by chance as when I started looking to create a web server in Rust I happened upon a couple of excellent presentations on Rocket by Sergio Benitez. And then found the documentation was excellent and everything worked fairly easily.

At the time Actix looked like it was going to meltdown as it's creator threatened to stop development and remove all the repositories. Not at all an inspiring situation.

I'd go with rocket. Actix-web is a great project, but the documentation available is awful and as a result it will take you far longer to get anything done than if you use Rocket.

1 Like

I needed to build an API that can serve GET/POST etc. I actually ended up settling on hyper for two reasons:

  1. This example was very easy for me to follow, compiled right away, and gave me a good starting point.
  2. It is part of the same ecosystem as Tokio (see their cool technology stack illustration ). This made me more confident integrating it with other microservices (like a tokio-based message bus listener
1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.