Poll: What library would you pick today for a REST API?

:wave:
I am curious about what library you might select for building a REST API. I welcome any stories of API development in the thread. I prefer simpler libraries. I'll and team will end up picking one to experiment with but I wanted to poll the wisdom of the crowd.

what library would you pick today for a REST API?

0 voters

1 Like

No wisdom here.

I started out with Rocket many months ago thanks to the interesting presentations you will find about it on YouTube. Actix-web seemed to come from very shaky ground at the time an it's continued existence was even in doubt at one point.

Hadn't heard of iron at the time.

Anyway Rocket tuned out to be nice and simple to get a REST API with data from our CocroachDB working and has been working well since. The documentation is excellent and approachable for a Rust beginner as I was.

As for 'today' I would not be changing from Rocket unless I run into performance problems or find it cannot do something I really need. Both of which are unlikely.

Unless rocket is still limited to the sync world, in which case actix-web would be the obvious choice, I'd say it's a matter of preference nowadays between Rocket and actix-web.

What got me interested in Rocket was the nice declarative way I could attach routes to handlers using attribute macros (the alternative being the old actix api which would require me to specify the routes in the main fn, which never made much sense to me). But actix-web has had the nice declarative API for handlers for a while now too.

I'm not entirely sure how rocket handles data plucked from an HTTP request, but I do like the way actix does it by making it effectively declarative. That is, if you have a route with a parameter in it, you just attach a parameter to your handler of the correct type, and boom you have access.
I'd imagine that rocket allows something similar.

Other than that, actix has historically been near or at the top of various benchmarks, but it's a bit of an open question to what degree that translates to superior real-world performance, not least because it depends on what exactly any given server is doing.

My choice was between Rocket and actix-web. I chose the latter because Rocket only ran on nightly. I haven't had any problems doing the simple things I need for my use case. I did get worried when the kerfuffle around actix-web was at its height, though. That issue seems to have been resolved.

The only one I have used is Rocket. It is really simple and I like it. If what you are doing is compute heavy and doesn't do a lot of networking, it will work great. If you are doing a lot of networking, you will probably want to use async, in which case actix-web would be the better choose. But if you don't want to deal with the complexity of async then you don't have to. Rocket will work fine with networking it's just not going to be as efficient and performante.

It is not so obvious to me.

Unless one is really looking for performance in the face of thousands/millions of clients going async is not likely to be of noticeable benefit.

I have not looked in to Actix but my experience over the last couple of weeks getting into async with tokio tells me that going async adds a lot of complication that one might not actually need.

As you say, it all rather depends on what ones actual requirements are.

3 Likes

Not necessarily true. If you are able to make multiple concurrent requests (either to a database or another web service) then you will see lower latency with async even if you server only has one client. It just depends on the use case and if you actually leverage async's concurrency in your handlers.You could make concurrent requests by forking and joining threads but I feel like async might be easier at that point.

2 Likes

I suggest you do so. My development experience with Rocket, and how easy it was, is very similar to how Actix now functions. The biggest difference is that the routes are async fns. And even more importantly, I don't have to perform any extra ceremony in order to reap the async benefits.
Add that all up and the better choice becomes really obvious when you pit the 2 projects against each other, 1 is stuck in sync land, the other is fully async, and their APIs for routing and setting up and launching the server are very similar.
You can talk about not needing the scalability, but personally I much prefer getting the scalability essentially for free i.e. having my cake and eating it too.

And then there's what @asafigan said, it's possible there's a noticeable performance difference between sync and async when multiple concurrent requests are being made. How much that matters depends on what the use case is.

I neither said nor implied that. I said it's mostly a matter of preference.
Unless Rocket is stuck in sync land (which I honestly don't know, not having used it in more than a year), in which case the choice becomes obvious as explained above.

1 Like

Certainly async will be an advantage when you have to wait on many things at the same time. Saves the overheads of using lots of real threads.

I don't see much difference in complexity between doing a bunch of std::thread::spawn vs something like tokio::spawn though.

Am I missing a point somewhere?

What I do find is that going async added complexity to my networking code that deals with web sockets and NATS messaging.

Async can be simpler in this case because you don't need tokio::spawn. You can just use something like join or join_all. But I guess you could write similar macros or functions for use with threads.

1 Like

OK, cool.

Thanks, for creating the thread. I am also interested on the result.
I did not vote , as I did not try the frameworks yet. But I plan to try both .
I would suggest you do the same (experiment a bit with both). Choosing the most suitable from two good frameworks can save a lot of time later.
I only had choice paralysis when choosing from 20+ frameworks for the same thing in Java :slight_smile:

2 Likes

You had it easy.

Don't ever try to choose a GUI framework for your client side Javascript. That is a road to madness.

:slight_smile:

1 Like

I’m actually missing tide in the poll :wink:

I’ve used it for some minor projects and found its usage quite convenient for a REST API that uses a mongoDB to request data from.

1 Like

I am using warp for an API I am currently finishing up. I needed the ability to send out server-sent events for anything other than a read, and it had the simplest API for that in my opinion. It's also fully asynchronous, which was a baseline requirement when I chose the framework; my end goal is to be able to support 100k+ concurrent users, so synchronous wouldn't cut it. I also wanted to run on stable, as this project doubles up as my senior project.

Happy to answer any questions you may have about my experience with warp. I've also used Rocket in the past, but its most recent release is still synchronous, requires nightly, and doesn't support SSE.

Side note: I slightly modified the title to make clear it's a poll from the second someone starts reading.

5 Likes

Thanks for the addition! Some of the ideas in tide strongly appeal to me. Yet for this poll I have weighted the selections toward most established projects and thus most likely to stick around long term. I feel my heuristic lacks a lot. But in my experience leading a small team of developers we do better when we optimize for longevity over ingenuity.

I had to implement a gateway 2 weeks back that had to keep a handle to the request while it waited for a response from kafka. I tried actix, but I didn't get the actor stuff and struggled to keep the request.

I ended up using hyper and with the examples i could quite easily keep my request handle.

If your backend is just a db then rocket should be easier, but I did like the control hyper gave me

Rocket is nice and everything but it's has a couple of problems
First you must use nightly which is not really ideal for a production codebase and the bigger issue is that rocket is synchronous compared to async actix-web it does a lot of sitting and waiting thus hanging less traffic.

Note that the upcoming Rocket 0.5 should work on latest stable Rust.

Let's call that 'potential' problems in some circumstances.

People, including my company, have been using Rocket on nightly Rust for ages. Rarely have there been problems with that, I have never seen any.

Unless one expecting a high load on a web server being good old fashioned synchronous code is not a problem.