bookshelf

An exercise on making REST API server using hapi.

Some notable things about this project:

Took hapipal as its starting point which provides:
- Clear separation between server configuration and deployment code (lives inside server directory), and application code (lives inside lib directory)
- Good default server configuration, changes were only made to allow CORS, modify port number, and strip trailing slash on route path
- Automatic routes registration, by creating new JavaScript file inside lib/routes directory, write and then export our route object from it
- Custom ESLint rules for code style consistency
Heavily utilizes joi to validate incoming and outgoing data, which should cover:
- The requirements explained in the submission page
- Even stricter rules focusing on opinionated view of what's considered as valid data type and value needed to make consistent API responses, such as:
  - Excluding - and _ from the return function that is used for generating random id to avoid potential issues by customizing the default nanoid function
  - Allow multiple query parameters to filter out books list, so for example if a user were to send GET request to /books?name=een&finished=0&reading=1, the handler will return books that meet all three of those criteria ^{[1] dunno why no one's doing this, i thought it's common understanding when you're working with query params, expect them to be used together [2] single query will also work, or you can combine one with another, or don't use at all [3] and that's the whole point, you should be ready for all the possibility [4] check out how it's done, i'm especially pleased with how it turned out}
  - See all in lib/data/books/schema.js
The implication of doing strict validation upfront using joi is that we're able to write a lean business logic inside method handler on each route object, because by that time we already know for sure we're working with valid data
Uses boom to spit out HTTP-friendly error message

imsyf/bookshelf

bookshelf