Posts Tagged ‘JavaScript’

Consider my Hapi Edge Developed

Tuesday, August 25th, 2015

The nice people over at Bleeding Edge Press noticed that I submitted a pull request to hapijs related repos at some point and asked if I would be interested in reviewing a book about hapi. Being a fan and apparently wanting to pushing myself I said sure. A few hours later a copy of “Developing a Hapi Edge” by Van Nguyen, Daniel Bretoi, Wyatt Preul, and Lloyd Benson was in my inbox. So let’s do this!

A quick elevator pitch on hapi. It is “a rich framework for building applications and services.” In non-marketing speak it is a framework for building applications for the web. It is exceptionally good at restful APIs and best known for being the framework that powers parts of Walmart. Personally, I like it because it just gets out of my way. In fact this very site is served through a hapi proxy.

Over the past few days I read through the book. I am going to start of with what this book isn’t. It isn’t the book you should buy as your first node book. This book makes the assumption that you know node, have an understanding of the web, and jumps right into hapi. This is a good thing because the book can focus on hapi.

When I say the book jumps right in, I am not kidding. Chapter 1 is a brief history and overview of the book. Chapter 2 turn up the speed. It starts off with setting up a simple server and revs up to different tools that you can use to setup and run you hapi application. This pace is continue throughout the book. I like the pace because it never stays on any topic to long. About the time I am getting tired with a topic the book moves onto the next one.

At the pace of the book, you may get overwhelmed with all the info coming at you. Trust me, by the end of the book it all comes together and it will all make sense. The authors make up for the pace by having a full blown application that book is based on. is the project this book is based on and each chaptor shows how a different part of the hapi infrastucure was built. The best part about this project is the code is available on github. It makes it really easy to see what the book is talking about in a real web application which helps in the learning of hapi. Other technical books or blogs have just shown code demos that you would not use in a real application. Having this project a long side the book was refreshing because if feels like the authors really wanted to show real world use of hapi instead of just some demos.

The authors even took the time to go over debugging and security. While these chapters are by no means a complete resource, it was nice to see a brief overview on the topics. It was enough to get your started with debugging and to get started at developing a secure website. Like everything else in the book, there was little fluff and was right to the point.

So is this book right for you? If you are looking at a quick and short guide to learn hapi, on a team that is using or about to use hapi, or a technical book worm, then “Developing a Hapi Edge” is a good buy for you. If you are looking for a reference book, this is not really it nor does this book claim to be that. The hapi documentation is really well done and an excellent reference.


Ampersandjs and ASP.NET MVC

Thursday, November 13th, 2014

Ampersand is a newish client JavaScript framework that helps build native web applications. It is built and maintained by &yet. Ampersand is different than other frameworks because it is not a monolithic library that solves all your problems. It is a collections of small modules that all solve a single problem that when put together make up Ampersand. This allows you to easily switch out modules that don’t work for you. To read more about Ampersand and its benefits check out the following links.

I recently wanted to know what it would take to run the Ampersand-cli demo app using ASP.NET MVC instead of node.js. So I did just that. The can be found on my github. Head over there and check it out. What follows is some the key points that is a bit different than the node.js version.

Getting Started

Node.js is required when setting up my demo code. It is not required but I used it because it is easier if you do. Node allows us to use npm and tools like gulp and browserify which we will cover in a bit.

First we need to install gulp and browserify from npm. Navigate to the WebApp root folder from the command line and run:

npm install -g gulp browserfiy

Next install all the dependencies found in the package.json from npm by running

npm install

Next run gulp.


Finally build and run the visual studio project.

Browserify and gulp 

Ampersand highly suggests to use a common JS loader like browserify. In my example, I followed this suggestion. Browserify is a commonJS loader that allows you to require(”) modules, like node, in the browser. Gulp is a streaming build system that allows you to run jobs such as pre-compiling CSS, copying files, and many other things.

When browserify is pointed at our main app.js file (Scripts\App\app.js) and run, it will bundle all of the app’s JavaScript files into one file (Scripts\app.bundle.js).

Gulp and the corresponding gulpfile.js is used to watch the JavaScript files and automatically run browserify when things change. This means that as you edit files, gulp will rebuild the app.bundle.js file. All you have to do is reload the browser to get the final results.


With any native web application frame, the odds are good you are doing routing on the client side. Which means the server must serve the same html, css, and js for any page that is request. To do this, a catch all route is created.

    name: "Default",
    url: "{*.}",
    defaults: new { controller = "Home", action = "Index"}

Base Layout and Action

Notice the _Layout.cs file is basically empty. This is because everything is loaded via Ampersand including anything in <head>. This also means that our default controller and action serve nothing. The only things our default action needs to serve is any CSS and JavaScript.


Ampersand’s demo site uses Jade templates and complies them at runtime down to a single template.js file. Meaning that all HTML is served to the user the first time the application loads. In my examples, I sort of replicated this by creating an Action that creates a single JS file with all the HTML templates. This can be better and more automated but for the purposes of this demo I stopped here to show a direction that could be taken.

