This should wrap up our connection handler issue #6 . I implemented the disconnect event handler and then modified the frontend connection testing component. The component should now display two buttons connect and disconnect. This is just meant to be a basic live example of connecting and disconnecting on the client side (make sure backend is running).
Here's a breakdown of all the requirements for issue #6 that I've implemented in past PR's:
WebSocket Integration
Configuration setup in app.py creates a single SocketIO instance, that all clients (users) will be able to connect and disconnect to. The instance is global because we don't want to create a new instance for every connection made. Here's why...
One of the primary functionalities of SocketIO is to broadcast messages to multiple clients. If you create a new instance of Socket.IO for each connection, each instance would be unaware of the other instances. This means you wouldn't be able to broadcast a message to all users. You'd essentially isolate each user in their own Socket.IO instance. Along with creating major overhead and wasted resources.
With this in place we have websocket functionality efficiently integrated into our backend infra.
WebSocket Endpoint
Set up configuration to register all websockets. SocketIO has event listeners that uses websockets under the hood which is the crux of our real-time communication requirement. /events folder is where all our listeners will live and be handled (endpoints).
Connection Pool Management
The current configuration of our SocketIO instance will allow us to accept and manage all users concurrently. If the future shows our product will need scaling, implementing more servers and SocketIO instances would be implemented. SocketIO has an adapter feature that would allow us to set up communications between these additional servers and their instances.
Error Handling
I've added error handeling to our Websocket integration process and our SocketIO event listeners.
Broadcasting Updates
The single SocketIO instance hosted on our server will allow broadcasting to all users connected at once.
Performance Optimization
We've structured our backend to be able to initialize and register all our api and event handler files along with their imports seamlessly during server configuration. Our SocketIO configuration is set to give us more control on our optimization and further improvements on this will be based on our needs and system design for managing our connected users.
Logging and Monitoring
Logging has been configured into our app and can be used throughout all of our backend infra. The connection event handlers have basic logging and error handling in place along with some of our config processes.
This should wrap up our connection handler issue #6 . I implemented the disconnect event handler and then modified the frontend connection testing component. The component should now display two buttons
connect
anddisconnect
. This is just meant to be a basic live example of connecting and disconnecting on the client side (make sure backend is running).Here's a breakdown of all the requirements for issue #6 that I've implemented in past PR's:
WebSocket Integration
Configuration setup in app.py creates a single SocketIO instance, that all clients (users) will be able to connect and disconnect to. The instance is global because we don't want to create a new instance for every connection made. Here's why...
One of the primary functionalities of SocketIO is to broadcast messages to multiple clients. If you create a new instance of Socket.IO for each connection, each instance would be unaware of the other instances. This means you wouldn't be able to broadcast a message to all users. You'd essentially isolate each user in their own Socket.IO instance. Along with creating major overhead and wasted resources.
With this in place we have websocket functionality efficiently integrated into our backend infra.
WebSocket Endpoint
Set up configuration to register all websockets. SocketIO has event listeners that uses websockets under the hood which is the crux of our real-time communication requirement.
/events
folder is where all our listeners will live and be handled (endpoints).Connection Pool Management
The current configuration of our SocketIO instance will allow us to accept and manage all users concurrently. If the future shows our product will need scaling, implementing more servers and SocketIO instances would be implemented. SocketIO has an adapter feature that would allow us to set up communications between these additional servers and their instances.
Error Handling
I've added error handeling to our Websocket integration process and our SocketIO event listeners.
Broadcasting Updates
The single SocketIO instance hosted on our server will allow broadcasting to all users connected at once.
Performance Optimization
We've structured our backend to be able to initialize and register all our api and event handler files along with their imports seamlessly during server configuration. Our SocketIO configuration is set to give us more control on our optimization and further improvements on this will be based on our needs and system design for managing our connected users.
Logging and Monitoring
Logging has been configured into our app and can be used throughout all of our backend infra. The connection event handlers have basic logging and error handling in place along with some of our config processes.