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
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).
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.