See the Template Controller and the views in the Template view folder.

Templates do not need to be served this way. You could make HTTP get requests for them in Ampersand. I did it this way to keep in the spirit of the original demo.

Sample API

The simple API was created using Web API. Nothing really different going on here expect that because of C# our models are strongly typed.


The original Ampersand demo used stylizer and a CSS preprocessor. I took the output from that and put it into site.css. You could do whatever suits your needs here.

Final things to Note

In this code, the app.bundle.js and template JavaScript is not far future cached. It could be. That is something you will need to figure out. There are many different ways to do this in MVC, I did not want to suggest one. The same goes for the CSS.

Much like Nuget’s packages folder, the node_modules folder is not checked into source control. Running npm install command will repopulate this folder much like Nuget’s auto restore.

Other than what is about, the rest of the application is vanilla Ampersand, no other changes were made.

Source Code:

So I wrote a state machine. Why? Because it sounded fun!

Friday, February 7th, 2014

I had a problem. I was tasked to make a wizard type interface for a few workflows in an web app. The workflows had 3+ steps with the current max number of steps at 10.


Option 1: I could control state on the server. After every step in the workflow the data of that step would be posted to the server where the server would keep track of it in session and take the user to the next step. This is very doable, and is pretty much how web apps have functioned before ajax. The downside to this is controlling partial state on the server is hard because session management is hard. You have to account weird scenarios like what happens if the user starts the same workflow in a different browser window, you now have to somehow identify what window goes to what session. Or how do you know when to clear a workflow in progress because the user navigated to a different page in the web app. What happens if they come back? All of these question can be fixed in some form but normally involve a lot of if statements.

Option 2: Wouldn’t it be easier to keep all workflow data on the client until the workflow was completed? Yes, yes it is. However this means that the client can no longer do full page reloads between steps. No problem, there are frameworks that cover this such as Angular.js. In my solution, I am loading and unloading html templates into the DOM manually and using Knockout.js for data binding. Why did I roll my own this way? Because IE8 but that is a different blog post. By keeping all the workflow state in the browser, we have less issues to deal with but a few new ones come up. For example, do you care that the user has to start over if they hit refresh? Do you need the browsers back button to work? These were easy for my use cases, it didn’t matter at the moment because of how this will be used in production. I started down this road, things were going well. But then I noticed that my JavaScript was getting kind of cluttered with if statements such as…

if (here) do this
else if (over there) do that
else if (holy crap) I have no idea
else if (another one?) and I am lost

Option 2b: State machines! About 2 steps into the first workflow, I noticed a pattern. Every step in a workflow loaded something, waited for the user to do work, moved to the next step. The lightbulb went off and I started looking at state machines in JavaScript. I found many like machina.js and npm had many in there as well. machina.js being the first in my search results, I went with it. It looks good and probably would have solved my problem but it has(had?) a dependency on underscore.js Due to the nature of this project, introducing an external library is time consuming, introducing two is a huge pain. But, you guessed it, that is another post someday. In the end, I decided to build my own. Why? Because it sounded fun, also I didn’t need a full featured library, yet.


So I wrote a state machine. It had a few requirements there were identified upfront.

  • Know what was the current state
  • Be able to change to a new state
  • Call an unload method on the old state
  • Call a load method on the new state
  • Pass data to the new state
  • Be able to generically call methods on the current state

Over time, I am sure the requirements will grow and we will make the choice of growing this code base or moving to a more feature complete option. And here it is.

    var fsm = function (states) {
        this.states = states;
    fsm.prototype.changeStateTo = function (newState, obj) {
        if (this.current &&
            this.current.unload) {
        if (this.states[newState]) {
            this.current = this.states[newState];
            if (this.current.load) {
    fsm.prototype.callAction = function (action, obj) {
        if (this.current[action])

As you can see, the state machine takes in an object that is the different states that it can be. A usage example is below.

The changeStateTo function will call unload on the current state, and then call load on the new state. It has some light error checking to make sure states and methods exist before continuing.

The callAction method is a generic way to call a specific action (function) on the current state. An example of this would be if there is a button that is on every screen, you could use this method to call that action when it is pressed on the current state.

And a small example of usage.

    var myFsm = new fsm({
            StateRelatedObject: { 
              text: "hello"  
            load: function ()
                //do work like load template or show/hide page elements
            StateRelatedFunction: function()
                //do specific work related to this state.
                //can access objects or methods on current state like...
                this.StateRelatedObject.text = "hello world";
            unload: function()
                //clean up after yourself here.
            load: function () { },
            StateRelatedFunctionOrObjects: function() { },
            unload: function(){ }
    myFsm.callAction("StateRelatedFunction", { /* data in here */ });

The object that is passed into the state machine can get rather large. This is ok because it is segmented into it different states and is well organized.

Testing is pretty easy too!

    //setup test parms here.


    //do asserts on data here.
    //example: myFsm.state1.StateRealtedObject.text === "hello world";


Edit 03/06/2014: I fixed a misspelling in code. I also posted a complete code example to github.