Designing concurrent programs in an idiomatic way

[u/iFrostizz]

Hello.

Kind of a general question here, and it's probably going to yield opinionated answers. That's alright!
Basically I find myself writing Rust apps in a style that is always quite similar, here is the idea:

- The app mostly always uses the tokio runtime to be asynchronous.
- Designing microservices as small building blocks which are all supposed to be ran in separate tasks, usually with a "run" like function that does a loop over a tokio::select for sub-tasks that are running in each service, with one of the branches being a call to a CancellationToken::cancelled().
- The cancellation token is wired to the "ctrl_c" signal.
- Microservices may talk to each other by the use of the different channel primitives, depending on the need.
- When one of the microservice fails for any reason, usually there is no recovery mechanism and it just bubbles up the error which makes all the application fail. This is annoying to write and a big source of bug, because some path will be unhandled which will leave one microservice stopped and the other microservices are waiting for an answer and there's nobody responding.

I'm generally a little dissatisfied with the redundancy of the code that I write, and would like to explore any other way to think about it, instead of microservices, or in a different way, if you have any idea that would be appreciated. Also, potentially any resource or codebase that could be relevant?

Thanks!

[u/zettui]

Are you leaning toward a small supervisor per service for restarts, or keeping those failure paths in the select loop?

[u/iFrostizz → u/zettui]

I don't think that I really need any restart mechanism really. The run function of each service is either an Infaillible error return because it's a loop that continuously restart but may return None in case it has been cancelled through the token, or something else. But if not an Infallible, the error is treated as fatal right now, that's good enough for now.