Socket IO integration

[JeffreyArts]

I wanted to discuss this plugin I've made for Payload2 over here, before I'd publish it to NPM. Reason for this is that integrating the functionality of socketIO with a CMS like Payload is a very opinionated process, so I rather hear some other points of view before I would publish it as "payload-plugin-socket-io". Because if done in a way that it is too opinionated would harm the payload community more that it'd benefit it. In particular I'd like invite you to have a look at certain design patterns that I have utilized, I've made a special commit that allows you to make comments within the plugin code, so I would suggest that whenever you have feedback on the architecture, to give it over there.

The two features that this SocketIO integration utilizes

1. It allows the developer to emit socket events whenever they interact with a collection. In short, it utilizes the afterOperation hook to emit different types of events (public, self and/or to a room). The configuration for it is done via the config.custom.socketAccess object. This takes one or more of these options: create, find, findByID, update, updateByID, delete, deleteByID, login, refresh & forgotPassword, which return an object to specify the type of event to be emitted. Below you'll see an example of how it could be used, it would also accept an object instead of a function to specify if an event should be emit to public, self or a room.

custom: {
        socketAccess: {
            create: (args, req, result) => {
                // Return false to disallow emit
                // Return {public: boolean | Object<result>}
                // Return {self: boolean | Object<result>}
                // Return {<room>: boolean | Object<result>}
                
                const data = {
                    id: result.id,
                    createdAt: result.createdAt,
                    updatedAt: result.updatedAt,
                    text: result.text,
                    user: {
                        id: result.user.id,
                        username: result.user.username
                    }
                }
            },
        } 
    },

2. Allow for socketIO "listeners" on the server
   Whenever a connection is being established the plugin connects the socket with a session object via express-session. This is automatically handled by the plug-in, but by providing the developer to append their own methods in this section of the application, it allows them to create listeners for emit events, fired from the client. For this you'll create a method like this:

const customRoutes = (socket: Socket) => {
    socket.on("manual-room-switch", data => {
        // Should contain logic for validating the input, causes this method allows anyone to join any room which is a security hazard, but for demo-purpose it is okay.
        if (data?.enter) {
            socket.join(data.enter)
        }
        if (data?.leave) {
            socket.leave(data.leave)
        }
        console.log(socket.rooms)
    })
}

That can be passed down into the plugin via the onConnection attribute. This options accepts either an array of methods, or just a single one. Other options are "enabled", to enable or disable the plugin. And "dev".... Setting this to true will console log emit events to communicate to the developer what events are fired. Which will be useful during development, for figuring out where in the pipeline an event isn't successfully handled.

I'm also not yet entirely certain if I'm happy with the way that the importing of express-session & socket-io happens outside of the plug-in. But than again, as a developer whom would like to include socketIO in my project, I prefer to have control over the native packages, than creating a pattern that would require me to pass express-session & socket-io configurations via the plug-in options. It might have some benefits regarding for quickly get it up-and-running by pre-filling certain values. But than I'd be black-boxing a part of the DX, which I rather not do.

Since this implementation is very different from the Websockets implementation that they'd like to develop for version 3.0 (see below), I thought that sharing this plugin here would be a good idea to give some inspiration to the team of what alternative features could be valuable. Whatever the decisions are going to be for the WebSocket API,i t would be a pity if that would disallow for an extension as this one. Cause of a collision between socketIO and websockets (I don't know if that will be the case, but I'm bringing it up the table just in case 😉.

WebSocket API: To enable real-time communication, and open the door to future features like multiplayer editing. We’re aiming to build in a very isolated, compartmentalized way, similar to how we built database adapters, where you can install it and it will just work. And this is going to open up the door for real-time communication between Payload and your frontend