Clock-In/Out System Part 3: Basic Back End (II) — UsersModule
A NestJS + Angular tutorial
This piece is part of a series in which I describe a clock-in/out system. If you want to learn more, you can read the following:
- Clock-In/Out System Part 1: Diagram
- Clock-In/Out System Part 2: Basic Back End — AuthModule
- Clock-In/Out System Part 3: Basic Back End — UsersModule
- Clock-In/Out System Part 4: Basic Back End — AppModule
- Clock-In/Out System Part 5: Seed Database and Migration Data
- Clock-In/Out System Part 6: Basic Front End
- Clock-In/Out System Part 7: Deploy Back End (NestJS) Using Docker/Docker-Compose
- Clock-In/Out System Part 8: Deploy Front End (Angular 6+) Using Environments
- Clock-In/Out System Part 9: Back-End Testing — Unit Testing of Services
- Clock-In/Out System Part 10: Back-End Testing — Unit Testing of Controllers
- Clock-In/Out System Part 11: Back-End Testing — E2E Testing
- Clock-In/Out System Part 12: Front-End Testing — Unit Testing
- Clock-In/Out System Part 13: Front-End Testing — Integration Testing
In the previous post, I presented the basic back-end structure and the first module (
AuthModule). I recommend that you read that post before this one so that you can understand the whole system. This post will present the
UsersModule, which is used to manage user information.
Managing User Information With
UserService provides two important methods:
These methods are used to find out if a user doesn’t have a valid ID card and to add a user to the system.
The first step is to show the structure of the files of the
UsersModule, which is shown in figure 1.
In the development of this module, we’ve used the same directory structure as the one in
AuthModule but we have a new directory called
controllers, which is used to communicate this module with the exterior using a RESTful API.
Furthermore, you can see two entities because, in this module, we need two tables (
The module’s file is shown in the following code:
This module defines the controller
UserController, which will be used to communicate this module with the exterior.
In this module, we need to use two entities:
User: This entity defines the user information.
Scheduler: This entity defines the scheduler of the user (which is a weak-entity).
So, the first step to define the entities is to define the provider which allows the use of
UserRepository in our services by injection.
The first entity is the user, which is defined by the following fields:
uid: UID of the user. In this case, a string of the “surname, name” of the user.
name: Name of the user. This field is used to show the name on a screen.
auth: That’s the relation between the tables
Users. This field is a list of authentications of the users.
key: The key which is assigned to a user.
schedule: This is one of the most important fields because it is the relation between the user and their schedule. The second entity of the user’s module is that.
UserSchedule entity is used to reflect each session where the user must be in the building. The fields that are stored in this table are the following:
UserSchedule’s UID. This field is automatically generated by the database.
dayThe day of the week in which the user is in the building (0 to 6 is equivalent to Sunday to Saturday).
hourThe hour of the day that the user is in the building (from 0 to 11 is equivalent to from 8:15 to 22.10, but the relation is not linear. However, there is a function that does that task).
roomThe space the user is in, in that hour.
userThe relation between the table
UserSchedule’s are related to a
Finally, the system is composed of three tables:
UserInformation about the users in the system and their keys.
User-ScheduleInformation about the schedule and rooms the user is in.
AuthInformation about the clock-in/out (including the timestamp).
Constants and DTOs
The next section is easy, as in the previous post. In this section, we define the constants and DTOs to obtain a better code.
The constants are used to clean the code of strings or numbers, while DTOs are used to validate the user from the client-side.
In the file
user.constants.ts, you can see several arrays:
SCHEDULE_EXCLUDEThe list of the scheduler which will be excluded from the list (the user must be in the building).
SCHEDULE_HOURSThe different hours to start and end the session of the user.
- Several constants to export formats of moments, or the first and last hour in different work shifts.
user.dto file is simple too. In this file, you can see the definition of a class in which two fields are defined (
Now is the moment to introduce the user’s controller.
In this file, you can see that the controller is called
user and two verbs are used:
GET /userThis method invokes the method
getUsersWithoutKeyfrom the service to obtain all users that are not keyed into the system (used to fill the information from a client-side).
POST /userThis method invokes the method
addUserfrom the service to add the key to a user. In fact, the body of the
POSTshould be a UID and key.
Finally, the most important part of this module is the service because the logic of the module is inside this file.
UserService has three important methods:
getUsersWithoutKeyIn this method, the return value is a Promise of
UserEntityfrom TypeORM. So, the target of this method is to invoke the correct
SELECTsentence using the
ORM, which consists in all users with a
addUserIn this method, the return value is a Promise, which is returned from the method save of TypeORM. So,
addUseris a wrapper of TypeORM, which is a wrapper of the
getUsersWorkingNowThis method is not used inside the
UsersModulebut is used from
AppController. This method returns a Promise of
UsersEntity, which is composed of all users that are in the building at this moment. This method uses the library Moment.js. It would be done in “bad code”, with a lot of code smell, but I’ve preferred using several variables to clean the code. Furthermore, I’ve used a private function
isMorningwhich allows me to know if the system is in the morning or the afternoon. That’s because there are several users that are in the building for several hours in the morning and several hours in the afternoon. The
Usersreturned contains the list of authentications in the day (using lower and upper limits).
In this piece, I’ve explained my
UsersModule , which is very simple because I’m using clean code in my coding.
This module is used to save information about users and clock-in/out.
getUsersMustBeWorkingNow is the main method of the system because this method returns the list of users that must be in the building using several constraints. These constraints are easily customizable.
In the following post of this series, I’m going to explain the
AppModule, which communicates the client-side with the server-side and the modules of the server-side between them.
- The GitHub of this project is https://github.com/Caballerog/clock-in-out
- The GitHub branch of this piece is https://github.com/Caballerog/clock-in-out/tree/part3-basic-backend-users