Providing Message Pack Support to an ExpressJS Node App

Recently, the extended body-parser that added support for message pack by extending the standard body-parser was released in Mobiltron’s github page.

The module aims to replace the basic body-parser module, in order to decrease complexities for the app programmers. You just need to add the require to body-parser-with-msgpack. An example project is published in Github that exhibits the module’s usage.

var express = require('express');
var bodyParser = require('body-parser-with-msgpack');
var app = express();

// Enable mime-types: application/json, form-data and message pack!
app.use(bodyParser.urlencoded({extended: true}));
app.use(bodyParser.msgpack());'/data', function (req, res) {
  	message: 'success',
  	data: req.body

app.listen(8080, function () {
  // Server started! [...]

The above example creates a POST route /data that accepts application/json, application/x-www-form-urlencoded, and application/x-msgpack mime types. The result is always returned as a Javascript object in req.body.

You can try it for yourself by cloning the Github repository.


Thinking in jQuery

Recently I was doing some heavy-duty Javascript stuff for a web project. It was quite a while since the Firefox plug-in and in many ways, it was rather enjoyable experience (and in some other ways boring 🙂 ).

If you want to do some cool stuff in the web nowadays, the adoption of a Javascript library like jQuery is typical. I had some experience in the past, but the development process showed me that I was not so experienced as I thought. jQuery has good documentation that can be used as a reference, but it is not very usefull, when you want to understand some basic concepts and you are in a hurry of doing some stuff to work.

So, this blog entry has one goal, to transfer my experience of doing stuff with jQuery as a set of rules/advices that will save time to inexperienced users like me.

Rule #1: “When you are using jQuery, forget low-level Javascript functions”

It is a good practice to use always jQuery’s functions to do the stuff you want. Never rely on the low-leve Javascript function. The reason is simple. jQuery offers an encapsulating object for all the elements of the DOM tree. If you select some nodes with the jQuery selectors and then try to access their children with the common DOM function offered by the standard Javascript API, you are done for. You lose that encapsulation and you are back in black.

Rule #2: “Use # for the ‘id’ selector, ‘.’ for the class selector and always use backslashes in front of dots in ids”

No special reason, just remember these three examples:

  • $(‘#theCoolId’) – id selector
  • $(‘.myBigFatClass’) – class selector
  • $(‘#theCoolId\\.With\\.Dots’) – more complex id selector

Rule #3: “When you have to insert code into an element, use html()”

Simple as that, select the node and paste the code:


Hey Stranger!


Rule #4: “By default the ajax() call is asynchronous”

… so if you want to load something, be sure to disable async, or else you will try to access something that is not ready. How can you do that? Simple!

	type: "GET",
	dataType: "xml",
	url: "data/strings.xml",
	success: function(xml) { /* success */ },
	error: function() { /* error */ },
	async: false /* I will wait to load the XML */

Rule #5: “insertBefore() and insertAfter() take the selector as the parameter”

I do not know about you, but I always thought that it is logical for the insertAfter() and insertBefore() to select a node, then append the node. But this is not the way they are implemented. A small example:


Hey Joe!


Rule #6: “It is always your fault”

Usually it is, accept it and try to understand how things are working :), instead of trying to convince everyone that you are Mr. Right!

The Devil’s Advocate: Ajax

Recently I decided to move on with my web programming skillset, and see (at last) a little more modern approach that include much client side coding, with Javascript. The first thing you learn when studying such approaches is the XMLHttpRequest, which is used to send/receive data with the web server.

To aid me, i purchased the Head First Ajax, a really nice book, focused in practical things, than in theory and specifications.

Imagine my suprise when in the first pages of the book i found this code?

function create_request(url) {
    var req = null;

    try {
        req = new XMLHttpRequest();
    } catch (tryMS) {
        try {
            req = new ActiveXObject("Msxml2.XMLHTTP");
        } catch (otherMS) {
            try {
                req = new ActiveXObject("Microsoft.XMLHTTP");
            } catch (failed) {
                return null;

    return req;

In my previous article, I stated that web programming is a little chaotic (the way it is), and the problem is the diverse technologies that are used, among with the ad-hocracy of the browsers.

And voila, one more snippet to my wall of fame, which shows the rubbish approaches that are used in some implementations. Internet Explorer decided that he should have another way to implement the http functionality object and with two different ways, making the programmers, trying to initialize 3 objects in total, with nested try/catch statements.

I really do not know, which great business policy is served with this implementation … maybe I lack the big picture management thing that exists in the head of some people, that take those superb decisions.