Node.js Backend web service/API. Part 2

Here is the prerequisite for this article. You might want to take a quick glance before jumping on this. You can skip this article if you can go through the source file here and understand everything you need. I know you can.

Architectural decision and design concept.

The focus of the architecture is to prevent repetitions that are always observed when creating a RESTful API. So the mundane function like the CRUD operation among others will be handled by base classes whose child class can choose to override properties or change its configuration hence it can be referred to as a scalable and configurable API.

There are four fundamental components of this which are listed below

1. Route
2. Model
3. Processor
4. Validation
5. Controller

So for simplistic purpose, I will refer to this concept as RMPVC and the diagram below shows a simple illustration of the concept.

Route

The route file will contain all the endpoints associated with a particular collection. it creates an instance of the controller responsible for implementing the functions associated with each endpoint.

In order to properly explain this concept in detail, we start by defining our todo restful API routes matching each method with the required controller functions that will be created as we move further

todo.route.js

todo.controller.js

From the above code snippet, you must be wondering where the create, update, delete, etc. function must have gone to, they did not go anywhere they have been inherited from the app controller so it can override any of the function if it requires a different implementation and can further add more function peculiar to the if the endpoints extend beyond basic resource endpoint.

App Controller:

This is the base controller where all other controllers will extend from. it a model reference as an argument which is further used within the constructor to initialize the translatable language whose default is set in the booted config file, in this case, it is “en” which stands for English. Below is the constructor.

The app controller will implement the basic CRUD function of a resource and it is listed below with their basic function.

1. find: This will find all the resources required and paginate based on the configuration of the pagination property in the config file
2. create: It will create a new resource
3. Id: this collects the id param from the route and retrieves the object match the id and stores the object within the req property as an object.
4. findOne: find one resource given its unique identifier from a query parameter
5. update: update a resource by its unique identifier from a query
6. delete: delete a resource.

app.controller.js

App Model

This is the base schema that every schema must extend. The base schema has two static methods that return the base validation class and base processor class. This class will have the default implementation of their required function and can be overridden by any child class that extends the app model.

app.model.js

The todo model below overrides the getValidator property and returns a todo validation class that extends the app validation. the todo class may just have to override the function that requires a different implementation

todo.model.js

App Validation.

This class specifies validations required for a resource. A child class will be required in order to override the implementation of a particular validation function in the base validation class. So below two functions for validating a payload on the create and update endpoint. Validtor.js is used for the validation rules.

Each of the validation function returns an object with validator or validated keys. The former hold the validator object with the rules defined while the latter is a boolean which is true if the validation on the payload passes.

The todo validation will override the app validation create a function to indicate the validation rules before a new resource is created

app.validation.js

todo.validation.js

App Processor

The basic concept for this is to abstract the core function that is most common within the controller to enable extensibility and maintainability. the functions defined in this class should be overridden only when core concept on the underlying resource is functionally and structurally different. For example, if this model utilizes a different database model like SQL the core functions implemented within the app controller will have to be overridden to maintain the underlying architectural approach. More insight will be further discussed in the subsequent Part 3.

Part 3 will expose the utility classes and objects that were used in this project and illustrate how the entire project fit together. Please comment below and if you have an idea on how I can make this article better. Thanks and see you in the next part