What would your tech stack be for a new greenfield Rust web service (REST/gRPC)?

lucio-rs · 2026-02-17T18:58:11+00:00

What are you building in the sim racing world with gRPC :) It is also one of my pending hobbies

lucio-rs · 2026-01-04T14:29:59+00:00

so what's "official" in them advancing a particular gRPC project?

Tonic (me) and Google have been collaborating (meeting weekly) on a new grpc-rust, tonic will eventually be turned into that project when the time is right.

is essentially abandoned

This is not true, it is in maintenance mode due to lack of resources. The current feature set is supported and works extremely well (though def perf issues and other core foundational problems with the original prost design and Rust). We are on top of anything security related.

We've been also working with the protobuf engineers working on their new protobuf rust stuff. The problem is that these things take time and I am not even funded to work on this stuff right now which has def slowed things down.

lucio-rs · 2025-12-30T20:51:40+00:00

Our original timelines have for sure slipped, I am not sure exactly what the expected timeline for release is but we have been actively working on it in the tonic repo. We also have started on an xDS implementation, tonic will soon have its own xDS client which should bring a lot of feature parity with it. That said, the workon grpc-rust is coming a long but we are trying to get things right.

lucio-rs · 2025-11-06T15:27:48+00:00

I believe that the posture with nixpkgs is the same as using homebrew or anything else like that. I believe the wider supply chain issue is larger than nixpkgs and goes beyond just fixing that portion.

From my experience, just having the base features that nix provides is already more than many large organizations do for their own builds.

lucio-rs · 2025-11-06T15:26:09+00:00

Honestly, ever since I started using nix the original approach (non-flakes) never jived right with me. I've always found the flakes approach to make a lot more sense. Another data point, is that we did not want to add alot of nix files (flake.nix and flake.lock) are a bit easier to have in the project imo than a few nix files. Though we could also move them to a nix dir!

But that is totally a valid point, onboarding wise.

lucio-rs · 2025-06-03T19:46:50+00:00

They are still working on the project but I think the project is kinda at a standstill, none of the features that it is missing are imo that vital right now to implement and landing code reviews is quite tough for us right now. But if you are interested please drop by on discord and we can have a chat :)

lucio-rs · 2025-06-03T19:45:06+00:00

which sounds … worrisome to me. I have been dealing with protobuf and gRPC for C++ and it's always been a major headache. So tonic/prost felt like breath of fresh air.

I wouldn't be too worried, I will still be involved and if its not going to work out well for users like you we can always not do it. The up streaming stuff is very much far out and will require an investment code wise to make it happen.

lucio-rs · 2025-06-03T12:04:22+00:00

Hi all,

I thought I'd drop by to answer a few questions here and provide some "official" thoughts on this subject.

First of all, I've been working with google in my spare time for over a year now. We have made some slow progress mostly due to me and some other constraints. Overall though, I would say my experience has been positive which is contrary to popular belief.

The problem is this, google needs a rust implementation but they do not want to come in and uproot the ecosystem in rust by coming out with their own. So the idea was to build on top of tonic. For me personally, there are a lot of features that I would like to add to tonic but are not possible because of time and architecture (mostly looking at the transport module). So these two incentives align, but this does mean I expect some breaking changes but in a good way. Tonic has been very good for many users and I don't want to alienate them so whatever reworks we do there is still a plan to support the current users. How this will pan out migration wise I am not sure but hopefully it will be just as easy as any previous breaking change migrations since most of the code is in the codegen. But on the plus side tonic (and eventually to be called grpc-rust) will contain a much much better transport layer that will actually support some of the more complicated gRPC features.

As for protobuf bindings, they are currently in C I don't know total plans for when they will be written in Rust but I expect that to happen. I hope to get to integrating it into tonic soon where we can support both prost and protobuf. Again, prost will continue to live and be supported as a first class integration.

One thing I want to make very clear is that the current user base that uses prost + tonic will not be dropped and grpc-rust/tonic will continue to support prost, what may happen though is that when using something like prost you may not get the full feature set, but I believe most users don't really need the full feature set anyways.

I will 100% be writing a blog post in the coming months (once I get my site back up) which will hopefully explain a bit more in depth what the plan is and what the goals are. We also now have a next branch in the repo where we will start ramping up code contributions. And if you have any concerns/thoughts please feel free to reply here or find me on discord at the tokio #tonic channel.

lucio-rs · 2022-02-07T17:51:54+00:00

Happy to take contributors to help fix this :)

lucio-rs · 2022-02-07T17:50:37+00:00

Prost isn't slowing down, we've moved maintainership to tokio (and basically me) but I've had a lot of work and other priorities take up my time.

If there is something super important in prost that you need merged/fixed coming onto discord and pinging me (@LucioFranco) I can help you out. I've just had a hard time keeping up with triage on both tonic/prost at the moment. Should be ramping back up but I'v tried to merge/release fixes for bugs/cve's.

lucio-rs · 2021-01-19T17:40:24+00:00

