Van Nguyen - Developing a Hapi Edge: A Rich Node.js Framework for Apps and Services

From the very beginning, hapi was built around a simple philosophy-- development should be fun. The role of a framework is to increase your productivity and step in when you want it, but step aside when you dont. It should not mess around with your environment, nor should it take away any of the power available from the underlying platform. But more importantly, the role of a framework is to establish a foundation for collaboration.

Enterprise software development has earned the notoriety of a painful, bureaucratic, stale, and complicated process. Whats worse is that we have learned to accept it as the status quo. At the center of the problem is the fact that enterprise software development happens in large teams, often distributed organizationally and geographically, and require a significant amount of process to prevent one mistake from affecting the productivity of hundreds of developers, or worse affecting the business operations.

When I set course building hapi, I knew the framework had to be the best at handling the typical web application activities, such as authentication, state, and caching, but those are all prerequisites for just being a contender. The real core of the framework is its functionality aimed at making large scale development easier, and fun. It means paying attention to small details like protecting the developer from creating conflicts in routes, cookies or other named properties, and to big details like how to allow teams to work on the same application without constant coordination.

As the project matured, hapi itself became a large scale development process. With dozens of contributes from many different companies and a growing code base, we had to expand the reach of our hapi-ness centric philosophy to the full development process. We greatly value code quality and consistency, and since writing tests was usually a painful part of software development, we worked to make that better, streamlined, and enjoyable. We wrote new testing tools, fortified our coding style, and automated much of the tedious parts. We did the same for documentation, automating the process as much as possible to free developers to focus on functionality.

Four years into the project, the satisfaction of its community is still the greatest motivator and guide in moving the work forward. As it continue to mature, we learn more every day about how it is being used and how we can continue to evolve it; hapi is a dynamic community and the project has a history of not being afraid to break things in order to make them better. We refuse to accept the status quo, even our own.

I am excited you are taking the time to learn about hapi and consider it for your next project; hapi is a community project and you are now part of it. Your voice and your hapi-ness matter and you should consider this your very personal invitation to join us, ask questions, and share with us how we can make things better.

Eran Hammer

July 2015