Curl and a missing slash

Monday, February 24, 2014

While I was playing around with proxy-mirror I noticed an interesting behaviour when testing the proxy with curl. The following command:
curl http://wp.pl --proxy http://localhost:8888/
will result in following output when the proxy is Fiddler:
[Fiddler] Response Header parsing failed.
Response Data:
<plaintext>
43 6F 6E 6E 65 63 74 69 6F 6E 3A 20 63 6C 6F 73 65 0D 0A 0D 0A 3C 48 54  Connection: close....<HT
4D 4C 3E 3C 48 45 41 44 3E 3C 54 49 54 4C 45 3E 34 30 30 20 42 61 64 20  ML><HEAD><TITLE>400 Bad
52 65 71 75 65 73 74 3C 2F 54 49 54 4C 45 3E 3C 2F 48 45 41 44 3E 0A 3C  Request</TITLE></HEAD>.<
42 4F 44 59 3E 3C 48 32 3E 34 30 30 20 42 61 64 20 52 65 71 75 65 73 74  BODY><H2>400 Bad Request
3C 2F 48 32 3E 0A 59 6F 75 72 20 72 65 71 75 65 73 74 20 68 61 73 20 62  </H2>.Your request has b
61 64 20 73 79 6E 74 61 78 20 6F 72 20 69 73 20 69 6E 68 65 72 65 6E 74  ad syntax or is inherent
6C 79 20 69 6D 70 6F 73 73 69 62 6C 65 20 74 6F 20 73 61 74 69 73 66 79  ly impossible to satisfy
2E 0A 3C 48 52 3E 0A 3C 41 44 44 52 45 53 53 3E 3C 41 20 48 52 45 46 3D  ..<HR>.<ADDRESS><A HREF=
22 68 74 74 70 3A 2F 2F 77 77 77 2E 77 70 2E 70 6C 2F 22 3E 61 72 69 73  "http://www.wp.pl/">aris
3C 2F 41 3E 3C 2F 41 44 44 52 45 53 53 3E 0A 3C 2F 42 4F 44 59 3E 3C 2F  </A></ADDRESS>.</BODY></
48 54 4D 4C 3E 0A                                                        HTML>.
while a simple implementation relaying on node.js core http module and http-proxy module outputs this:
An error has occurred: {"bytesParsed":0,"code":"HPE_INVALID_CONSTANT"}
Meanwhile without the proxy parameter the actual response is:
HTTP/1.1 301 Moved Permanently
Server: aris
Location: http://www.wp.pl
Content-type: text/html
Content-Length: 0
Connection: close

Curl forgiving behaviour

As it turns out the actual outgoing HTTP request is different depending on the presence of –-proxy parameter. Without it the target server receives and responds with:
GET / HTTP/1.1
User-Agent: curl/7.26.0
Host: wp.pl
Accept: */*

HTTP/1.1 301 Moved Permanently
Server: aris
Location: http://www.wp.pl
Content-type: text/html
Content-Length: 0
Connection: close
but when the proxy setting is present:
GET http://wp.pl HTTP/1.1
User-Agent: curl/7.26.0
Host: wp.pl
Accept: */*
Proxy-Connection: Keep-Alive

UNKNOWN 400 Bad Request
Server: aris
Content-Type: text/html
Date: Sun, 23 Feb 2014 16:01:36 GMT
Last-Modified: Sun, 23 Feb 2014 16:01:36 GMT
Accept-Ranges: bytes
Connection: close

<HTML><HEAD><TITLE>400 Bad Request</TITLE></HEAD>
<BODY><H2>400 Bad Request</H2>
Your request has bad syntax or is inherently impossible to satisfy.
<HR>
<ADDRESS><A HREF="http://www.wp.pl/">aris</A></ADDRESS>
</BODY></HTML>
As you may have noticed the difference in requests (apart from additional header) is in first line – where in the first case curl assumed we want to GET /. The former uses a relative URI while the later absolute. Now if we change the command line just a little bit so that the address looks like http://wp.pl/ the server will receive request with correct absolute URI and will respond with 301.

