Question

I am currently working on a project which has to use WebSockets as a way of transferring data to my client. The infrastructure looks like this.
Client –> Web Server –> Microsoft SQL Database

I think that the most ideal situation would be like this:
Client opens a socket to the Server.
Server opens a socket to the Microsoft SQL Database.
Whenever the database is updated (some data has been inserted) the DB writes the data to the socket.
The server writes the data back to the client.
This might be a bit tedious though, maybe I can somehow open a socket to the DB from the client directly?

I want to know if there is a way to automatically notify the socket to the web server if the MSSQL database is updated, so that it can process that information.

The main question is really; how will I make this work? I’ve looked into some projects which work with WebSockets like Node.JS and Socket.IO, also Tornado. Although I haven’t found any clues as to where to look for this specific feature. I have found some rather unstable drivers for the MSSQL databases for NodeJS but do not understand if there is any way to make a socket to the DB and instantly send the data through the socket when it’s pumped into the database.

I also realise that making a socket between client and db wouldn’t be smart to say the least security wise, as for now that’s not an issue, and that SQL is not the way to go for realtime applications but I’m bound to it for now 🙂

Edit 1:

Thanks to @tomfanning I now know of a solution to this problem but seriously doubt the improvement in performance. Let me picture the situation for you. In the case that I would use the Trigger on the MSSQL database I imagine this happening.

Situation 1

1. The database gets updated
2. The trigger is pulled
3. The CLR script makes a connection to the Web Server. Either through
   a socket which it has to open and close for every trigger or through
   a HTTP(S) request which involves opening and closing a Header (which
   is useless overhead)
4. The Web Server receives the trigger and emits the data to the
   client.
5. The client updates.

And now imagine the same scenario but then with AJAX

Situation 2:

1. A timeout of 1000ms is set in the client for AJAX requests
2. The client time’s out and makes an AJAX request
3. The database executes some query and posts back the result
4. The client updates.

In situation 1 you need both a request and a socket emit/receive and in situation 2 you would only need one request. If I were to set the timeout of the AJAX request to 10MS would it appear to the user as if it were a realtime application like a websocket? Or would situation 1 still be more efficient and I’m just exaggerating?

Thanks in advance!

Answer 1

Possible solution might be T-SQL triggers on INSERT or UPDATE with a CLR procedure which sends some notification to your main application, which then pumps data out to your client via websockets. Would avoid needing to poll the database.

Per your comment – not sure how AJAX would help you specifically in this case – because being a technology driven from the client (browser), your solution would again be polling, which I understand you want to avoid. WebSockets sounds like the right fit here because it gives you the ability to do true “push” from the server to the client without requiring a poll.

Obviously I’m talking in very general and theoretical terms here.