Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

RESTful backend and socket.io to sync

Today, i had the idea of the following setup. Create a nodejs server along with express and socket.io. With express, i would create a RESTful API, which is connected to a mongo. BackboneJS or similar would connect the client to that REST API.
Now every time the mongodb(ie the data in it iam interested in) changes, socket.io would fire an event to the client, which would carry a courser to the data which has changed. The client then would trigger the appropriate AJAX requests to the REST to get the new data, where it needs it.

So, the socket.io connection would behave like a synchronize trigger. It would be there for the entire visit and could also manage sessions that way. All the payload would be send over http.

Pros:

  • REST API for use with other clients than web
  • Auth could be done entirely over socket.io. Only sending token along with REST requests.
  • Use the benefits of REST.
  • Would also play nicely with pub/sub service like Redis'

Cons:

  • Greater overhead, than using pure socket.io.

What do you think, are there any great disadvantages i did not think of?

like image 226
bijan Avatar asked Jul 17 '12 22:07

bijan


People also ask

Can you use WebSockets with REST API?

REST is the most commonly used architecture for developing APIs in recent years. It supports a half-duplex data transmission between the client and server. In the case of full-duplex data transmission, WebSockets are used.

Should I use WebSockets or REST API?

Whether you chose REST or WebSocket, one thing is certain your application will be able to communicate properly with other apps/software. You need to pick one based on your communication requirements and expectations. REST is far advanced and secured while WebSocket depends on lower-level components.

Can a Socket.IO and express on same port?

On Scalingo, your application must listen to the port defined in the PORT environment variable dynamically defined by the platform.


2 Answers

I agree with @CharlieKey, you should send the updated data rather than re-requesting.

This is exactly what Tower is doing:

  • save some data: https://github.com/viatropos/tower/blob/development/src/tower/model/persistence.coffee#L77
  • insert into mongodb (cursor is a query/persistence abstraction): https://github.com/viatropos/tower/blob/development/src/tower/model/cursor/persistence.coffee#L29
  • notify sockets: https://github.com/viatropos/tower/blob/development/src/tower/model/cursor/persistence.coffee#L68
  • emit updated records to client: https://github.com/viatropos/tower/blob/development/src/tower/server/net/connection.coffee#L62

The disadvantage of using sockets as a trigger to re-request with Ajax is that every connected client will have to fetch the data, so if 100 people are on your site there's going to be 100 HTTP requests every time data changes - where you could just reuse the socket connections.

like image 80
Lance Avatar answered Oct 14 '22 19:10

Lance


I think that pushing the updated data with the socket.io event would be better than re-requesting the lastest. Even better you could only push the modified pieces of data decreasing the amount of data sent over the line. Overall though a interesting idea.

like image 21
Charlie Key Avatar answered Oct 14 '22 17:10

Charlie Key