You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the missing features holding me back from SvelteKit as opposed to Next.js is the ability to have an endpoint that acts as a text/event-stream also known as an EventSource. However, SvelteKit has a very appealing endpoint design, and it would be great to have it support Event Streams.
It would be great to have this support baked in to SvelteKit, and one design that I believe is appealing is to return a body in the endpoint that is an async generator function. SvelteKit can instantiate that as an async generator and consume the iterator until it has exited, or the client has disconnect, which ever comes first.
I believe the adapter design for SvelteKit does cause a problem in that this feature is only available where long running request processing can be enabled. There are a few caveats with load balancers and serverless that will cause problems keeping the EventSource open. Yet, this proposal doesn't require SvelteKit to be involved in processing the event stream, and all the client-side retry logic will work flawlessly.
Heavily related to #1563. Do you think we should close this and talk about it there since it's another side of the same coin (from my inexperienced perspective)?
Uh oh!
There was an error while loading. Please reload this page.
One of the missing features holding me back from SvelteKit as opposed to Next.js is the ability to have an endpoint that acts as a
text/event-stream
also known as an EventSource. However, SvelteKit has a very appealing endpoint design, and it would be great to have it support Event Streams.It would be great to have this support baked in to SvelteKit, and one design that I believe is appealing is to return a body in the endpoint that is an async generator function. SvelteKit can instantiate that as an async generator and consume the iterator until it has exited, or the client has disconnect, which ever comes first.
I believe the adapter design for SvelteKit does cause a problem in that this feature is only available where long running request processing can be enabled. There are a few caveats with load balancers and serverless that will cause problems keeping the EventSource open. Yet, this proposal doesn't require SvelteKit to be involved in processing the event stream, and all the client-side retry logic will work flawlessly.
Please see a proposed experimental branch here:
https://github.com/sveltejs/kit/compare/master...kjmph:feature/event-source?expand=1
Here is a potential
es.json.ts
file that demonstrates the design:This can be called like so via
es.svelte
:This can be dropped in place in the
src/routes/
directory vianpm init svelte@next my-app
The text was updated successfully, but these errors were encountered: