Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature?]: Websocket for SolidStart/SolidJS, instead of fetch #1561

Closed
2 tasks done
ile opened this issue Jun 27, 2024 · 2 comments
Closed
2 tasks done

[Feature?]: Websocket for SolidStart/SolidJS, instead of fetch #1561

ile opened this issue Jun 27, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@ile
Copy link

ile commented Jun 27, 2024

Duplicates

  • I have searched the existing issues

Latest version

  • I have tested the latest version

Summary 💡

I did search for issues, but I'm not sure if this is possible already or not.

Looking at the Network tab in Development Tools in the production/development build of a SolidStart, it seems that the calls to the server are fetch calls (to the /_server).

I think there would be performance gains to be had here if this was done with websockets. I.e. open the connection when the first request is made and use that with every page change. When the page changes are client-side, it should be possible to use websockets.

Motivation 🔦

  • Connection always open
  • HTTP request overhead will not exist
@ile ile added the enhancement New feature or request label Jun 27, 2024
@lxsmnsyc
Copy link
Member

lxsmnsyc commented Jun 28, 2024

It is the contrary actually, and not all web services has built-in websockets support. There isn't really any benefit on switching towards it, in fact, fetch provides more pros than cons.

open the connection when the first request is made and use that with every page change

fun fact: this is what http/2 solves

@ile
Copy link
Author

ile commented Jun 29, 2024

I did some tests (https://github.com/ile/fetch-ws-test) to a server located in the same country.

Running 100 requests for each method, 2 times...

Run 1:
HTTP Fetch with Keep-Alive:
Average: 18.980 ms
Min: 17.000 ms
Max: 35.000 ms

HTTP Fetch without Keep-Alive:
Average: 33.530 ms
Min: 19.000 ms
Max: 38.000 ms

WebSocket:
Average: 14.640 ms
Min: 14.000 ms
Max: 16.000 ms


Run 2:
HTTP Fetch with Keep-Alive:
Average: 19.030 ms
Min: 17.000 ms
Max: 38.000 ms

HTTP Fetch without Keep-Alive:
Average: 33.160 ms
Min: 19.000 ms
Max: 38.000 ms

WebSocket:
Average: 14.700 ms
Min: 13.000 ms
Max: 17.000 ms


Average Results Across All Runs:
keepAlive:
Average: 19.005 ms
Min: 17.000 ms
Max: 38.000 ms

noKeepAlive:
Average: 33.345 ms
Min: 19.000 ms
Max: 38.000 ms

webSocket:
Average: 14.670 ms
Min: 13.000 ms
Max: 17.000 ms

It's not a huge difference between keep-alive fetch and websocket. Not totally without a difference.

fun fact: this is what http/2 solves

I know that "fun fact", but at least before the fetch keep-alive was unreliable in Firefox. https://stackoverflow.com/questions/67754620/fetch-keep-alive-is-not-working-as-expected

@ile ile closed this as completed Oct 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants