Recommendations for a web framework for newcomer

Hi, after a few months, I finished reading The Book and doing Rust By Example, so my next learning step would be to redo a gym management web app I initially made in python(django) I really like rust so far, so motivation is there :slight_smile:

Coding is a hobby for me, so I'm looking for a framework that is easy to understand and has many components already available(either as "batteries included' or plugable modules) or planned. Having async is a must too since I want to continue my learning. My background: I've been doing scripting(batch, vbscript, powershell) since forever, and I've dabbled in python for about 10 years as a hobby(meaning I never got in OOP or other advanced stuff that is used everywhere now. I still stick to function and struggle still when I see lambdas and other "modern" creation :stuck_out_tongue: )

Over the months that I learned the basic of rust, I kept an eye on warp, rocket, actix-web and tide, which look like the currently developed frameworks.

Warp: I simply can't grasp the filters everywhere. I know many people highly recommend it on reddit, but I came to the conclusion that it's not for a beginner like me. In my limited testing, compiler messages were also very difficult to understand compared to the usual rust error message.

Rocket: That one I understand the synthax and principles! :stuck_out_tongue: I'm on the fence if I should select it mostly because it looks like making it async seems to take a very long time, and any projects started right now will probably mean refactoring alot when/if 0.5 comes out.(I could be wrong, it's only a feeling) Current doc for async is also not really done so it's difficult to jump right in for someone like me.

Tide: I also understand that one! Might require a higher level of knowledge than I have though because the doc is still sparse and more geared toward pure devs for the moment. I like that the main dev started a "core" team though, it shows long term dedication and probably a nice pace of development once it's settled :slight_smile:

actix-web: The most mature, but some principles are weird and I have trouble liking them(like scopes) Lots of boilerplate too when my requirements are quite simple. I'll learn it anyway, no matter what, because I pre-ordered the book "Rust Servers, Services, and Apps", and it uses actix as the framework, but I'm not a fan and probably won't use it for my project.

So,with all that said, I'm mostly hesitating between Rocket and Tide. Any recommendation between the 2 of them? I take comments for the other 2 frameworks too, or others I might have missed.

Thanks!

3 Likes

Tide is definitely the simpler and easier to learn of the two, although you already seem to understand Rocket fairly well so maybe that's not a concern. Rocket probably requires less boilerplate than Tide as it automatically manages all the request processing for you (Tide just gives you a Request struct and it's up to you to extract what you want from it).

1 Like

Iβ€˜m personally in favor of tide. Itβ€˜s straight forward, lightweight, expandable with middleware and easy to learn. Even though the documentation and examples could be improved I got a recent RestAPI backend running in less than a day :wink:

Async is baked into which is a big plus from my point of view.

Best regards.

1 Like

With only a few months of Rust experience I found I needed a REST API in our project and landed on Rocket. I would say it is pretty straightforward and pleasant to use. A year later as things have grown I have not felt any need to look around for anything else. The documentation is great.

Sorry I can't make a comparison to other web server crates having not tried them. At the time Actix was going through, shall we say, a "crisis of management" and so was immediately crossed off the list of options. Although I understand those issues have been resolved since.

I don't think you should worry about Rocket not being async. Firstly I suspect you are unlikely to need the benefits claimed for asynchronous code. Secondly the Rocket API looks very similar in sync and async, as far as I can make out from the version 5 docs and reading around.

1 Like

As someone not super familiar with web development, I found Rocket's high quality docs to be indispensable. I tried Tide but found it more difficult to make stuff with despite the simple API because of how clueless I was (and still am).

1 Like

There is also Nickel, Iron and Gotham.
I've only got experience with Gotham, Rocket and Actix - and in my opinion rocket is the easiest, but it does not run on stable Rust. Actix was for me the most difficult of the three, so I sticked with Gotham.

1 Like

Thanks for the replies so far, this gave me confidence to dig a bit deeper with both to see which might fit best for me. I took time yesterday to redo in tide and rocket the first chapter of the book I mentioned above(even though it's using actix as a base, I highly recommend it to newcomers like me because it also talks about stuff like State and models in rust and code organization and it helps alot since most of that was baked in in Django and mostly transparent)

Basically, in that chapter, we start a server and add an /health endpoint that uses async to count how many time it was called.

I used rocket from the master branch and used the doc related to that version. I agree that the use of macros make it mostly identical to the non-async version. For Tide, I used the API doc.

I concur that Rocket documentation is a gift for beginners and a must. I can't make head over tails of the navigation in an API doc format, so a "verbose" doc is welcome. (But, I must say, becoming more familiar with the API doc format is a goal I have for 2021 since it's the standard for libraries doc.) A small warning, I've met quite a few small errors in the doc for Rocket, but that was expected since they are doing still doing a major overhaul for async.

End result: I was able to make it work with both framework and it was extremely lisible. It took more time with Tide, but that is only because of my lack of experience with how to find the information within the API doc format. This small experiment also made me understood quite clearly what Kester mentioned about some boilerplate in Tide(but it's alot less then actix). While Rocket will deal with formatting http input/output for us, while in Tide you actually have to think about what is coming in and what you are returning, and code it accordingly. Here's the result.

Rocket:(notice how the fn return a string, rocket deals with the HttpResponse. It also kinda combine the route with the handler by using a macro)

#[get("/health")]
pub async fn health(app_state: State<'_,AppState>) -> String {
    let health_check_response = &app_state.health_check_response;
    let mut visit_count = app_state.visit_count.lock().unwrap();
    *visit_count += 1;
    format!("{} {} times", health_check_response, visit_count)
}

Tide:(We must build the HttpResponse in the fn and return it. Routes and Handlers are clearly defined)

pub fn general_routes(cfg: &mut web::ServiceConfig) {
    cfg.route("/health", web::get().to(health_check_handler));
}

pub async fn health_check_handler(app_state: web::Data<AppState>) -> HttpResponse {
    let health_check_response = &app_state.health_check_response;
    let mut visit_count = app_state.visit_count.lock().unwrap();
    let response = format!("{} {} times", health_check_response, visit_count);
    *visit_count += 1;
    HttpResponse::Ok().json(&response)
}

So, I'm still torn, in a good way. Rocket doc helps me alot, but one reason I've always struggled understanding the "magic" django does is that it hide so many things in the name of simplicity, that I never really learned what a web app architecture was and what it really does behind the scene. Rocket seems to have the same philosophy, doing alot of stuff for us(which is a worthy goal, but I might eventually prefer the Tide approach that makes us learn more about http )

Tide makes it clear what is happening, but I'm really struggling finding what to do and how because I'm no dev and the API doc format is a bit like deciphering hieroglyph for me. I saw a blog post though that some kind of book was planned eventually, so that will be a great addition if/when it happens.

It was a fun test to do(Especially since it worked in the end!). I will do more tests in parallel as time permit, but the learning process so far has been great(except for lifetime, that part, I still don't grasp correctly, but at least the compiler helps alot with it's suggestions.)

Edited for clarity(english isn't my first language) and typos.

1 Like