SPA Silos

I was recently listening to a fascinating .NET Rocks podcast which featured Miguel Castro discussing MVVM on the Web. Miguel talked about his experiences with Knockout.js and AngularJS as client side MVVM frameworks. What I really enjoyed about this podcast was the insight he brought to the table of developing commercial SPA's (Single Page Applications) but using a more hybrid approach. What am I saying here? I think Miguel used the phrase “pages with SPA pockets” but said Brian Noyes coined a much more accurate description—SPA Silos.

SPA Silos are where a single web application is actually made up of many SPA’s. When we envisage creating a SPA, we normally have a vision of a single HTML base page that will initially load all of your SPA code. From there the browser will not actually request any new pages from the server but only swap out views and make web API calls in the background as you navigate around the app. The SPA Silo approach is to break that single SPA into many mini SPA’s each responsible for its own area of functionality. Navigation within the mini SPA is handled by routing in the SPA framework. When moving to different areas of the application, this is handled by requesting a new page from the server which bootstraps all the SPA code for the mini SPA that will provide the functionality for the area of the application you are now navigating to.

Miguel gave a nice example which helped illustrate this practice very well:
Let’s say you are building an e-commerce management web application. The application would have areas such as Products, Customers, Orders, Admin etc. Instead of having a single SPA which contained the functionality for all of these areas, you would actually have 4 mini SPA’s which are each loaded when navigating to the required area instead of upfront when first loading the application.

What are the benefits from using this hybrid SPA Silos approach I hear you asking? There is one very big benefit which immediately springs to mind--Separation of Concerns. I cannot stress the importance of this principle enough. If this hybrid approach was not used you would have one very big SPA application with potentially a very complex and large routing table as well as a very large code base. By breaking the application out into many smaller applications you now only need a routing table for the area your application is concerned with (products or customers for example). Another benefit is that the code base for each area of the e-commerce management application is modularised due to it being implemented in a self-contained SPA. This will help make finding the required code easier assisting with maintaining and enhancing the web application in the long run. SPA applications force the browser to work in a way it was never originally designed to. Browsers work best when they can navigate from page to page and forget everything that happen on the previous page. They like to "wipe the slate clean". SPA’s force the browser to stay on a single page but update the current page's content dynamically as the user navigates around the application. This behaviour could lead to memory leaks as a browser could go for hours, days or even weeks without the page actually being refreshed. This hybrid model helps encourage page refreshing as each time the user moves from one area of the application to another, the application will make a page request and the browser will be breathing a sigh of relief. Of course, if the user were to spend all their time in a single area of the application the original problem will still be present. However, with the hybrid approach the functional surface area which a user can operate in without triggering a page refresh is greatly limited, increasing the likelihood of a page refresh occurring on a more regular basis.

On the downside there is the added complexity of handling a combination of client-side and server-side routing within the web application but I feel this is outweighed by the benefits of this approach.

Miguel will be presenting a session on this approach at NDC London in December so I will be watching this session as soon as it’s posted on their Vimo channel. If you cannot wait until then, Miguel's Building End-to-End Multi-Client Service Oriented Applications - Angular Edition course on Pluralsight also provides an insight into this hybrid approach.

Quoting Miguel, "It’s the best of both worlds".

EDIT:
You can find Miguel's talk at NDC London here: AngularJS for ASP.NET MVC Developers by Miguel A Castro.

Think Twice Before Changing your APIs

How often do you make changes to a service that actually alter the API itself? I'm sure if I asked this question to an experienced developer the answer would follow something along the lines of "You would NEVER want to do that! If you change the API, you risk breaking any applications that are consuming that service." As this danger is fairly well known, how do you guard against it?

Imagine this scenario: there is a set of web services that are being consumed by multiple web applications. The API for one of these services has been changed so that a service method that was taking a string, is now taking an integer. Unfortunately, this little change caused the contract surrounding the service to also change, which meant that any applications consuming it would also need to be updated. It wasn't until another application started to throw exceptions that it became clear that one had been missed.

If this was a new area of development, a contributing factor to this oversight could have been that the developer making the change might have not known that the contract they were changing was already being consumed by multiple applications. The developer might have assumed that it was OK to change the contract because the code was "very young" and it couldn't have been integrated with other applications in such a short time frame. If anything this highlights why you can’t rely on a developer to catch this as they can't be expected to know of where each service method is being used.

The fix is simple, but could this have been avoided in the first place? A simple solution would be to never alter the API of a service, ever. The problem with this is that it is still comes down to the developer to ensure that this is being followed. Remember that in my example, the service method had been only been created very recently so it's conceivable that another developer would also assume that they were dealing with the only occurrence where the service method was being consumed. Documentation and improved communications between developers would help to identify an issue, but it would still be up to the developer to notice it.

An ideal solution would be automated so that a developer would not need to be aware of how an API is being consumed. If this could be created as a set of tests that are run as part of a build process, any issues would be identified well before deployment to production. To achieve this, you would need the ability to stage the service in a test environment where you could fire off requests to verify that the API has not changed. Another possibility would be to compared the current WSDL file with a previous version to check for changes.

If you find yourself considering altering an API, be sure to take a moment to ask yourself why. Can you extend the current contract to ensure that the API will not be broken instead of changing it? In most cases, this should be the preferred course of action and making changes to the contract should only happen when there really is no other choice.

Bootstrap 3's Grid System

I have been playing with Bootstrap 3's grid system and have found it to be a very clever general purpose grid system for assisting developers with the layout of their sites. It also helps lead you to developing a responsive design which adapts to the size of the screen size it is being displayed on. To help cement these concept in, I quickly created a demo site which allowed me to view bootstraps responsive design features in action.

You can find that site here. 
Adjust the width of the page and see how the grids layout automatically adjusts with you. These adjustments go beyond shrinking the width of a column but allow you to specify different column sizes for specific view ports. This opens up lots of options for re-arranging your site to make it just as usable on a phone, tablet or laptop.

Bootstrap goes beyond just allowing you to apply different widths to a column within a grid though. It also provides you with the ability to show and hide columns based on the width of a page. This provides you with even more functionality to empower your sites responsive design.

How does Bootstrap do this? It's all through the use of CSS media query's. Media query's allow specific CSS to be applied when certain condition are met. In the case of the Bootstrap grid system, these conditions are based on the width of your page. Take a look at the Bootstrap 3's docs to get a better understanding of how this works and the grid system in general.

With CSS frameworks like Bootstrap, HTML5 Boilerplate and Pure, its getting harder and harder to NOT create a responsive site.