Fly Labs
Ask FlyBot

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 const ws: WebSocketRequestHandler = async (request) => {....} ``` A concern with this approach could be mixing protocols, within an endpoint could be confusing. Another could be if this becomes too complicated since as far as I know the initial [handshake](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake) to start a WebSocket connection is handled over http, would this then be handled directly by sveltekit which cou

GitHubToolOtherSource
0Sign in to voteCopy link

FL score

52

out of 100

Verdict

VALIDATE

high confidence

Competition

11

competitors found, nascent market, funded players

Trend

8 community mentions

A SvelteKit-native WebSocket integration via endpoint functions, addressing developer frustration with existing workarounds, but facing direct competition from SvelteKit's own impending solution.

The pain

SvelteKit developers face significant frustration and complexity integrating WebSockets, especially when migrating from Sapper or using serverless environments. Current workarounds are cumbersome and not seamless.

The gap

The gap is for a truly native, idiomatic SvelteKit WebSocket API that works consistently across various adapters, particularly serverless. Existing solutions are mostly external libraries, manual setups, or broad real-time platforms, not integrated framework features.

Build angle

Develop a plug-and-play SvelteKit solution for native WebSocket handling through endpoint functions, focusing on seamless integration across different adapters, particularly serverless (Cloudflare Workers, etc.).

Strengths

  • Real, specific, and urgent pain point for SvelteKit developers.
  • Clear demand for better WebSocket integration, especially in serverless.
  • Growing trend towards real-time applications and SvelteKit adoption.
  • Proposed solution (endpoint functions) is intuitive and SvelteKit-idiomatic.

Risks

  • SvelteKit is actively developing native WebSocket support, potentially making a third-party product obsolete or redundant.
  • Low willingness to pay for a core framework feature; users expect it to be free or included.
  • High build complexity for a solo builder to create a robust, cross-adapter solution.
  • Difficult to establish a defensible moat or pricing power against the framework itself.
  • Monetization strategy is unclear and likely challenging for a dedicated product.

Next steps

  1. Deeply research the progress of SvelteKit's native WebSocket support (beyond 'testing versions available') to understand its scope, timeline, and capabilities.
  2. Engage directly with SvelteKit developers experiencing this pain to validate their specific needs and, crucially, their willingness to pay for a *third-party* solution (even a highly polished one) if SvelteKit's native solution lands.
  3. Consider contributing to SvelteKit's official efforts if the goal is to solve the problem, rather than create a separate product.
  4. If pursuing a product, identify an extremely narrow, unserved niche or specific problem *within* WebSocket integration that SvelteKit's native solution will *not* address (e.g., a specific advanced security feature, a unique serverless runtime's edge case that no one else is handling).

Questions about this idea?

FlyBot reads the scoring and gives you a second opinion on “Native support for web sockets”.

Open FlyBot