DEV Community

Hong duc
Hong duc

Posted on

request-response pattern with socket.io, Am I using anti pattern ?

Hello, I am building a chat app using socket.io. But something hit me.
Right now, I am re-implementing the request-response pattern with socket.io, because every time client send a message, I need to know whether the message is sent or not or timeout. But doing this I thought why not use http to send message ? But I remember that I want to avoid request overhead.

Am I using anti pattern here ? Am I doing thing the wrong way ?
Thank you

Top comments (5)

Collapse
 
smartcodinghub profile image
Oscar

I did hit similar issues with a chat (an example to explore) using SignalR Core. At least, with this abstraction, you can respond when you get a message. I used this for validations like the user doesn't exist, invalid words and things like that. Using this, you can know if the message reached the server, but no if it was delivered to the target user (Although you can know it).

But I think that the first purpose of web sockets is to keep only a connection open with the server and avoid all the overhead (Headers, Cookies, etc...). Using this, with a request-response pattern, doesn't seem necessarily wrong to me if it fits your needs.

Collapse
 
kelerchian profile image
Alan

Am I using anti-pattern here?

No, you're not.
amqp.org/ protocol uses a similar pattern. It is an alternative to HTTP as a method of server-to-server communication and has been adopted by message brokers such as rabbitmq.com/.

You might want to pull some inspiration from it.

Collapse
 
vbarzana profile image
Victor A. Barzana • Edited

Oh crap, I know what you mean, just going through it now, I found this library npmjs.com/package/socket.io-request but it is not touched since 2018, let me know if you find a better solution, otherwise we have to come up with something. I remember back in the day when we were implementing jWebSocket framework, RIP, we had set up a very nice request/response mechanism by introducing to every request a requestId autogenerated id and matching every message on the client back to this requestId on the client for every message, this could be a lot of overhead, but would allow you to add any kind of callback hell or promises on the response which was way more intuitive.

Collapse
 
vbarzana profile image
Victor A. Barzana

Ah, nope, ignore this library npmjs.com/package/socket.io-request they don't have a proper r/r mechanism there, not recommended.

Collapse
 
marvelouswololo profile image
MarvelousWololo

could you share a snippet of your code showing us the problem?