UNKNOWN Status Line

Careful readers may have already noticed the Status Line of response returned by server is malformed. According to the spec it should have following form:
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
That's the reason why Fiddler warns users about protocol violation and the reason of error inside node.js proxy.

A less intrusive proxy

An example described above leads to other questions about behaviour of http proxy especially if we think about implementing HTTP debugging tool like proxy-mirror. It’s only a guess but I suspect that there are other subtle differences between requests sent by client and those received by target server when the proxy is implemented using http-proxy module or core http module. I am aware of at least one such case where HTTP Headers are lowercased. If I’m right a debugging tool relaying on them would make it really hard to spot certain problems – like protocol violations on both client and server side.
In my next blog post I’ll describe how to built even less intrusive proxy without building the http parser by hand.

An HTTPS system proxy with node

Thursday, January 2, 2014

Creating a simple http proxy in node.js is super easy thanks to an excellent module – http-proxy. With only the following code you’ll have a proxy that can be used as system or browser level proxy:

var httpProxy = require('http-proxy');
var proxyServer = httpProxy.createServer(function (req,res,proxy) {
	var hostNameHeader = req.headers.host,
	hostAndPort = hostNameHeader.split(':'),
	host = hostAndPort[0],
	port = parseInt(hostAndPort[1]) || 80;
	proxy.proxyRequest(req,res, {
		host: host,
		port: port
	});
});

proxyServer.listen(8888);

Adding support for HTTPS

The first thing we will need is a certificate that will be used by TLS implementation for encryption. A server has access to certificate private and public key thus it is able to get a clear text from a message encrypted with public key. It’s a common knowledge that asymmetric encryption is more expensive in terms of CPU cycles than its symmetric counterpart. That’s way when using HTTPS connection asymmetric encryption is only used during initial handshake to exchange a session key in a secure manner between client and server. This session key is then used by both client and server for traffic encryption using symmetric algorithm.

Naturally to get or rather to buy a proper certificate one would have to be verified by a valid certification authority. Fortunately for the sake of a demo we can generate a self signed certificate. That’s really easy, a nice description is available on heroku help pages:

openssl genrsa -des3 -passout pass:x -out proxy-mirror.pass.key 2048
echo "Generated proxy-mirror.pass.key"

openssl rsa -passin pass:x -in proxy-mirror.pass.key -out proxy-mirror.key
rm proxy-mirror.pass.key
echo "Generated proxy-mirror.key"

openssl req -new -batch -key proxy-mirror.key -out proxy-mirror.csr -subj /CN=proxy-mirror/emailAddress=piotr.mionskowski@gmail.com/OU=proxy-mirror/C=PL/O=proxy-mirror
echo "Generated proxy-mirror.csr"

openssl x509 -req -days 365 -in proxy-mirror.csr -signkey proxy-mirror.key -out proxy-mirror.crt
echo "Generated proxy-mirror.crt"

http-proxy support for https

http-proxy module supports various https configuration for example passing traffic from https to http and vice versa. Unfortunately I couldn’t find a way to get it working without preconfiguring target host and port – which was a problem while I was implementing proxy-mirror. Here is what curlwill print out when trying to use such proxy:

