90 days of node.js - Day 10 Promises and refactoring

In case you don't know what this is all about, the out-of-loop link describing my 90 day journey through node land.

Day 10 was a fairly short day, but gave me some time to plan out what the next few days will be like.

One of the final goals of this whole node.js for 90 days is for me to build out a couple of real apps. I ended up identifying one app which I think will be easy to build together and will also help me pick up some interesting node.js libraries in a app to manage twitter lists. I love lists, but have always found the regular app pretty cumbersome to use. Ergo and itch I can scratch. I find that a structured goal can keep you highly motivated in any unstructured learning process (especially one started on a whim)

My focus today was to clean up the twitter client I originally made and modify it so it becomes a server - an express app. Right now all this app does is spit out a hunk of JSON when you make a request like so http://localhost:PROCESS.ARGV[2]/list?username=SCREENNAME. Not a major leap here, but a simple demonstration of the easiness in integrating  express with any simple request handler. It's still missing exception handling and timeout handling, but I'll get that in. It was a nice tie-in to the work of day 9.

The major change though was using Q. Q is a simple-to-use implementation of the Promises/A+ spec. I love Promises. I use jqeury's deferred right now in all my work and Q has impressed me with the ease in which the exceptions flow thru the promise chain and the simplicity in chaining and creating promises. I plan to use more of Q as time goes on, Personally, I have used Futures in Java before and that's pretty much what Promises are. If you have had to query across sharded databases and get a coherent result back all at once, this whole paradigm is a huge win. I'll leave Jake Archibald's excellent write up on promises to be your guide ( the demos were a little flaky, but I came for the code and stayed for the style and the laughs)

I am using Q quite extensively in the code right now. The idea is that since every call to the Twitter rest endpoints is async, I can either pass in callbacks all the way down OR return a promise at every level and have the calling code wait on when the promises are resolved. This makes it easy to conceptualize the flow of the code. It also makes error handling a breeze and I can use the promise chain to centralize the error messaging and logging. The inversion of control that you get with the promise informing the caller when it gets done, instead of the caller asking it is refreshingly simple to understand and use.

Returning a Q promise from my functions is a bit of a leap. As far as I am concerned, all I am doing is returning an object implementing the Promises/A+ spec. In theory this should work with es6 when promises are delivered as part of the spec, since all Q does is return an object with a then and fail function in line with the Promises/A+ spec. This is a deviation from the design choice that I have seen in node code for the most part - callbacks. Callback hell is real and here to stay ( even though many people I've interviewed for work roles have never heard of it - odd that). If I can contain my code to be nicely organized around a when...then...fail paradigm, I think the code reads better, the intent is clear and debugging is easier.

You can take a gander at the code in the github repo. It's fairly shoddy code right now, so the next few days will be spent in making a more robust server. The next steps that I have planned are :

Another major goal of this whole exercise has been (re)learning how to write good technical documentation. I can write, but I am not sure if I can be effective in explaining why I am choosing a certain code path. It seems to me I have an opportunity to learn how to effectively describe the ideas of design that I am pursuing. I futzed around with a few ideas and eventually latched on docco. Docco is what backbone and underscore use to generate the annotated source code. The annotated source code has been such a life saver, I think it makes sense to write docs on those lines.

These steps involve a lot of building and compiling and seems like that also gives me a good opportunity to pick up grunt or gulp. I am picking gulp, only because the jsFiddle newsletter came out today (jsFiddle has a newsletter, you guys!!!) and it has a link to a tutorial for gulp. Not a workshopper I notice - might be an opportunity there.

In any case, looks like my next 5 days or so will remain packed with more node code.