Node.js Backend web service/API. Part 4

I will recommend looking through the previous part of this article to have a proper understanding. But I may be wrong because we all learn differently. It is just my opinion, and you can skip this article if you can go through the source file here and understand everything you need. I know you can once again.

Implementation of the app controller function

So this part is dedicated to further explain some the implementation of the app controller function and how it all fits together. The two main functions that will be demonstrated here is the create and find function.

Every controller function creates a response key whose value will be used by the response middleware to return value to the client based on the processor getApiClientResponse function called at runtime

Most of the controller function utilizes a processor and a validation object determined by getValidator and getProcessor static function in the model. The signature of the function within this class can be overridden by a child whenever a child class and model function specifies the child class to utilize at run time.

The Create function

Before an object is created it is validated and an error returned if the validation rules failed. If everything goes well the model’s process creates a new object and in this case, it's just a new object

The CreateNewObject function simply extracts the fillable object from a payload, uses it to create a new object and returns the object.

The Find function

An instance query parser is created with the request query as an argument. Here the required properties are created and the functions required are now available. Also, a pagination instance is created with the request URL as an argument.

The buildModelQueryObject is where the magic happens, this processor function is responsible for creating the queries required based on the instance of the query parser and pagination created. It returns the final query promise object and a countQuery object which is used to keep the pagination object updated and consistent.

The find endpoint paginates by default unless specified with a reserved query string key defined within the query parser. The list of reserved keys are

[‘per_page’, ‘page’, ‘limit’, ‘sort’, ‘all’, ‘selection’, ‘population’, ‘search’];

I will explain the purpose of three of the keys

• The ‘all’ key set as true returns unpaginated result. as mostly required for resources that need to be shown within a drop down or are limited
• The ‘population’ is specified when an attribute that is a reference of another collection needs to the populated as an object. the syntax adopted is the same as the mongoose population schema.
• The ‘search’ key is used to find any resource that matches the value based on the attribute of the model specified in the model searchQuery function.

This functions and capabilities of the buildModelQueryObject function can be extended or overridden to by any child class which could include more robust implementation.

The next screenshot will be a combination of most of the reserved keywords and the returned payload

The app controller function can be overridden by the Todo controller if any of the function has a different implementation. And some of the endpoint can be omitted if it is not required for a particular resource

I hope this article was able to help give a basic concept to what can be further extended to meet more complex needs without sacrificing code quality and fundamental architecture.

More to come.

Authentication endpoint and controller function. it will adopt the structural implementation of this project and further implement most authentication controller functions such as login, register, verify code and link and password-reset, etc.

Thanks for reading and hope to get constructive criticism on how to better improve the concept which is actually the focus and aim of this article.