The Power of Distributed Architecture in Web Apps

If you are a web applications developer in 2014 are you are still designing integrated systems you are probably doing someone, somewhere an injustice. Unless the application you are building specifically has to be integrated as a single code base, you are likely better off making a few design updates and rolling out a more flexible, distributed system. Distributed systems have been around for years but have only in the last few hit full-scale adoption on the web industry. Heavy hitters like linkedin lead the way with a distributed architecture that allows them to roll out new clients for any platform whilst maintaining the same data layer, auth and auxiliary systems. Linked in Architecture 56 Kilobit Most distributed web application architectures features a solid data-layer API, and at least one client designed to interact with it. Commonly the first client application will be a browser application which uses HTTP GET and POST, PUT etc actions to retrieve and send data to/from the Data layer API (to which I am going to assign the acronym DLAPI because it makes me sound clever). Thus, a very simple common distributed system model may look akin to this: Basic Common DLAPI Architecture - 56Kilobit Skilfully crafted using draw.io by the way – incase you haven’t come across this tool before Extending on this model it’s easy to see where the power of distributed systems starts to manifest. Now when you want to roll out a new client, you need only build an interface layer which interacts with the same DLAPI. This way and all clients remain up-to-date with each other, without the need for complicated, slow-ass sync-up routines.   Basic DLAPI Architecture with multiple clients - 56Kilobit.com Our app is now ready to work on PC’s, Phones, Tablets and Aliens. Building on the easy multi-client advantages of a distributed system, these setups can become even more powerful because they are in a much better position to leverage and consume third-party services than an integrated system might be. Developers can save literally months of time by off-loading large portions of their requirements and logic to services which have been designed and built specifically to excel in their problem area. For example, as a web application developer I may well chose to off-load all of my user management and authorisation logic to a maintained third party service like Stormpath or Userapp, or maybe fire off my automated email calls to Apostle.io. Guaranteed these systems are going to be a lot more secure, up-to-date and well maintained than anything I could build into my project because they are run by teams dedicated to one problem area.   DLAPI Architecture with multiple clients and third party services   Being fair, you can obviously use 3rd party apps with fully integrated web apps (FIWA), however, from experience I think that distributed applications are in a better position to take advantage as integration tends to be  shallower, and modules tend to be easier to swap in and out. In the above example, the HTML for the web page can be provided via CDN and some sort of dynamic DNS. This means that the delivery of the HTML, JS assets and Images can be extremely quick. Then, all your client side app has to do, is get some data from your DLAPI and populate the template it already has. The results is performance which far out-runs the traditional integrated application.

In Practise

What do you actually need to do to make your applications distributed? In my opinion the first step to making your applications distributable rather than integrated is to build API-First. Taking the example of a PHP application which lists posts, instead of creating and HTML view file, return your posts and post details using JSON. This may sound like a trivial change, however there is a hell of a lot of design considerations which go into building a good RESTFul API. Id recommend reading my upcoming blog **LINK IN FUTURE** post about best practise API design. I think distributed systems have to be designed properly from the off-set, I don;t think you can easily convert an integrated system, unless it has hidden API capabilities built in. This is a big subject to cover, but as stated, I suggest starting with learning about good API design.

Stacking Up

Requirements for an API driven architecture are different to that of an integrated system. Whereas in an integrated system you may wish to use a full MVC framework like Laravel or Symphony, when it comes to API’s you want light weight and fast. If you are looking to build an API with PHP I would look at Slim or my preferred choice Phalcon. Phalcon is actually a compiled PHP extension so it’s a lot faster than it’s competitor frameworks and ideal for an API. I’ve got some bench marks to share on Phalcon in another **upcoming post**. In terms of client-side, if you are building a browser client app first, I would look into a javascript MVC framework such as Angular or Ember.js. My Current stacks for distributed development are: 1- Node JS, MongoDB, Angular JS 2 – PHP5.5, MySql, Phalcon Framework, Angular JS

Selling It

I’ve cover the commercially orientated side of selling distributed architecture to your boss and clients in Selling Better Web Architecture.