Some thoughts

Up until this point, I’ve been using the traditional means of creating an application on the web.

That being the utilization of the HTTP protocol and using either Ajax or standard means to transmit data to the server.

I have been considering an alternative which would enable me to:

1. Transmit data in realtime, with little to no latency between your peer and the server
2. Have the ability to transmit data from client to client, with a relay sitting in between for secret messaging without exposing IP addresses to the peers and without exposing any data to us, except encrypted and rather useless data.
3. Reduce loading times by at least a hundred times from what I currently have
4. Follow a more traditional means of application development

Naturally, my eyes went to WebSockets. It would follow a similar strategy as the one used for T-Bot Rewritten. The thing is, I’d have to implement these things too:

1. A room system, allowing me to only emit packets to those within scope
2. A session handler, purely just for connections
3. A ping-pong system to ensure that we are not talking to a dead link for too long - connections will die

Why would I need to bother with any of that, if all of this has already been solved? Enter: socket.io

socket.io

All the things that I had mentioned above are already solved here. Its usage would be similar as using Express and almost everything that I do in Express can be done with socket.io as well.

In all, this is my next choice. This is the step I am taking for all my future personal projects. It would allow me to develop things that were once either incredibly hard or impossible to implement without adding another networking layer on top of what I already had, which I am naturally against. It’s either one, but never extend one to two. You don’t want to repeat yourself.

Handling of sessions

Historically, I’ve always been writing my own session handlers for full control. Really, I don’t have to. I can just utilise express-session along with connect-redis to have the exact same functionality, but overwrite the method that is used to generate session IDs so that all sessions can easily be retrieved for users, voiding the need to even have a session store at all. This sounds like the right approach.

You might think that I’d need to use Express to use the express-session component. I understand you might think so, but that’s totally and completely wrong. I’d just have to slightly modify it so that it no longer uses cookies and that’ll be that!

Goodbye cookies

Since sessions will no longer be using cookies, I will no longer have to have any cookies in the next thing I build. This will void the need for a lot of hassle on the legal end and best of all, we would not need a cookie banner telling users that we have cookies like 99% of other platforms on planet Earth which is in my opinion, a tad annoying.

Session tokens will then be stored in LocalStorage, ready to be transmitted over the link once a connection is created to the remote endpoint. A perfect solution, I’d say.

Handling denial of service attacks

If you create something, there will always be one to try to destroy it through any means possible. That is true for almost every single online project in existence, and I am certain that whatever I create will not be exempt from this rule. Traditionally, I’d only need to bother with limit_req to throttle the number of requests that can be made, but since that all data will now be sent over the socket, this no longer becomes possible.

The solution fortunately, is rather simple. Instead of relying on limit_req, implement a rate limit for actions such as creating an account, sending a message, etc - on the application level. Sure, you’d still need to open a connection, but we can easily limit that through nginx with little to no overhead.

Querying the data source

Up until now I’ve been manually writing SQL queries to query for data from the database. I wonder what’s been going through my head all this time. I’m going to be using an ORM that will make my life a lot easier going forward.

Closing words

These are only a few of my ideas that I’ll be using moving forward. I am posting this online to get feedback on these ideas and maybe create a better strategy although I do not expect much to change.

Thanks for reading!