We could implement user authentication and accounts by simply adding a user model and a few routes and views to the existing Notes application. While that’s easy, is this what is done in a real-world production application?
Consider the high value of user identity information and the super-strong need for robust and reliable user authentication. Website intrusions happen regularly, and it seems the item most frequently stolen is user identities. To that end, we declared earlier an intention to develop a user information microservice, but we must first discuss the technical rationale for doing so.
Microservices are not a panacea, of course, meaning we shouldn’t try to force-fit every application into the microservice box. By analogy, microservices fit with the Unix philosophy of small tools, each doing one thing well, which we mix/match/combine into larger tools. Another word for this is composability. While we can build a lot of useful software tools with that philosophy, does it work for applications such as Photoshop or LibreOffice?
This is why microservices are popular today among application teams. Microservice architectures are more agile if used well. And, as we noted earlier, we’re aiming for a highly secured microservice deployment.
With that decision out of the way, there are two other decisions to be made with regard to security implications. They are as follows:
- Do we create our own REST application framework?
- Do we create our own user login/authentication framework?
In many cases, it is better to use a well-regarded existing library where the maintainers have already stomped out lots of bugs, just as we used the Sequelize ORM (Object-Relational Mapping) library in the previous chapter, because of its maturity. We have identified two libraries for this phase of the Notes project.
We already mentioned using Passport for user login support, as well as authenticating Twitter users.
For REST support, we could have continued using Express, but instead will use Restify (http://restify.com/), which is a popular REST-centric application framework.
To test the service, we’ll write a command-line tool for administering user information in the database. We won’t be implementing an administrative user interface in the Notes application, and will instead rely on this tool to administer the users. As a side effect, we’ll have a tool for testing the user service.
Once this service is functioning correctly, we’ll set about modifying the Notes application to access user information from the service, while using Passport to handle authentication.
The first step is to create a new directory to hold the user information microservice. This should be a sibling directory to the Notes application. If you created a directory named chap08/notes to hold the Notes application, then create a directory named chap08/users to hold the microservice.
Then, in the chap08/users directory, run the following commands:
$ cd users
$ npm init
.. answer questions
.. name – user-auth-server
$ npm install debug@^4.1.x fs-extra@^9.x js-yaml@^3.14.x \ restify@^8.5.x restify-clients@^2.6.x sequelize@^6.x \ sqlite3@^5.x commander@^5.x cross-env@7.x –save
This gets us ready to start coding. We’ll use the debug module for logging messages, js-yaml to read the Sequelize configuration file, restify for its REST framework, and sequelize/sqlite3 for database access.
In the sections to come, we will develop a database model to store user information, and then create a REST service to manage that data. To test the service, we’ll create a command-line tool that uses the REST API.
Source: Herron David (2020), Node.js Web Development: Server-side web development made easy with Node 14 using practical examples, Packt Publishing.