Wednesday, 27 of August of 2014

JSONP and Better Designs

JSONP enables more efficient, more client-centric designs. I wish I would have understood it better when I started building the Tufts GIS portal.

The portal is a nice single-page web app that helps users find GIS data layers. It uses Solr to quickly generate search results. The original design was straightforward. The page has a map, a keyword field, and several other controls for search parameters. When the user initiates a search the JavaScript code sends an AJAX call back to the web server. The server computes a Solr search query based on the passed parameters. Then, it sends the query to the Solr server, gets the search results and returns them as the return value to the AJAX call. The Solr query is fairly complicated, it takes a couple hundred lines of Java code on the server to generate.

This original design works very well but it can be significantly improved because Solr supports JSONP. Instead of computing the Solr search string on the web server, the client can generate it. Then, the client can send off the request directly to the Solr server. This has several obvious advantages. It will be a little faster since the web server hop is eliminated. The load on the web server is reduced. Much more importantly, we have ported a chunck of server-side Java code to JavaScript runningnon the client. I care about this because some institutions might want to stand-up an instance of the portal but they might not be Java shops. By eliminating server side code, I can make the portal server-side technology agnostic. If the portal only uses HTML and JSONP, it can be easily deployed by php shops, Java shops, etc.

Its was easy to change the portal to use JSONP. A couple hundred lines of Java code had to be ported to JavaScript. Since the AJAX call was already returning a JSON object, it was trivial to change the AJAX call to JSONP. The only concern with adding client code is that it typically runs in the UI thread. Having the client compute the Solr search string instead of the server is an additional client side computational load. However, it is of order O(1) and only involves some concatenation to generate a string that is under two kilobytes in length. It is a negligible load.

I put the JavaScript code to generate Solr search strings in its own JavaScript file. Now, anyone can integrate the Tufts GIS data repository into their own portal. They simply include our JavaScript file on their page and call is functions to perform searches. They don’t need detailed knowledge of our Solr instance and its schema. Instead, the JavaScript library provides a high level API.

The JSONP based approach makes the portal independent of server-side technology. It also provides a high level API that our portal and other institutions can use. Both are big wins.