That may make this easier, but I don’t know VueJS wel enough to say. But that doesn’t fundamentally change the fact that these messages aren’t persisted on the server, nor is there, by default, any kind of shared state between the clients and the server.
Can you elaborate what you mean by that the messages aren’t persisted on the server or shared state between client/server?
Consider the “standard” or “archtypal” chat application, where you have “n” users establishing a websocket connection to a Daphne server.
When each user connects, an instance of the WebsocketConsumer class is created for them.
The consumer joins them to a “Group”, so that messages sent to the group are distributed to all the connected users.
When a user sends a message through the websocket to their consumer:
- The consumer receives the message
- It sends the message to the Group
- The Group sends the message to all “n” consumers joined to that Group
- Each of the “n” consumers that receive the message from the Group send the message out through the websocket to the browsers connected to them.
The consumers do not keep or store the message. Once a consumer has sent a message and the function exits, the consumer no longer has access to that message. (It does not continue to exist on the server.)
The consumer also does not keep track of what messages it has received or sent. (They do not persist on the server.)
The consumer also does not have any information about what data may be stored in the browser. Data can exist in the browser that doesn’t exist in the consumer, and vice versa. (There is no shared state between those environments.)
Now, this does not mean that that functionality can’t be provided - but that’s coding that you would need to do. If you want a consumer to track every message sent to or received from its connected consumer, you can do that - however, keep in mind that websockets themselves can be dropped and reestablished, causing a new consumer instance to be created, and losing track of whatever may have been previously stored.
Yeah they say websockets is unreliable, especially in production
It’s worse on mobile devices and wifi than on wired ethernet. (Our ethernet-based websockets are extremely stable and reliable.)
So from what you told me, from what I gathered. Consumers act kind of as an intermediary of messages sent between the client and the server.
You know, they’re like a pipe for data in the form of messages to travel through via websockets.
I know with the handshake model for TCP, a websocket connection can keep re-establishing a connection if one is lost, unlike with standard HTTP request/response.
Am I kind of on the right track here?
This isn’t correct. The consumer is the endpoint on the server of the websocket connection. The browser sends messages to the consumer.
If anything is to be done with the message on the server, it’s the consumer that is responsible for doing it.
I don’t think I’d word it this way. The JavaScript in the browser can detect when a websocket connection has been interrupted, and can establish a new connection.
This distinction is important because this new connection is going to be to a new instance of the consumer - you’re not “reconnecting” to the same consumer instance. This means that the channel_name associated with that consumer will be different, and any data stored solely in the consumer is lost.
Gotcha. Do you think it’s crucial to code or program the consumer to keep track of all messages sent from the browser?
In other words, configuring so that you can modify the messages in my consumers so that data is stored after being sent?
That’s a “business rule” decision and not a technical one.
In part, it’s going to depend upon whether the messages contain data of value and need or deserve to be saved.
For example, I’ve got a couple of SBCs that send sensor data through a websocket to a consumer that saves that data to a database for later analysis. Those messages all need to be saved.
On the other hand, I have a WebRTC implementation using Django Channels using the consumer as the connection point for the connection and negotiation process - there is absolutely no value is saving any of those messages. So the messages are routed to their appropriate destination and then “forgotten”.
Makes sense. My messaging platform is B2B between arborists and businesses/property managers for commercial services. So it will probably contain sensitive business data. In your honest opinion, is WebRTC better than websockets, at least for one-on-one messaging, peer-to-peer connection, scaling etc…?
This is another decision that probably depends as much upon business requirements and architectural requirements as it does technical issues.
The two aren’t equivalent and don’t provide the same functionality. Because of this, it might also not be a case of either/or, but one of both working together.
Yeah, I mean as I was going through the Channels docs, I understood Consumers as an application that consumes the message or as you put it, the endpoint for the messages sent