Clock-In/Out System Part 3: Basic Back End (II) — UsersModule

A NestJS + Angular tutorial

Carlos Caballero
Dec 3, 2018 · 7 min read
Image for post
Image for post

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:

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 UsersModule

The service UserService provides two important methods:

  1. getUsersWithoutKey
  2. addUser

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.

Image for post
Image for post
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 (User and UserSchedule).

The module’s file is shown in the following code:

Image for post
Image for post

This module only imports DatabaseModule to connect with our Postgres using TypeORM, and exports the UserService which is used in AppController.

This module defines the controller UserController, which will be used to communicate this module with the exterior.

Entities

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.

Image for post
Image for post

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 Auth and 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.
Image for post
Image for post

The 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:

  • UID The UserSchedule’s UID. This field is automatically generated by the database.
  • day The day of the week in which the user is in the building (0 to 6 is equivalent to Sunday to Saturday).
  • hour The 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).
  • room The space the user is in, in that hour.
  • user The relation between the table UserSchedule and User. Many UserSchedule’s are related to a User.
Image for post
Image for post

Finally, the system is composed of three tables:

  • User Information about the users in the system and their keys.
  • User-Schedule Information about the schedule and rooms the user is in.
  • Auth Information 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_EXCLUDE The list of the scheduler which will be excluded from the list (the user must be in the building).
  • SCHEDULE_HOURS The 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.
Image for post
Image for post

The user.dto file is simple too. In this file, you can see the definition of a class in which two fields are defined (UID and name).

Image for post
Image for post

Controllers

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 /user This method invokes the method getUsersWithoutKey from the service to obtain all users that are not keyed into the system (used to fill the information from a client-side).
  • POST /user This method invokes the method addUser from the service to add the key to a user. In fact, the body of the POST should be a UID and key.
Image for post
Image for post

Services

Finally, the most important part of this module is the service because the logic of the module is inside this file.

The UserService has three important methods:

  • getUsersWithoutKey In this method, the return value is a Promise of UserEntity[] from TypeORM. So, the target of this method is to invoke the correct SELECT sentence using the ORM, which consists in all users with a NULL key value.
  • addUser In this method, the return value is a Promise, which is returned from the method save of TypeORM. So, addUser is a wrapper of TypeORM, which is a wrapper of the INSERT/UPDATE sentence.
  • getUsersWorkingNow This method is not used inside the UsersModule but 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 isMorning which 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 Users returned contains the list of authentications in the day (using lower and upper limits).
Image for post
Image for post

Conclusion

‌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.

The method 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.

Better Programming

Advice for programmers.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store