Strive for one call per user action

So while working on my assigned project at work, I observed some lag populating some drop downs on a screen at I was on. Immediately, I suspected that the drop downs were being loaded from asynchronous calls performed after the screen had loaded. So I fired up Firebug, and sure enough, there they were. 3 calls were being made to the server to get 3 different sets of data to use to populate 3 drop downs. Despite the calls being small and relatively quick (28-49ms each), the effect was still a visible lag long enough that I was able to open one of the drop downs before it had finished being populated.

Now some might say, so what?  Big deal. Why fuss over 49ms? Well, despite the very visible lag, this is just a symptom of a problem that could very well escalate should more drop downs of this nature get added to the screen. Or if this “pattern” is replicated on other more complicated screens it could lead to user frustration and possible inefficient use of resources, especially if the app is stateless and requires authentication.

I’ve followed a guideline, almost a rule, over the past 4 years that I have been building service oriented single page apps, and that is: perform no more than one call per user action. A user initiated action is nothing more than a simple use case. And simple use cases should define a contract that specifies what must be submitted and what must be provided if the preconditions are met. To me, these extra calls are being made because the use case requirements were not fully implemented into one service call. Think of the activity flow or sequence diagram one might draw for a given use case. In its simplest form, the user actor initiates some action with the system and the system responds.  Now, I’m not talking about calls for images or other visual elements.  When I refer to calls, I’m talking about service method invocations.  This by and large is why I take issue with using (non-pragmatic) RESTful services with thier full HATEOS driven implementations as the model for building services for client side applications, but that’s for another post on another day.

Another concern that I have when I see chatty applications that engage in this type of behavior is that it indicates to me that the client application is more familiar with the intimate details of the middleware than it probably should be. This could lead to unintended exposure of pieces of the system that should otherwise be encapsulated. This could expose security concerns and allow new unexpected permutations of workflows and interactions to occur with those functions.

Now it may seem that I am arguing against reusability here, but I assure you that it’s quite the opposite. One could still potentially have those same fine grain functions, but just encapsulate them as implementation detail code that is reused by more coarse grain use case specific methods. In fact, by doing this you will likely find that some of the functionality that resides in the front end code might make more sense being encapsulated in the use case service method code on the server. This code would then be automatically reused if one were to build an alternative front end that leveraged the same service methods.  You might even reduce the size of the amount of data that you are sending over the wire, especially if some of it is going to be filtered out or is just used to help process or relate the data.

For example, let’s say that we organize products by manufacturers.  And let’s say that we have two drop down lists to filter with, one that is a list of manufacturers and the other a list of products.  If we obtain these two lists separately and then drive the contents displayed in the product list based on the selected manufacturer, then we are writing code on the front end to handle that processing.  Additionally, we likely have a manufacturer id or some sort of code, possibly the name, on the product records returned that associate the products with the manufacturers.  An alternative approach to this would have been to send down a dictionary with the manufacturer names as keys and object values containing a list of their products already broken out to each manufacturer.  The processing of the two lists would have been completed on the server and now, an alternative front end would not have to have the same logic repeated.  Consider the following:

    "Good Company",
    "Anvil":            "Acme",
    "Dynamite":         "Acme",
    "Paint on hole":    "Acme",
    "Bandage":          "Good Company",
    "Garden Hose" :     "Sears"


    "Acme":         {products: ["Anvil", "Dynamite", "Paint on hole"]},
    "Good Company": {products: ["Bandage"]},
    "Sears":        {products: ["Garden Hose"]}

The code on the front end can now simply rebind the product list control with the products property of the company object bound to the item selected in the company list control.  With the two separate lists, the front end code would have to scan through the list of products to locate the related products to bind to the products list control when the selected item in the company list is changed.  Consider also that there may be even more complicated rules that might affect those lists such as the user’s location for availability or a combination of other factors and it becomes easier to see why we might want to move that concern to a more centralized location.

I’m interested in other opinions on this topic.  What do you think?  Should we strive to make our front-ends more or less pretty and dumb or should we move more processing logic to the front and have finer grain access to resources from the middle ware?  Please leave your thoughts in the comments below.


Atomic Stack Coding Standards

I have started writing the Atomic Stack Coding Standards documentation. This documentation will begin with coding styles and best practices in an attempt to encourage consistency in the code among the various contributors.

Check it out at

Atomic Stack

