node.js framework - Hapi

node.js framework - Hapi
https://hapijs.com/

Framework backgrounds:
The initial commit for Hapi was on August 5, 2011 by Eran Hammer a member of WalmartLabs. Hapi was created by parts of Postmile and was originally built on top of Express. Later it was developed into its own framework because of what Erin state's in his blog:
hapi was created around the idea that configuration is better than code, that business logic must be isolated from the transport layer...
3,816 commits later Hapi is is on version 7.2.0 and is still maintained by Eran Hammer.

Creating a server:
var Hapi = require('hapi');
var server = new Hapi.Server(3000);

server.start(function() {
console.log('Hapi is listening to http://localhost:3000');
});
Hapi is the unique one of the group. First like always, hapi is required but instead of instantiating a hapi app, you create a new Server and specify the port. In Express and Koa we get a callback function but in Hapi we get a new server object. Then once we call server.start() we start the server on port 3000 which then returns a callback. However this is not like Koa and Express, it is not a wrapper around http.CreateServer(), it is using it's own logic.

Routes:
var Hapi = require('hapi');
var server = new Hapi.Server(3000);

server.route({
method: 'GET',
path: '/',
handler: function(request, reply) {
reply('Hello world');
}
});

server.start(function() {
console.log('Hapi is listening to http://localhost:3000');
});
Here we are using the built in method that the server object provides us server.route() which has the following options: path(required), method(required), vhost, and handler(required). The HTTP method can handle the typical requests GET, PUT, POST, DELETE, and * which catches any route. The handler is passed a reference to the request object and must call reply with the containing payload. The payload can be a string, a buffer, a serializable object, or a stream.

REST API:
var Hapi = require('hapi');
var server = new Hapi.Server(3000);

server.route([
{
method: 'GET',
path: '/api/items',
handler: function(request, reply) {
reply('Get item id');
}
},
{
method: 'GET',
path: '/api/items/{id}',
handler: function(request, reply) {
reply('Get item id: ' + request.params.id);
}
},
{
method: 'POST',
path: '/api/items',
handler: function(request, reply) {
reply('Post item');
}
},
{
method: 'PUT',
path: '/api/items/{id}',
handler: function(request, reply) {
reply('Put item id: ' + request.params.id);
}
},
{
method: 'DELETE',
path: '/api/items/{id}',
handler: function(request, reply) {
reply('Delete item id: ' + request.params.id);
}
},
{
method: 'GET',
path: '/',
handler: function(request, reply) {
reply('Hello world');
}
}
]);

server.start(function() {
console.log('Hapi is listening to http://localhost:3000');
});
First impressions of the routes in Hapi are how clean and readable they are compaired to the other frameworks. Even the required options method, path, handler, and replay for the routes are easy to the eye. Like Koa, there is a lot of reuse of code making the room for error larger. However this is intention, Hapi is more concerned about configuration and wants the code to be cleaner for easier use in a team. Hapi also wanted to improve error handling which it does without any code being written on the developers end. If you try to hit a route not described in the REST API it will return a JSON object with a status code and error description.

the Good:
Hapi is proud to say that their framework is based on configuration over code, and a lot of developers would argue that this is a good thing. This is very usual in large teams to add consistency and reusability. Also with the framework being backed by WalmartLabs as well as many other big name companies using Hapi in production, it has been battle tested and companies are confident enough to run their applications off of it. So all signs point towards this project continuing to mature in to a great framework.

the Bad:
Hapi definitely seems to be more tailored towards bigger or more complex applications. It is probably a little too much boilerplate code to throw together a simple web app and there is also a lot less examples or open source applications that use hapi. So choosing it might involve a little more part on the developer rather than using third party middleware.