shuttle icon indicating copy to clipboard operation
shuttle copied to clipboard

[Improvement]: Allow other async runtimes than tokio, such as async-std

Open A248 opened this issue 1 year ago • 1 comments

Describe the improvement

Allow users to rely on async-std or other runtimes. The user should control the creation of the async runtime for maximal flexibility. The current behavior of forcing Tokio is inefficient for applications which do not want it.

At present, using #[shuttle_runtime::main] expands to include, among other things, #[tokio::main]. This forces the use of Tokio even where the application wants another async runtime, such as async-std. It means that every application must at least spin up a Tokio runtime. This introduces unnecessary bloat, increasing infrastructure costs.

Some applications may want a different runtime such as async-std or smol. Although shuttle is mainly used for web applications, I imagine that some kinds of non-web applications might reasonably not use async at all, or very minimally, such as via pollster.

Tokio is sprinkled throughout this repository and the documentation, which may present a challenge. For example, the shared-db module with PostgreSQL depends on sqlx with the Tokio feature flag; the hardcoded dependency is a blocker for using async-std with sqlx and postgres.

Duplicate declaration

  • [X] I have searched the issues and this improvement has not been requested before.

A248 avatar Oct 23 '23 12:10 A248

I think the main challenge/blocker is that the Shuttle runtime wraps the app with a tonic server, and using that without tokio looks cumbersome at best. Based on this, I don't think we will be able to support other runtimes until we do a redesign with that in mind, but thanks for the good suggestion! Edit: congrats on issue 1337 :)

jonaro00 avatar Oct 23 '23 18:10 jonaro00