So, I’ve been thinking about how I wanted to try to jump start my blog for a very long time.  The problem is, that for as much as I like technology, I’ve never really taken to the typed word.  I’ve always preferred to make a phone call rather than write up an email or send a text. For as fast as I can type, it seems that I can never really type fast enough to get my ideas recorded, except generally in perhaps the case of programming which is good, given that I’m a programmer.  But when it comes to free-flowing thoughts like those generally relayed via speech, I would definitely prefer to dictate than to actually type.  So, I’m going to attempt to use the Voice Memos iOS application as a way to stage the content for my blog.

Recently I decided to start an open source project, based on some opinions I had received at the St. Louis Days of .Net which echoed similar sentiments from the previous year’s conference.  You see, over the years I’ve been fortunate to have been tasked with solving some of the most difficult challenges faced by the various teams that I have been a part of.  I’ve also been fortunate to have worked with some very talented and skilled individuals on those teams.  Some I collaborated with and others I was literally schooled by.  I’ve somehow managed to hold on to the practices that have proven useful and advantageous in the various projects that I’ve worked on and assimilated them as recurring patterns.  I’ve described some of these patterns to certain individuals over the last few years, and nearly every time, I’ve been asked if any of it was embodied in an open source implementation.  The unfortunate answer has always been nothing that I’m involved with and nothing that I was aware of.

So the purpose of this open source project is to embody the set of tools that I will be implementing and leveraging during the course of the development of a personal closed source project of my own.  As such, requirements will flow from my personal project to the tool-set project.  The tool-set will be comprised of a stack of technologies that I will leverage to build an n-tier web application.  These technologies will be new implementations based upon the patterns that I have successfully leveraged over the years.  These will include things in the following list, which I plan to go into further detail of in future posts:

  • Configurable tier implementations across 8 tiers (data storage, data access/io, business enforcement, application services, service hosting, client side server access/io, client side controllers and client side views)
  • Three independent storage/transport schemas (data storage, entity model, and use case schemas)
  • Entity Model in memory indexing
  • Entity Model domain specific querying language built as a fluent api on top of .Net classes
  • Singleton/Multiton supporting services with lifetimes managed by an Abstract Factory implementation
  • Vertically integrated independent entity tiers relationally bound in the business tier with optimized distributed data access/io execution
  • Expansive configuration
  • Web server host abstraction (with IIS integration implementation, future implementations may include integration on top of OWIN)
  • Built in user account management and security authentication/authorization (including access challenge/negotiation)
  • Built in/expandable service hosting options (default web service implementation with multiple/expandable content negotiation options)
  • Subclassable Enums (and conversely enumerated subclasses, an excellent alternative to using switch statements)
  • Additional supporting data types
  • Advanced .net generics tricks (including subclass constraints/contexts and generic namespaces via nested classes)
  • General object based data storage services for supporting the practice of high fidelity functional prototyping
  • Interchangeable client side server proxies (supporting functional prototyping via an elaborate proxy implementation simulating future remote services)
  • Classical inheritance implementation on top of ECMAScript 5/JavaScript 1.8.5 with base class method call dispatching, public and protected access modifiers, instance and static scopes with constructors
  • Pure client side MVC solution implemented using JSON/HTML/JavaScript
  • and of course more…

The name of this set of tools is Atomic Stack.  The server side tiers (Atomic.Net) are being implemented in .Net using C# due its amazing generics support.  The client side tiers (AtomicWeb/AtomicJS) are being built upon HTML5/ECMAScript 5/CSS 3.  The project goals will including adherence to development practices including:

  • Separation of Concerns (including Unobtrusive JavaScript)
  • Clean Coding Principles
  • Tier/Down Design and Development (with wide client side development cycles with narrow vertical server side development sprints)

In addition I will be looking at employing additional practices not currently in use including the following:

  • Design by Contract (at least for application hosted services)
  • Test Driven Development

I’m sure that if anyone actually comes across this blog, that some may point out that there are a ton of frameworks and libraries out there.  They may question, do we really need yet another framework or library, much less a stack of them?  Frankly, I’m not sure.  I do know however that I have ideas and I would like to contribute those ideas in a tangible way to the community.  And due to my past experience, there is a certain degree of independent yet cohesiveness among these ideas which therefore are compelling me to attempt to start from scratch and create these new tools with minimal constraints solely upon the raw platforms that they are to be built upon (.Net, JavasScript, HTML, CSS, etc.).  Ofcourse I will very likely be incorporating additional dependencies upon things that are already well written and tested (like Mike Woodring’s DevelopMentor ThreadPool, HtmlAgilityPack and jQuery).  But it is very likely that I will avoid some tools whose implementations I find lacking (for example the MS Entity Framework).

Anyway, I droned on long enough and I’m not quite sure how to end this post.  If you are interested in checking out the project, please visit