Streamed SSR Response

[futursolo]

Description

This pull request consists of the following changes:

Yew Runtime

Introduces a single-threaded Runtime to bridge between Send and non-Send futures.

This runtime pins the rendering task to one of the thread in the internal rendering pool.
Pinning a future to a single thread is better than making them Send when it comes to processing web requests as they are usually shortly lived and io-bounded (e.g.: waiting for DB / API connection), resolving them on a single thread eliminates the overhead of sending the tasks between threads.
(See: https://docs.rs/actix-rt/latest/actix_rt/index.html)

1. Makes yew::platform (previously yew::io_coop) public.
   This exposes a spawn_local that always works with the current runtime used by ServerRenderer.
2. Adds yew::platform::run_pinned to run a future pinned on to a single thread.
3. Async Functions on ServerRenderer are now Send.
   • ServerRenderer renders with run_pinned by default.
4. Added a non-Send version of Renderer: LocalServerRenderer.
5. tokio or wasm-bindgen-futures runtime is required.

With this change:

• The ServerRenderer becomes runtime-independent (can be awaited in an async-std runtime) as it brings its own runtime.
• Futures on the ServerRenderer are now Send and can be polled from web servers that requires Send futures (warp / axum).

Streamed Server-side Rendering

1. Streams Server-side rendering Response to the client side as they are rendered.

Other

1. MSRV is updated to 1.60.

Checklist

• I have reviewed my own code
• I have added tests

[github-actions]

Visit the preview URL for this PR (updated for commit d4b15f6):

https://yew-rs-api--pr2697-platform-6j632oka.web.app

_{(expires Sun, 29 May 2022 16:43:19 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

[github-actions]

Size Comparison

examples	master (KB)	pull request (KB)	diff (KB)	diff (%)
boids	172.935	172.938	+0.004	+0.002%
contexts	109.814	109.815	+0.001	+0.001%
counter	86.896	86.894	-0.003	-0.003%
counter_functional	87.552	87.549	-0.003	-0.003%
dyn_create_destroy_apps	90.009	90.007	-0.002	-0.002%
file_upload	103.011	103.010	-0.001	-0.001%
function_memory_game	167.299	167.300	+0.001	+0.001%
function_router	352.482	352.402	-0.080	-0.023%
function_todomvc	161.981	161.973	-0.009	-0.005%
futures	225.774	225.773	-0.001	-0.000%
game_of_life	107.561	107.532	-0.028	-0.026%
immutable	208.688	208.697	+0.009	+0.004%
inner_html	83.958	83.956	-0.002	-0.002%
js_callback	113.045	113.048	+0.003	+0.003%
keyed_list	195.531	195.538	+0.007	+0.003%
mount_point	86.529	86.529	0	0.000%
nested_list	115.953	115.953	0	0.000%
node_refs	93.958	93.958	0	0.000%
password_strength	1538.663	1538.665	+0.002	+0.000%
portals	97.553	97.550	-0.003	-0.003%
router	321.299	321.199	-0.100	-0.031%
simple_ssr	154.684	154.625	-0.059	-0.038%
ssr_router	398.561	398.469	-0.092	-0.023%
suspense	110.688	110.675	-0.014	-0.012%
timer	89.582	89.582	0	0.000%
todomvc	143.035	143.036	+0.001	+0.001%
two_apps	87.543	87.543	0	0.000%
web_worker_fib	153.946	153.954	+0.008	+0.005%
webgl	87.779	87.774	-0.005	-0.006%

✅ None of the examples has changed their size significantly.

[futursolo]

The MSRV has been updated to 1.60 due to the requirement of namespaced dependency.

[hamza1311]

Looks good to me! This will be a great improvement

[futursolo]

The benchmark workflow failure is not related.

[WorldSEnder]

A few things in the custom BufWriter implementation that I didn't notice the first time around, other than that, looks mostly good to me (from an API perspective).

[WorldSEnder]

For build times it might still be best to get rid of the tokio dependency in the long run, but I don't view this as blocking (since I have yet to measure the difference anyway). We could also add build times to the performance benchmarking step, I think it'd be a good metric to have.

[hamza1311]

Looks good. Thanks for all the work you put in