In this chapter, we're going to look at validation in Node and also at joi, the object schema validator used throughout the hapi framework and its ecosystem.
We have actually already touched on joi in Chapter 2, Adding Functionality by Routing Requests, when we saw a then unfamiliar type description on a request parameter in our route configuration example. However, joi isn't limited to validating request properties, or even to use within hapi. It is a standalone object schema validation library that can be used in any Node application. Before we delve into some joi syntax and examples, let's first explore the topic of validation first.
In pretty much any type of application, we are going to work with data, and of course, we need to ensure that this data is of a certain type or structure before we can act on it. This poses a number of problems. First, how do we easily define the way we want our data to be structured (often referred to as a schema), and second, how can we provide feedback in a consistent manner if the data provided isn't structured the way we want.
As with testing, if it's not easy to write or understand a schema, often, as developers, we won't do it, and instead, resort to very primitive attempts such as:
…
if (typeof username !== 'string') {
// throw or return error
}
// perform action
…First of all, please note that if you find yourself doing this, you're going to have huge problems as your application logic grows. You might have already seen examples of this—massive validation functions for performing actions with different combinations of properties.
This is hugely counterproductive for a number of reasons. Any developer reading this combination of if statements will be none the wiser as to what the expected data should look like, just a list of things that it shouldn't be. Secondly, code like this is hard to maintain. It's hard to read, update, and of course 100% test coverage, the importance of which we looked at in Chapter 5, Securing Applications with Authentication and Authorization, is hard to obtain. As a general rule, I find the need for typeof to be used in business logic a code smell; it should be reserved for libraries.
In practice, I generally try to have the following structure throughout an application:
- Accept objects instead of using multiple parameters to describe any application, that is, 'configuration over code'.
- Any function that accepts an object as a parameter should have a schema for each object, especially if it's a 'public' function, that is, a function exposed by your module, library and so on. This provides both a safety net and documentation for the next developer.
- Validate all inputs by their schema before interacting with any data. This makes for a separation of concerns that leads to a much clearer code.
With the preceding goals in mind, let's now look at joi, and how we might achieve these goals with it.