shuttle-hq / shuttle

Build & ship backends without writing any infrastructure files.
https://shuttle.rs
Apache License 2.0
5.96k stars 247 forks source link

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

Open A248 opened 10 months ago

A248 commented 10 months ago

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

jonaro00 commented 10 months ago

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 :)