curl -vk --proxy https://localhost:8888/ https://pl-pl.facebook.com/
* timeout on name lookup is not supported
* About to connect() to proxy localhost port 8888 (#0)
* Trying 127.0.0.1...
* connected
* Connected to localhost (127.0.0.1) port 8888 (#0)
* Establish HTTP proxy tunnel to pl-pl.facebook.com:443
> CONNECT pl-pl.facebook.com:443 HTTP/1.1
> Host: pl-pl.facebook.com:443
> User-Agent: curl/7.26.0
> Proxy-Connection: Keep-Alive
>

I suspect the problem is inherently related to the way http-proxy uses nodejs core http(s) modules – I might be wrong here though. The workaround I’ve used in proxy-mirror was to listen to CONNECT event on http server, establish socket connection to a fake https server listening on different port. When the https connection is established the fake https server handler proxies requests further. The advantage of this approach is that we can use the same proxy address for both http and https. Here is the code:

	var httpProxy = require('http-proxy'),
    fs = require('fs'),
    https = require('https'),
    net = require('net'),
    httpsOptions = {
	    key: fs.readFileSync('proxy-mirror.key', 'utf8'),
	    cert: fs.readFileSync('proxy-mirror.crt', 'utf8')
    };
    
    var proxyServer = httpProxy.createServer(function (req, res, proxy) {
	    console.log('will proxy request', req.url);
	    var hostNameHeader = req.headers.host,
	    hostAndPort = hostNameHeader.split(':'),
	    host = hostAndPort[0],
	    port = parseInt(hostAndPort[1]) || 80;
	    proxy.proxyRequest(req, res, {
		    host: host,
		    port: port
	    });
    });
    
    proxyServer.addListener('connect', function (request, socketRequest, bodyhead) {
	    var srvSocket = net.connect(8889, 'localhost', function () {
		    socketRequest.write('HTTP/1.1 200 Connection Established\r\n\r\n');
		    srvSocket.write(bodyhead);
		    srvSocket.pipe(socketRequest);
		    socketRequest.pipe(srvSocket);
	    });
    });
    
    var fakeHttps = https.createServer(httpsOptions, function (req, res) {
	    var hostNameHeader = req.headers.host,
	    hostAndPort = hostNameHeader.split(':'),
	    host = hostAndPort[0],
	    port = parseInt(hostAndPort[1]) || 443;
	    
	    proxyServer.proxy.proxyRequest(req, res, {
		    host: host,
		    port: port,
		    changeOrigin: true,
		    target: {
		    	https: true
		    }
	    });
    });
    
    proxyServer.listen(8888);
    fakeHttps.listen(8889);

HTML5 WebSocket support

The above code has still problems handling WebSockets. This is because browsers, according to the spec, change the way they establish initial connection when they detect that they are behind an http proxy. As you can read on wikipedia more existing http proxy implementation suffer from this.  I still haven’t figured out how to handle this scenario elegantly with http-proxy and node.js, when I do I will post my findings here.

Building an HTTP sniffer with node.js

Wednesday, January 1, 2014

Whether to inspect a server response, optimize network usage or just to fiddle with new REST API it almost always make sense to use an application that can display http requests and responses for investigation. On Windows there is the great Fiddler. While it’s possible to use Fiddler on other platforms using virtualization software I think it’s an overkill. Fortunately there are alternatives. Charles looks like the most advanced one offering most if not all features available in Fiddler. There is also a little less popular HTTP Scoop. Both Charles and HTTP Scoop aren’t free but in my opinion they are worth the price especially if used often. Command line lovers might find mitmproxy suit their needs. If you only need basic features ngrok might serve you well. To dive a bit deeper and see http traffic on a tcp level WireShark is indispensable.

As you can see there are plenty of tools available to help understand what is happening on http level. As I was learning about http caching a question popped to my head. How hard would it be to actually build a simple http sniffer?

proxy-mirror – a simple http inspector

As it turned out it’s actually not that hard to built one thus proxy-mirror came to be. Of course this is a very simplistic http sniffer – nowhere near to tools I mentioned above both in terms of features and reliability – but it works (at least in most scenariosWinking smile). It’s open source and I learned couple of new things about HTTP while implementing it – more on that in future posts. Here are some screen shoots of the the tool: 

As you might have guessed from screenshots proxy-mirror is a web application. Right now it’s not very easy to try it out – the instructions are in the Readme – I’ll try to fix it soon.

How it works

I wanted to run proxy-mirror on many platforms and rely on a foundation that has both great support for http and building web applications. I picked node.js over java or ruby mainly because I wanted to sharpen my skills in it.

You can think of proxy-mirror as 2 logical components. The first is a regular http proxy that you can use by configuring your browser or system. I didn’t want to focus on building that first so I utilized a great node module call http-proxy. With it’s helped you can have a system wide proxy in couple of minutes. The http proxy component emits events whenever a request or response goes through it. Those events are consumed by the second logical component – a web application built with express.js. The information about http traffic received from events is then pushed to browser part through socket.io where a simple SPA built with my beloved AngularJS displays information about them.

Features

Right now proxy-mirror has only couple of features:

  • http and https support – although the latter one requires additional setup
  • simple session list – a grid with list of request/response pairs that you can inspect
  • a detailed view – both for request and response that can display headers, message body and a preview right in the browser

Although it still is a very simple (and buggy) application I actually found that it has most of features I frequently use – probably except for filtering. Maybe someday it will become a reasonable alternative for Charles - at least for me.

I think building an http sniffer is a great exercise in the process of learning how http(s) works. I guess the famous saying about journey being more more important than the destination fits nice here.

Combine Express.js and ASP.NET Web API

Sunday, November 3, 2013

I’m really excited about the OWIN initiative. This “standard” enables countless new ways of combining existing http web stacks with .net – a thing that up until recently was either impossible or not feasible. It gets even more positive knowing that Microsoft supports the case actively.

OWIN - why you should care?

Open Web Interface for .NET aims to define a standard interface between web servers and web applications. Adhering to this interface will allow decoupling of server implementations from web frameworks. The idea isn’t something novel and other platforms benefited from it immensely. In Ruby we have pretty mature Rack which allows hosting Rails, Sinatra or any other rack compatible application on a web server of your choice. In Node.js world there is Connect middleware with frameworks like Express and Zappa built on top of it. To be fair Connect is not exactly the same thing as Rack but the analogy serves well to understand underlying ideas.

Having a common middleware and frameworks built on top of it not only allows you to swap your web server at whim. It also means that you’re now able to combine many application into one easily even if they are implemented in different frameworks. It took me some time to realize how powerful concept it is until I built a demo for a conference presentation. I wanted to have single web server running in background so that I can easily switch between pages built with Angular, Backbone and Knockout. I also didn’t want to throw out separate templates scaffolded with Yeoman and have a shared REST-like api built with Express. How surprised I was when the only thing I needed to do was to call equivalent of:

connect.use(angularApp);
connect.use(knockoutApp);
connect.use(backboneApp);

OWIN opens a new world for .NET web stacks

This all may sound blurry for a .NET newbie or maybe even to experienced developer so I’ll give some examples of what is or will be possible to do in a near future.
  • IIS as option not requirement – having a way to add a full fledged web interface for a windows service was not an easy thing to do. If only you could you use Asp.Net MVC things would be so much easier. Guess what, when Asp.Net MVC will support OWIN and I’m positive it someday will, this will be a no brainer.
  • Combine Nancy, FubuMVC, pick a name – maybe you would like to use some existing component and not have to rewrite it to match you stack. Or maybe you work on a really big project and some teams prefer one framework over the other. You are right, this already is possible.
  • Integration tests – say you would like to execute end to end tests over your web application. Right know you’ll either have to deploy your asp.net mvc app to IIS or IIS Express. This means spinning up separate processes even if you would like to run a single test on you development machine. You may be lucky and be using asp.net web api and be able to use HttpSelfHostServer but then again you’re limited only to this stack. With OWIN it already is possible to use a lightweight Nowin or Katana to run any compatible application inside your tests.
  • Faster Tests – is hosting a http server inside you tests too expensive? With OWIN you might actually be able to run tests entirely in memory with no network involved whatsoever.
  • Cross cutting concerns – maybe you need to apply the same authentication mechanism to couple of separate applications. Yes you’re right implementing it as HttpModule might work, but what about this one that you have to support which is based on Nancy. Nancy already supports OWIN so you’re good to go.
  • Combining Express.js and Asp.Net Web Api – so you’re building a web app using Express.js but you’ve found that it would be nice to reuse some part of the existing code that is built in .NET. With the excellent edge.js and OWIN enabled middleware built on top of it called connect-owin you’re now allowed to this.

One app using both Express.js and ASP.NET Web Api

The last example of OWIN usage seemed like the coolest to me so I wanted to try if it’s really doable at the moment. This wasn’t as easy as one could wish but bare in mind that the OWIN initiative is just starting getting momentum and we’re really on a bleeding edge. The connect-webapi-samples repo contains a sample of single web app where some requests are served by express.js while others using ASP.NET Web Api. You can start the server with:
msbuild .\Connect.WebApi.sln
node .\index.js
Navigating to http://localhost:3000/hello will give you response from Express:

image

When you go to http://localhost:3000/webapi/values you’ll get a standard ValuesController response:

image

Note that both requests are logged in console using connect.logger middleware:image

I was thinking about a case where this combination could become handy. In a project I’m currently involved in we’re using Highcharts to present beautiful charts to clients. Unfortunately some of them still use ancient browsers like IE7 which does not handle many Highcharts displayed on one page – or rather dies trying to render them. For those browsers we actually produce similar chart images on server. This however requires a lot of boring code to convert from Higchart chart configuration to the 3rd party library format we use for rasterizing.

What we could do very easily with OWIN is to keep a .NET component that generates a complete Highchart configuration and add a very thin “middleware” layer that would take a real configuration pass it into Phantomjs and get back an image that would look exactly the same as real chart. I’m pretty sure it would be much more robust solution than our current approach.

Backbone – when used properly…

Sunday, October 27, 2013

it keeps one’s head out of one’s butt.

This little gem was the first JavaScript MVC like tool that caught my eye. It has a very vibrant community and seems to have reached certain maturity level. More importantly it is so small library that everyone can grok its source code fully in couple of hours. And yet I haven’t actually used it in any project even thought I had couple of occasions.

I guess it was partially because I had read ThoughtWorks technology radar October 2012 edition where author’s claim that:

Backbone.js is a great example of an abstraction pushed too far (…) We find that it blurs the framework and model too much, forcing either bad architectural decisions or elaborate framework hackery in order to preserve sanity.

Back then I had to make a quick decision which framework/library to use, if any, on a project that I started working on and the article steered my away from using Backbone.js. Just for the record the project was developed with Angular.js.

Forming my own opinion

It really bugged me why the technology radar authors stated such a harsh opinion about a tool that has caught some much attention. It seemed even more interesting because I haven’t found a follow up or a more elaborate and concrete comment about the decision to put Backbone.js on hold. I did however find some time to do a simple demo for a presentation I gave on our company internal conference.

The demo I built has only 2 pages. First one shows how to make a page more interactive with a filtered table and couple of elements that trigger the same behaviour. Second view was created just to see how easy it is to make use of html push state. The source code is available on github.

Due to its minimalistic nature it’s really easy to start working with Backbone. The documentation is easy to follow and if you don’t find enough explanation you can always dive into reading the source. The library let’s you choose how you would like to render you views. Out of the box it provides support for client side templates by leveraging underscore.js.

Views are in fact the main force that drives code control. As there is no typical Controller I found it hard to decide where to put some of the initialization logic. For simple cases Router might be a good choice however as the application grows I pretty sure this approach would not be sufficient. It also means that you are now responsible for composition of smaller views into a complete page. I know this problem is solvable in many ways – Derick Bailey’s plugin Marionette is an excellent addition that fills the gaps not provided by Backbone.

What I find most disturbing is the way we attach events to DOM elements by providing selectors. I use this approach on daily basis in a project solely based on jQuery but there are several shortcomings that in my opinion make it hard to apply to large applications. First of all it means that you typically would add artificial CSS classes to elements. This isn’t bad at first as long as you use those classes only for attaching events and not for providing ways to style your application. An important implication follows –it’s nearly impossible to have a UI designer to work on html and CSS parts without breaking application behaviour. You can however mitigate this by establishing some rules and naming conventions. For instance that all artificial classes used to attach events are prefixed with ‘js-‘ and shall not be used inside CSS files.

Prefer composition over inheritance.

The most important part of the presentation logic are models, view models or presentation models (depending on a pattern flavour you’re using). I think it should be the main place where your application behaviour is defined. Whenever a tool that I’m using is trying to push some structure over me in that single place I immediately get suspicious. Unfortunately it’s not different in Backbone. The way you define and implement your models inside Backbone app is through deriving from base class provided by the library. By doing this you gain many of the commonly required features of model object like filtering, validation and even associations. It speeds up a development a lot especially when you are in need of this commonly requested functionality like form editing in CRUD applications.

However, from my experience, preferring inheritance over composition hurts the most when used to built model part of an client side MVC. I guess this is true for me mainly because I often change the structure and the way different parts of model talk to each other way more often than views and controllers interactions. Having a predefined structure, imposed by framework, limits ways you can define the model and this sometimes leads to pain points that are hard to overcome. In general inheritance is much stronger form of coupling than composition even in a language as malleable as JavaScript so I think that my observations might be true for others too. As all ways this is a question of getting the right balance between having a lot of features ready and waiting for you and keeping you model as flexible as possible to survive the harsh realities of requirement changes.

Don’t listen to me, try it yourself…

I’ve pointed some of, in my opinion, weak points of Backbone. I realize that I might be wrong in some parts and have missed out some important aspects. The fact that the community behind the tool is so active and from what I see always willing to help some newbies can probably out weight cons I’ve listed. I think Backbone is a very effective tool for many programmers out there – it just does fully adhere to my rules.

However when choosing a framework to use on a project one should not be focussed on finding good or bad opinions on the web. I think its much better to spent a week or couple of days with the team actually using the tool to build real features. This can give an immense feedback generated by the project team within actual context – one that you would never get reading reviews on the web.

AngularJs modules to the rescue

Monday, September 16, 2013

Building large scale JavaScript application is a tough problem. The language nature is malleable and it does not have proper modules mechanism built in. Some argue that you can’t really built and maintain big applications built with JavaScript.  Others say that the key in succeeding is to never built big applications but to approach things in a more clever way – by applying divide and conquer rule.

Dividing code base

Due to lack of modules mechanism in ECMAScript 5th edition, which is the version most commonly available in browsers, there were couple of implementations created. RequireJs and AMD are just 2 most popular ones. Angular team decided to provide it’s own implementation of modules and left the asynchronous loading of them to existing tools. I suspect that it was because they didn’t want to create a dependency on 3rd party library and because of their use of dependency injection. The framework relies on modules heavily making it possible to use just the parts that you actually need saving precious network and loading time. Here is how to define a module:
var myApp = angular.module('myApp', ['ngResource']);

myApp.factory('itemsStorage', function ($resource) { 
  var itemsStorage = ...;
  // items storage implementation
  return itemsStorage;
});
We’ve declared a new module called myApp and stated that it depends on another module called ngResource. In line 3 we are declaring a factory for itemsStorage that requires $resource service. Angular will automatically resolve $resource service and inject it as a value of parameter. As you may suspect under the hood the dependency injection mechanism inspects parameter names of our function and thus it is able to know how to satisfy them with proper values. Be careful when using JavaScript minimizing tools because most of them will by default shorten parameter names and that will break the DI. The only work around for it is to disable an option responsible for parameters in minimizer. Most of the times I find it useful to split one module definition across couple of files. It is a supported scenario but there are some quirks to it.
var myApp = angular.module('myApp');
 
myApp.directive('timeAgo', function(){
  return function($scope, $element, $attrs){
    // timeAgo directive link implmentation
  };
});
The first line says that we would like to retrieve myApp module so that we can extend or use it. This API may be confusing, it was for me, as it may look like we’re actually declaring a module that has no dependencies. The distinction between extending and declaring a module has an important ramification. You’re now responsible of loading file with module declaration before files that extend module functionality. In order to declare module with no dependencies you have to pass an empty array as a second argument:
var secondModule = angular.module('secondModule', []);

A praise of dependency injection

Dependency injection is a very useful concept especially in statically typed languages as C# or Java. It really helps you decouple your code as your classes no longer require to know about the implementation details of their dependencies. There are several ways to implement this pattern however must commonly used is a constructor injection. A lot of IoC containers exists both in .NET and Java world: Castle.Windsor, StructureMap, Guice or Ninject are just a few. However I have never seen a viable implementation of DI in JavaScript until AngularJs.

At first it seemed like a magic, so much that I actually had to dig into the framework code base to see how it’s done. As it turned out the idea behind the implementation is really simple. I did however encounter problems while trying to figure out why a particular service cannot be resolved or a directive isn’t working. Usually it was because of typos in parameter names or a missing dependency in module declaration. I know that the Angular team has put effort to make it easier to figure out those kind of problems in a recent release.

I’ve heard opinions that in a dynamic language as JavaScript the DI provides little to know gain instead adding an accidental complexity. I do agree that it is possible to live without however it requires much more discipline to keep a code clean. Whenever you create a service (a piece of code) that will be used in several places you have to make sure not to leak implementation details to clients (the ones that use the service). Without DI it means you have to make it easy to create a service by hand, typically by providing a factory method or a parameter less constructor. If you won’t take care of it upfront it will be harder to refactor the service implementation later on because of the number of clients that create it. When using DI at least this one task is forced upon you upfront.

Now what makes an actual implementation of DI practical is its ease of use. If you remember a time when most of C# and Java IoC containers required declaring actual object graph in an XML files you’ll understand what I mean. I think Angular team made using dependency injection feel easy and very natural and that’s what makes it so useful.

Dependency resolution and conflicts

There is an important limitation in Angular modules implementation around conflict resolution. Basically the framework uses last wins approach so you really have to be careful while naming things. It may seem not important at first but let’s consider following code sample.
var A = angular.module('A', []);

A.factory('serviceA', function(){
 return function(){
  console.log('using serviceA defined in module A');
 };
});

var B = angular.module('B', ['A']);

B.factory('serviceB', function(serviceA){
 return function(){
  console.group('using serviceB defined in module A');
  serviceA();
  console.groupEnd();
 };
});

var C = angular.module('C', ['A']);

C.factory('serviceA', function(){
 return function(){
  console.log('using serviceA defined in module C');
 };
});

C.factory('serviceC', function(serviceA){
 return function(){
  console.group('using serviceC defined in module C');
  serviceA();
  console.groupEnd();
 };
});

As you can see we have 3 modules here A, B and C. But in line 21 inside C module definition we’re declaring serviceA. Since module C depends on A that already defined serviceA we’re actually overriding the implementation. It’s quite useful to be able to override and stuff our custom implementation of particular service provided by other module. Except that we have no control over the scope of our modification. In the above example the serviceA defined in module C will be the one used everywhere at runtime. Even though module B knows nothing bout C. Calling declared services like this:

serviceA();
serviceB();
serviceC();
Will produce following output:
image
You can play around with this sample on jsfiddle.

What can we do about it? The only advice I’ve seen is to use prefix on service names. Now this is a working and simple approach however the code will not look great. I wonder how hard it would be to modify angular injector part to gain the ability to gain more control over overriding things…

AngularJs – my new superhero tool.

Sunday, September 15, 2013

As I mentioned in my previous post I’ll describe my thoughts and findings about 3 popular JavaScript libraries that help building large web application. I’ll start with AngularJs which is the first one I’ve used in a real product.

Model View Whatever

Angular team didn’t try hard to map their concepts to classical MVC pattern. You can see it even in the title of its home page. Instead they focused on making a development path of a large web application as smooth and productive, in a long term, as possible. This means its really important to return to documentation and developer guide if you feel you’re getting lost along the way. Learning Angular is a really interesting journey especially that many concepts that I previously had categorized as not for the web turned out to be totally useful.

Model and view model

This term has really a short definition according to angular way:

a model is any data that is reachable as a property of an angular Scope object
The nice thing about it is that it really is up to you how you choose to encapsulate the most valuable and complex logic inside your model or view model classes. No base “class” , no artificial properties and helpers is required. In fact the framework won’t force you to build a proper view model for data-binding. While this freedom gives you more flexibility it also means that you are responsible for keeping your Controllers clean and thin. I prefer to put logic that encapsulates data and provides global, shared behaviour into separate classes totally unaware of the UI. Depending on the use case I’ll then put an instance of this model into scope or  if the presentation logic is more complex create a view model that wraps some model objects. To make the model objects easily accessible and sharable between views angular provides services. For a very simple logic that augments the way a single piece of data is presented there are filters.

One important thing to understand though is that data-binding is only happening between view (and directives) and a scope object. If a model object provides events fired when its state changes they have to implemented in a traditional way. When I say traditional I mean that you typically will need to apply Observer pattern – or rather use one of implementations available. This is somewhat different from the dirty checking mechanism that sits behind all the angular data-binding magic. Fortunately the framework provides a way to connect a non angular event to the scope with $apply method. However be warned that you have to be really careful here to call it only outside of angular digest cycle.

Controller – keep it thin

A controller is mainly responsible for setting up the scope object and as such is created on a per view basis. It is the most common entry point for an application behaviour triggered by DOM events. While its often easy to put more and more business logic inside them you should really try hard not to. As a reward I often found myself being able to reuse more logic than I anticipated. Another rule of thumb is to never access DOM elements from controller. Angular has a special place for all DOM related activities called directives.

Directive – a way to reusable ui

This is the part of angular that causes lot of confusion when it comes to building custom directives. Especially that whenever you need to manipulate DOM in any way you should use them. To make things easier there is a lot of not so obvious vocabulary used like compile, interpolate, link and my favourite transclude. In my opinion directives make working with data-binding in angular so productive. They are kind of hard to understand deeply at first, but reading the guide couple of times helps a lot. To demonstrate its power I’ll just say that entire jQuery ui is easily accessible with just one directive. I guess I have to little experience to provide some tips about building directives - the most complex one I’ve built was paginate. Here is a HTML snippet of how to use it:
<div paginate="items">
    <ul>
        <li ng-repeat="item in pager.paged">
            {{item.index}} {{item.text}}
        </li>
    </ul>
    <button ng-click="pager.previous()">Previous</button>  
    <span ng-repeat="page in pager.pages" 
             ng-class="pager.classForPage(page)">
      <a ng-click="pager.goTo(page)">{{page}}</a>
    </span>
    <button ng-click="pager.next()">Next</button>
</div>

Directive is the hardest part to fully understand but if you do learn them and built them in a generic way you can accelerate development a lot.

Views

I’ve only touched couple of aspects of Angular - there is a lot more to it. In particular I haven’t commented on View part in MVC trio. Angular tends to be criticised for the way it handles views. Mainly because you may get to a stage where it is hard to see actual html inside tons of directives attached to DOM elements. An alternative approach would be to use existing template engines like Handlebars – that’s the way it’s done in Ember.js – but it’s not really practical in Angular.

However I really like the idea that behaviour of html elements is immediately visible when you scan views mainly because declarative nature of directives. It makes it possible for an CSS or UI design expert, not familiar with Angular nor JavaScript, to make safe changes to views. In addition you no longer need to repeat selectors to access DOM and attach behaviour to it. This eliminates some of the maintenance burden. Like with any tool you have to be careful though not to overload html with directives and never put logic inside your views even if its only presentation related. If you find yourself repeating the same set of directives in many places of your codebase it may be good to step back a little and think of a way to encapsulate a common behaviour – probably with a more specific directives.

I’ll soon try to comment on features that Angular provides that make it suitable for large scale application development.