CODEWITHSUNDEEP
javascriptwebsocket
Hedge
Hedge

Reputation: 16748

Problems when synchronising objects via WebSockets?

I'd like to synchronise data between a browser client and server using ONLY WebSockets.

Currently most people use WebSockets only to notify the client that some data is available on the server.

After investigating the current state I found no good reasons why I wouldn't use WebSockets to synchronise the data directly.

Note: This is not a duplicate of disadvantages of websockets as I've got a specific use case in mind

Upvotes: 0

Views: 120

Answers (2)

vtortola
vtortola

Reputation: 35925

There is absolutely no technical problem in doing so. The problem is if you try to decouple writes and reads to move to a more scalable architecture like CQRS. Are websockets part of the reads or the writes? :)

My recomendation for regular apps is to use WebSockets to get updates, and to send queries about the read model like autocompletion inputs, searches, etc... But use a REST API to send actual data that needs to be persisted. But, if you application is highly interactive then you will never find yourself in a position of wanting to decouple reads and writes, so using WebSockets for all should be fine.

How to handle CQRS from a client-side perspective

WebSocket/REST: Client connections?

Upvotes: 1

Touffy
Touffy

Reputation: 6561

I've done that using SSE without any particular issue (just make sure you read data updates on a single channel, i.e. don't send a response payload with a REST call and the same payload over your persistent channel), and I think WebSockets should be even better. Can't imagine why it wouldn't work (as long as there's no old HTTP proxy screwing up WebSockets itself).

Upvotes: 1

Related Questions