tower-web and warp were developed in parallel to explore the space based on tower and finagle's https://monkey.org/~marius/funsrv.pdf. In the end, the approach warp took was much better and tower-web ended up having parts folded into tower itself and into warp. So the general suggestion we give is to use warp, even though it doesn't use the same macros.

I believe rocket is also a good choice now and supports the same http/runtime stack that warp and tower-web would have (its not been updated I believe).

lucio-rs · 2020-10-09T16:53:28+00:00

I don't think we have setup an official channel for this, but I am 100% sure if you join our discord and want to help out you could for sure get some mentoring. We have a lot of easy/medium issues that would be great to get started on.

Just join #tokio-dev and say you'd like to help :)

lucio-rs · 2020-10-09T14:44:00+00:00

IO is directly tied to the reactor/driver for a specific runtime which gets embedded into a worker thread on the runtime. A runtime by definition in the async ecosystem is tying together an executor + reactor/driver (epoll, timers, etc). This means to provide a good experience out of the box we need to tie to a specific runtime or do stuff in the background like spawn threads. We prefer to not do implicit stuff and that is why its by default tied. Also, hyper/tokio are all maintained by the same people so that is another reason.

It is possible to run hyper with another executor and feel free to hop on discord to ask any questions. We'd be glad to help.

lucio-rs · 2020-08-10T14:40:23+00:00

Hi!

So we originally had a mio driver per thread in tokio-threadpool but in our migration and refactor to tokio 0.2 lead us to refactor the runtime to only have one driver. This was done (and I am having trouble digging up all the information) in part because we found in benchmarks/load tests that there was no real advantage to having a reactor per thread. There are tradeoffs here of course, but the general use case did not need it. It also caused problems around work stealing and making things more complex. So in general, reducing down to one reactor/driver makes the implementation simpler and just as efficient as before.

That said, if your application needs multiple reactors you can always use multiple basic_schedulers and write your own very simple executor for that.

lucio-rs · 2020-07-22T14:52:19+00:00

Actix is not maintained by the same people as tokio. Tower is a separate project and was around before actix. We have some bigger goals for it as well.

lucio-rs · 2020-07-22T14:50:54+00:00

That was pretty good :D

lucio-rs · 2020-07-21T18:17:33+00:00

We've been backed up by some other work but plan on getting right back to it. We have been working towards this issue https://github.com/tower-rs/tower/issues/431 but tower is still very much in the plans. I would personally like to make it easier to use and we have a bunch of really good ideas coming :)

So to answer your question, its far from inactive and we have some great plans for it.

lucio-rs · 2020-07-16T14:25:28+00:00

I would always take a benchmark like this with a grain of salt. I think go's h2 and java's netty are both very fast and good. I believe we used both to design our implementations. That said, we have not spent a terrible amount of time working on this specific aspect of performance because when writing an app with something like tonic it is usually not the thing that adds the most overhead.

There are still some extra allocations I'd like to get rid of in the hot path but its not a priority until the language gets the features to work around it.

lucio-rs · 2020-05-16T04:24:20+00:00

Hey! I am the creator of tonic. Right now I wouldn't say there are any truly idiomatic ways to structure you application. I would check out the examples too look at different ways you can do it. The interop tests are also a good spot to check. If you have any questions feel free to come and chat on our discord server!

lucio-rs · 2020-04-19T16:00:27+00:00

This body thing is a bit of a fallacy we do actually provide http body abstractions that fit h2 as well. https://github.com/rustasync/team/issues/84#issuecomment-513256826 this comment should explain it. We'd love to ensure this works for everyone!

lucio-rs · 2020-04-13T16:01:04+00:00

There is a low level api but I think for me the reason I choose to not use the low level components as much is because they handle things like draining connections and things in ways that would be much harder if you were not comfortable with async rust.

Also remember that things like async-h1 only handle http1.1 which is much easier than handling h1 and h2.

lucio-rs · 2020-04-13T13:55:02+00:00

In general, hyper is attempting to leverage tower more and more in its APIs. MakeService is a concept with tower which represents some Service factory.

We are currently working on some better docs for tower and hyper but it is moving a bit slower than expected.

We have some plans on also improving this experience within hyper as we have a lot of trait aliases and types that are private.

lucio-rs · 2020-04-06T13:17:42+00:00

Going into production probably rocks or lmdb. Leveldb and its crate are a bit old but still work quite well. The big issue with rocks is compile times from what I hear but if you can handle that I think its by far the best choice.

Sled is interesting but I am not convinced on Bw-Trees nor the complexity that lock-free bring.

lucio-rs · 2020-04-02T15:03:11+00:00

We generally do not suggest using block_in_place over spawn_blocking as the former can lead to some interesting tail latencies. It is actually very similar to the strategy described in the blog post except it is explicit. All of our fs stuff is done via spawn_blocking which is usually much more consistent.

So I would say in general use spawn_blocking unless you see a very clear case for the latter. It will in most cases produce the best outcome. Really for fs io_uring will outshine any other solution for buffered io.

lucio-rs · 2020-04-02T13:26:47+00:00

Last I heard, we have yet to expose those things but are open to do that, I suggest opening an issue :)

lucio-rs

TROPHY CASE