[FEATURE]Use WebSocket

[zyxgad]

I suggest bluemap use WebSocket to get data, that will reduce many unnecessary web request. Of course, bluemap need keep http API to compatible with the old client

[roobscoob]

If this is to be implemented, please keep the HTTP fetch option as a persistent choice. (i.e. don't deprecate/remove it). When deploying BlueMap at scale (for example, as an interactive component displaying a static world on a website) HTTP fetches are much better, as tools exist to optimize the delivery of static content over HTTP. These same tools do not exist for WebSockets

[FinlayDaG33k]

Do note that if websockets are going to be used, we'd also need to implement RFC 7692 in order to use some compression.

[TBlueF]

There is currently no intend to use web-sockets for the map-tiles .. in my opinion, http-requests are perfectly fine for that :)
The web-sockets would be for live-updates like player-markers

[mrsolarius]

Maybe instead of web socket, just use server side event ?

[TBlueF]

I will consider it, yes :)

[FinlayDaG33k]

With HTTP/3 becoming more common by the day, I'd say websockets wouldn't add much anymore.
The only thing I'd see websockets being useful for, is making things like player-locations be available in a more real-time fashion as mentioned in #244 (comment).

Pros

• HTTP/3 is built on QUIC/UDP, which eliminates head-of-line blocking and ack packets (server assumes arrival, client will request packets when they go missing).
• No need to do anything in the client front-end (the browser will handle it).
• It's still just HTTP, so compression and all those goodies will remain in-tact (so no need to do wonky stuff like I've mentioned in [FEATURE]Use WebSocket #244 (comment)).
• Clients that do not support HTTP/3 can still use HTTP/2 or even HTTP/1.1 as normal.
• Doesn't break setups that use a CDN (or something similar).

Cons

• TLS is a must (might be the biggest part of the challenge).
• HTTP/3 is technically still just a proposal (albeit it has pretty much stabilized).

I do not know how the internal webserver works from a code-perspective but I think the changes should be relatively minimal while still having a bigger impact than using websockets would have.