Chapter 7. Modularizing Our Code

In the previous chapter, we followed a TDD workflow and implemented the first endpoint of our API—the Create User endpoint. We wrote our End-to-End (E2E) tests in Gherkin, ran them using the Cucumber test runner, and used them to drive development. Everything works, but all the code is contained within a single, monolithic file (src/index.js); this is not modular and makes our project hard to maintain, especially as we add more endpoints. Therefore, in this chapter, we will be separating our application code into smaller modules. This will allow us to write unit and integration tests for them in Chapter 8, Writing Unit/Integration Tests.

By following this chapter, you will be able to do the following:

• Break down large blocks of code into smaller modules
• Define and validate JavaScript objects with JSON Schema and Ajv

Modularizing our code

If you take a look inside the src/index.js file, you'll see that there are three top-level middleware functions—checkEmptyPayload, checkContentTypeIsSet, and checkContentTypeIsJson—as well as an anonymous error handler function. These are prime candidates that we can extract into their own modules. So, let's get started!

Modularizing our middleware

Let's carry out this refactoring process in a new branch called create-user/refactor-modules:

$ git checkout -b create-user/refactor-modules

 

Then, create a directory at src/middlewares; this is where we will store all of our middleware modules. Inside it, create four files—one for each middleware function:

$ mkdir -p src/middlewares && cd src/middlewares
$ touch check-empty-payload.js \
  check-content-type-is-set.js \
  check-content-type-is-json.js \
  error-handler.js

Then, move the middleware functions from src/index.js into their corresponding file. For example, the checkEmptyPayload function should be moved to src...

Adding a user profile

If we look back at our requirements for creating a user, there's one that is still unfinished – "The user may optionally provide a profile; otherwise, an empty profile will be created for them". So, let's implement this requirement!

Writing a specification as a test

We will begin development by first writing E2E tests. In the previous chapter, we already tested a scenario where the profile is not supplied. In these new E2E tests, we will add two more scenarios where the client provides a profile object—one using an invalid profile, the other a valid one.

Therefore, we must first decide what constitutes a valid profile; in other words, what should the structure of our profile object be? There are no right or wrong answers, but for this book, we will use the following structure:

{
  "name": {
    "first": <string>,
    "last": <string>,
    "middle": <string>
  },
  "summary": <string>,
  "bio": <string>
}

All of the fields are optional, but if...

Summary

In this chapter, we have broken up our monolithic application into many smaller modules, and implemented all the requirements for our Create User feature. We integrated JSON Schema and Ajv into our validation modules, which forced us to be more consistent with the structure of our error messages. This, in turn, improves the experience of our end users.

In the next chapter, we will use Mocha and Sinon to write unit and integration tests, which will strengthen the confidence we have in our code.