An innovative way to replace AJAX and JSONP using socket.io

[Olivier Scherrer]

Hi,

I've explained the solution that I'm using in my real-time web applications to unify AJAX+JSONP+WebSockets into one single component, by using socket.io

The solution allows to fetch any kind of data from anywhere without worrying about cross-domain issues, using a unified transport that can work on the server and in the browser.

You can read it here: http://podefr.tumblr.com/

I can't find any drawback to this solution and I really feel like it makes socket.io even more awesome!

I would be happy to have some feedback from you and wonder if anyone has already seen/used anything similar?

Thanks,

Olivier

[Ricket]

Hi Olivier,

For the JSONP proxy, why add the intermediate server? Part of the beauty of JSONP is that you don't need an intermediate proxy. I would much prefer to let the user's browser do the grunt work, and not have to have a Node.js server running (or host my entire web site from Node.js) just to query some simple data from another location.

AJAX proxying has been done for years. Search for PHP AJAX proxy in Google and restrict the date to 5 years ago and you'll get numerous results. Heck, you could probably find a CGI AJAX proxy from 10 years ago, if XMLHttpRequest was even around back then.

In response to the MongoDB example, client-side database requests are a Really Bad Idea. Are you saying that you are enabling client-side JavaScript to pull records from the database? Have you considered the security implications of this?

-Richard

[Olivier Scherrer]

Hi Richard,

You're right about the fact that setting up a node.js for the sake of not doing JSONP and AJAX doesn't seem right. In the solution I'm presenting, I state that there's already a node.js server that serves data to an application, and in that case, it can be nice to use it in combination with socket.io to actually remove JSONP and AJAX calls.

Concerning the database, I agree that client-side database requests can be dangerous, but with this architecture the sensitive configuration (like auth) is still managed from the server side. The only data that transits through socket.io is the data that is displayed and the request params to identify it. Can you see any security issue?

Thanks,

Olivier

[Olivier Scherrer]

This is the direct url to the blog post: http://podefr.tumblr.com/post/22553968711/an-innovative-way-to-replace-ajax-and-jsonp-using, it's missing from the first topic

[Ricket]

Hi Olivier,

This makes some sense. I'm sure it could be advantageous in some applications. These are some disadvantages I can think of: the JSONP server sees all the requests coming from one server (your Node.js server) - if it's a third party server, they might interpret the traffic as an attack and block your IP; increased inbound and outbound bandwidth usage on the Node.js server; using up connections on your Node.js server (those connections that are being spent getting data from the JSONP server could perhaps be better spent serving more users); increased latency. All unnecessary, just to achieve a cleaner client side coding style with one transport, right? Because your other advantages are silly - "easy to use" (so is jQuery's JSONP reader); "no cross-domain issues" (that's sort of the point of JSONP); "based on well-known technologies" (your library and Socket.IO are much less known than the JSONP/AJAX/HTTP standards); "multi-purpose transport that can stream binary data too" (well yes, the non-JSONP part can stream binary data; the JSONP part can only stream JSONP data...).

If the server was doing something that the client couldn't, then there's a possible advantage. Like if the client was something so thin that it didn't have AJAX capabilities - but then how would it be communicating with the Node.js server? Or if the server was just statically retrieving and serving the JSONP as a static page - but that has nothing to do with this proxying idea. So I honestly can't come up with anything that sounds like a real advantage to me... Sorry...

I stand by everything I said about exposing a database to clients. To everyone reading this, please do not expose client-side access to your database. Olivier, maybe you could write another post on your blog about this topic, like your approach to securing it?

-Richard

[Olivier Scherrer]

Hi Richard,

Thank you very much for your feedback and explications, that's a very interesting discussion. 

About JSONP, I still think of it as an "exploit", like the wikipedia article says: "Exploiting the open policy for <script> elements...". My solution, on the contrary, seems more conventional. Of course I wouldn't ping a JSONP server with it. I've developed a browserID request handler that can be plugged into my framework, which uses browserID's services like explained in browserID's Quick Setup. I think that this is a nice use case for the solution, and there are certainly others.

I understand the dangers of exposing the database to the client and will express warning to people that want to use the solution for that purpose. I need to dig this further until finding the proper way to have both easy access to the data and maximum security.

Something puzzles me though, what do you think of PouchDB? It's a portable CouchDB written in JS that you can install in the browser and can replicate with other instances. Isn't that worse in terms of security?

Thanks,

Olivier