Native support for web sockets
We've been attempting to migrate our app from sapper to sveltekit and ran into the problem of web sockets, in sapper we could simply attach the WebSocket server directly to the express server and be done with it, but as per Rich Harris' comments [here](https://github.com/sveltejs/kit/issues/334#issuecomment-804987028) and here [here](https://github.com/sveltejs/kit/issues/334#issuecomment-806289525) in sveltekit we don't want to expose direct access to the middlwares thus promoting the node adapter over the serverless ones. However seeing as some of the serverless providers are starting to support web sockets ([cloudflare](https://blog.cloudflare.com/introducing-websockets-in-workers/)) ([begin](https://blog.begin.com/introducing-architect-5-0-fully-serverless-websockets-20bb97673c4e)) ([AWS Lambda](https://aws.amazon.com/blogs/compute/announcing-websocket-apis-in-amazon-api-gateway/)) should sveltekit provide a way to handle these connections directly? A native approach to this could also potentially provide a tool to solve this [issue](https://github.com/sveltejs/kit/issues/87) and [this](https://github.com/sveltejs/kit/issues/887) **Describe the solution you'd like** An interesting solution could be to expose functions in endpoints in the same way we handle http requests, and then let the adapters handle the rest ```routes/api/index.ts``` ```js // Handle post requests export const post: RequestHandler = async (request) => {....} // Handle web socket requests export co
Posted by AndreasHald on May 19, 2021, 9:23 AM
Tags
Related issues
- I hate that this whole cluster of beliefs exists, but software on my own computer enforcing what I can and can't do for ideological reaso...
- As I replied in another comment[1], it's their software, their choice.
- [Feature] Support external model integration via personal API keys and local LLMs (BYOK)
- > So when head of companies don’t care about quality, they’ll push hard no matter what to have speed.
- Feature request: support multiple named accounts per app/connector
- Support standalone Windows installer (`codex-setup.exe`)
Raise real-world problems, find people facing the same issue, and discuss solutions.3,000 issues0 comments
support (SaaS)
I hate that this whole cluster of beliefs exists, but software on my own computer enforcing what I can and can't do for ideological reaso...
NewAs I replied in another comment[1], it's their software, their choice.
[Feature] Support external model integration via personal API keys and local LLMs (BYOK)
> So when head of companies don’t care about quality, they’ll push hard no matter what to have speed.
Feature request: support multiple named accounts per app/connector
Support standalone Windows installer (`codex-setup.exe`)
[feature]: Move OIDC back to self-hosted OSS(Plane Free)
I was running about 1000 machines on VMware in my previous career.
Native support for web sockets
We've been attempting to migrate our app from sapper to sveltekit and ran into the problem of web sockets, in sapper we could simply attach the WebSocket server directly to the express server and be done with it, but as per Rich Harris' comments [here](https://github.com/sveltejs/kit/issues/334#issuecomment-804987028) and here [here](https://github.com/sveltejs/kit/issues/334#issuecomment-806289525) in sveltekit we don't want to expose direct access to the middlwares thus promoting the node adapter over the serverless ones. However seeing as some of the serverless providers are starting to support web sockets ([cloudflare](https://blog.cloudflare.com/introducing-websockets-in-workers/)) ([begin](https://blog.begin.com/introducing-architect-5-0-fully-serverless-websockets-20bb97673c4e)) ([AWS Lambda](https://aws.amazon.com/blogs/compute/announcing-websocket-apis-in-amazon-api-gateway/)) should sveltekit provide a way to handle these connections directly? A native approach to this could also potentially provide a tool to solve this [issue](https://github.com/sveltejs/kit/issues/87) and [this](https://github.com/sveltejs/kit/issues/887) **Describe the solution you'd like** An interesting solution could be to expose functions in endpoints in the same way we handle http requests, and then let the adapters handle the rest ```routes/api/index.ts``` ```js // Handle post requests export const post: RequestHandler = async (request) => {....} // Handle web socket requests export co
Comments (0)
No comments yet. Start the discussion.