In Part 1, we discussed about the bare-bore design.
In Part 2, we discussed about the high-level implementation structure.

In Part 3, we now explode the box #1 – “Browser or Custom App”. We look at various consumption channels and how they affect the implementation and technology choices.

At a broad level, there are these four channels for consuming any application data^[1]:

• Native application for desktops
  • Operating system dependent (Windows, Mac, Linux, Solaris)
  • Extreme choices of GUI libraries available (MFC, Cocoa, GTk, Qt etc) – a bunch of them cross-platform
  • A large set of libraries has bindings for multiple languages (Java SWT, GTk#, Tcl/Tk etc)
  • Has access to maximum hardware and other resources of the machine
  • Data format and protocol choice is completely under your control – from binary data over custom protocol to XML/JSON data over HTTP
• Native application for tables and mobiles
  • Again, OS dependent
  • Limited choice of GUI libraries available – mostly platform dependent (iOS, Android, Symbian, Blackberry, Windows Phone etc)
  • Has limited, but sufficiently large, access to the hardware and other resources of the device
  • Message and transport protocols are under your control
• Browser based applications
  • Choice of programming language is restricted to JavaScript, except for native browser plugins (that I won’t consider)
  • Choice of formatting and rendering language is restricted to HTML
  • Choice of styling metadata is restricted to CSS
  • Open standards based, cross-browser, cross-platform development can be powerful as well as tricky
  • Plethora of frameworks and toolkits available (jQuery, YUI, Dojo, GWT etc)
  • Transport protocol is strictly HTTP/S, message protocol is typically in JSON / HTML and, at times, XML though not generally preferred because of performance
• 3rd party applications
  • Choice of data format not really under your control – typically, would be either XML or JSON. You want it to be portable across applications
  • Transport protocol will typically be HTTP/S
  • Endpoints will typically be RESTful, though not necessary or mandatory
  • Don’t have to worry about the end user interface – left to the final application

Question: Can we come up with one choice for transport protocol, message format?

Answer: I guess yes. HTTP/S should be the de-facto choice for transport protocol. And this choice shouldn’t require any second thought. These protocols are, probably, the only ones that are invariably allowed by all firewalls – be it wi-fi modem at your home or the one at your office. Corner cases are different issues.

What about the message protocol / format? XML or JSON? And I am pretty sure, the world may be divided on this. I will always get down to choice only between these two for the reasons of portability across languages and platforms – we have parsers and serializers across the board. Both of them have their own pros and cons. Lately, I have started favouring JSON. Even my Java / PHP applications now use JSON format – even the configuration files that I use are in JSON format.

Question again is – is JSON my personal choice or is there a logical reasoning behind it?

Well, it’s my personal choice that I can support with logical reasoning. Apart from other reasons, there are two prominent ones:

1. If needed, I can pass-on the data (complete or partial) into the browser where processing JSON is at least multiple times faster than XML. I once did a benchmark and found JSON parsing 100x-250x faster. That’s logical. And I live in a world where it’s all about web. That’s personal.
2. I can move my application to Node server and there – it’s all about JavaScript. Refer to reason #1 for more details after this.
   Moving to Node is personal choice but if the application is web based, it’s a logical choice.

Summary:

Use HTTP as the transport protocol and JSON as the message format.
Addendum: If possible, use JavaScript runtime. These days, you can create applications using HTML5 and wrap it using embedded browser.

[1]: The reason why I use the term “application data” and not “application” is that several times, we may send out raw data for application mashup while at other times the application itself is the end-consumer of the data.