Chapter 7. Making Your Application Production Ready
So, we're already at the last chapter. I hope you have enjoyed learning about hapi and how to build applications with it so far. In this last chapter, I'd like to cover some of the remaining common tasks that we often encounter when building applications, and getting them ready for production.
Here, you'll learn about the following:
Using databases to store our data
Server methods and adding caching to our applications through them
Logging and the importance of logs for applications in production
Different tools to add to your tool belt for debugging Node applications as well as some hapi-specific tools from the hapi ecosystem
Some advice on production infrastructure
Places you can go to in order to continue your learning about hapi
Let's begin.
I covered persisting data earlier in this book in our user store example using an in-process database called LevelDB. While LevelDB works quite well for demo purposes, due to a very simple installation and setup, it has a very limited feature set, and isn't recognized widely as a production-ready database.
Most applications today use some of the better known and tested databases, such as MongoDB (https://www.mongodb.org/), PostgreSQL (http://www.postgresql.org/), or MySQL (https://www.mysql.com/). While this is because of the wider feature sets that they offer, it is also, as it has been proven in production environments, something of vital importance when it comes to a database. When an application crashes or runs slowly, you'll find you have some frustrated customers, but losing their data usually means you've lost them for good!
Taking this into account, I wanted to add an example to demonstrate integrating one of these databases with hapi to show that this can be done just...
In the previous section, we talked about databases and wiring one up to our user store example. However, in applications, a database will often be the main performance bottleneck in the technology stack. The queries we used in the previous section were quite simple, but as an application grows, so does the complexity of a typical database query. Query complexity, as well as a database growing in size will increase the length of time it takes for a single query to run, making for a poor experience for users of our application.
The best strategy for tackling this is to introduce caching. Fortunately, hapi actually has built-in support for server-side caching through the catbox module. catbox is a key-value-based object store which has extensions for different storage engines via adapters, such as an in-memory adapter (added by default when we create a server), Redis, and memcached.
As this is quite an advanced part of application development, I won't go into too much detail...
| | "We're a logging company that just happen to stream video" | |
| | --A member of the Netflix team |
I was once attending a technical talk when I heard the preceding quote. We're all familiar with Netflix, the streaming service, but to a member of their team, they consider themselves a logging company that just serves video. I think this is a great way of highlighting the importance of logs.
If you're planning on running any application in a production environment, having quality logging is absolutely paramount, as it will be one of your only means of visibility into what is happening in the production environment, or of went wrong if you find a server crashing without explanation. If you've ever had to diagnose a production issue before, you'll exactly understand the importance of having quality logs.
There are some criteria that a good logging system should have; for one, logs must be time-stamped and readable for both us humans and for machines. There is also so much we can ascertain...
Now that we've prepared ourselves for being able to diagnose issues in production, let's also see the tools available in the Node and hapi ecosystem for debugging applications in our development environment.
Coming from a PHP background which had quite a mature debugger, I always found debugging Node applications a bit more difficult to debug due to JavaScript's asynchronous nature. Fortunately, development tooling is improving around this, with more and more development environments being shipped with integrated Node debugging tools. Let's take a quick look at some of the currently available tools as well as some of the hapi-specific tools for debugging your hapi applications.
This is generally every JavaScript developer's go-to when they have an issue. While it works for smaller issues, I wouldn't recommend trying to use this for everything. When it comes to more complex issues, you will want to have some experience with the node debugger.
General production advice
From time to time, I see the question of production setups being asked in GitHub issues as well as in some of the hapi community chat rooms, so I thought I would provide some information here. While Eran published a GitHub gist detailing Walmart's setup (https://gist.github.com/hueniverse/7686452), they were using hapi mainly as a proxy, and I'm pretty sure most production environments won't be at Walmart's scale dealing with events such as Black Friday.
The production setup I see most often with Node, and one that I have used regularly in my own setups, is to have a dedicated web server such as Nginx or Apache to act as the public interface responding to requests on port 80 for HTTP and 443 for HTTPS. I then use these as a reverse proxy to my Node application running hapi. This is so that HTTPS can be handled by the web server terminated prior to reaching the Node hapi-based application, so the Node applications can focus purely on business logic. Often, I have...
Congratulations on getting this far! I won't be covering any new topics in hapi in this book, but hopefully, I've convinced you on hapi as a great choice for your next project or for integrating with a current one. I just wanted to take some time before finishing up to point out some places where you can further your learning on hapi.
Getting started with hapi.js GitHub repo
The first place I would turn to learn more about hapi is the code repository associated with this book. As mentioned in each chapter, all code examples associated with the book are located in a GitHub repository at https://github.com/johnbrett/Getting-Started-with-hapi.js. If you find that any examples were tough to grasp, or would like to explore them in more detail, I recommend cloning the repository and running each example while taking a look at the code. Trying to expand on any of the code examples will be your best source of learning hapi, Node, or coding in general. If you have any further questions...
Congratulations on finishing this book! I hope it has given you a huge amount to think about, and furthered your knowledge of hapi greatly so you can start writing robust and fully-featured applications today.
If you're new to Node, moving on from reading examples and working through pre-defined problems to writing your own applications from scratch can be tough. Don't be disheartened if this is the case—this will come with time as you write more. Moreover, in the previous section I've listed plenty of resources to help you along the way.
In this book, we've covered hapi, the configuration-centric framework that helps rapidly build robust APIs and web applications. We've looked at adding functionality to our applications through adding routes and serving different types of content such as JSON, static files, or rendered templates. We then looked at different methods for structuring applications, using hapi's excellent plugin system. Following that, we explored the different options...
