Server overloaded with CRUD requests?

[Shawn Lim]

Hello, I'm new to backbone.io.
I was looking at the docs and a pressing question pop up: Will using backbone.io overload the server (database) with CRUD?

As I know, whenever a user on the frontend does something to CRUD a model, the socket transport is used and the backend socket.io updates all connected sockets on the change. Does the backend ALSO sends a bunch of calls to the database to update the database of the changes?

Now what if 10 users are updating models on the front end. The backend receives a lot of requests to update all connected sockets of the change, AS WELL AS send database calls to update server information?

One perfect example would be a notice board with sticky notes. Each note is a model that contain a title and description, and it can be moved around / deleted / updated / created.

=> When a user moves a sticky note, hundreds of socket.emit are called to the backend. The backend responds by updating all other connected sockets. Does the backend also send hundreds of requests to the database to update the position of the sticky note?

It seems this way the database would explode from so much CRUD action.

How could I design a solution for this using backbone.io? Enlighten me pls.

[Andrei Sebastian Cîmpean]

Hello!

I used backbone.io on a project that would also generate a lot of "noise" and be ineffective because it required a lot of communication if used like this.
In the end I changed the plugin like this:

• most of the plugin would remain like this, but instead of connecting to socket.io, I used PubSub channels built in the same way as in the plugin
• I moved the connection part in a separate logic and when a message is received, I construct the channel id in the same way as socket.io and PubSub publish the data on that

.I didn't have a chance yet to upload the modified version.

[Shawn Lim]

hey @andreisebastianc I don't really understand what do you mean. Do you have a sample repository for me to take a look?

[Andrei Sebastian Cîmpean]

@geekyme check out https://gist.github.com/andreisebastianc/5199453

[Scott Nelson]

You're free to build the backend however you'd like- it doesn't necessarily need to save anything in a database. Backends are only responsible for handling sync requests and responding to them. Your sticky node backend could keep data in memory and have some other mechanism to periodically serialize the state to a database if need be.

[Shawn Lim]

thanks @andreisebastianc . Hey @scttnlsn, yeah I thought so too. I built something in socket.io before to sync models across screens. However my backend socket server don't save to my database like you mention.

Just curious, how would you implement such a mechanism to periodically save the state to a DB?

[Scott Nelson]

@geekyme The simplest solution would be to have your backend manipulate an in-memory data structure. You could then just periodically write it out to disk:

setInterval(function () {
    db.save(data, function (err) {
        if (err) log(err);
    });
}, 60000);

A more robust solution might be using something like Redis. Store your backend's data in Redis and then use Redis snapshotting to periodically persist the data to disk.