Forem: adarsh04

How to configure modules in a NestJS project

adarsh04 — Sun, 14 Jan 2024 01:20:04 +0000

NestJS has a defined structure on how to configure your modules. Whenever you misconfigure this step, then you tend to get a frustrating error like the one below:

In this article, I will run you through how I configured modules for my pet project to give you an insight into how everything works and help you overcome errors such as the above.

The gist of my project is that users can sign up for the app and view recipes: a database stores recipes and users.

Starting with I have defined an app.module.ts below:

@Module({
 imports: [
   AuthModule,
   UsersModule,
   MongooseModule.forRoot(process.env.MONGODB_STORE_URI || 'mongodb://localhost/Meal'),
   RecipesModule
 ],
})

My app.module.js is the root module that Nest.js leverages to build the internal structure of the application, the modules, and the providers stemming from the modules and the relationships between them. I have defined them in the imports list because this is where we grab the providers from the modules needed in this module to build the application's internal structure. The modules include the ones I have defined: AuthModule, UsersModule, RecipesModule, and the 3rd-party module MongooseModule, which we use to establish a connection to the database.

Now, let's move on to one of the modules in the imports list, the recipe Module, to understand how to configure an individual module.

@Module({
 imports: [MongooseModule.forFeature([{ name: Recipe.name, schema: RecipeSchema }])],
 controllers: [RecipeController],
 providers: [RecipeService, Recipe]
})

The imports, by definition, are the providers stemming from the modules we use in this module. We have a MongooseModule.forFeature here to register the Recipe Model.

We have a key for controllers. It, by definition, is for just the controllers used in this module.

Next, the providers: I have defined RecipeService and Recipe here. The reason is that providers, by definition, are those we want to share, at least across this module. I inject the recipe model into the Recipe service. And the Recipe Service is injected into my controller. Hence, they need to be part of the providers.

@Injectable()
export class RecipeService {
   constructor(@InjectModel(Recipe.name) private recipeModel: Model<Recipe>)
   { }

@Controller('/api/v1')
export class RecipeController {
   constructor(private readonly recipeService: RecipeService
   ) { }

Now, let's move on to the Users module.

@Module({
 imports: [MongooseModule.forFeature([{ name: User.name, schema: UserSchema }])],
 providers: [UsersService, User],
 exports: [UsersService]
})

We have already discussed the reason for providers; they need to be used by just this module, UsersService and User.
Interestingly, now we have a key for exports, which has UserService as an item in its list. The exports are the subset of the providers that should be available in other modules that import this module.
Let's review another module, AuthModule, to elaborate on why we have exports listed this way.

 imports: [
   UsersModule,
   JwtModule.register({
     global: true,
     secret: process.env.JWT_SECRET || jwtConstants.secret,
     signOptions: { expiresIn: '60s' },
   }),
 ],
 providers: [AuthService],
 controllers: [AuthController]

If we look at the imports list, we have an item for the UsersModule. Further, going deeper into the AuthService:

@Injectable()
export class AuthService {
 constructor(
   private usersService: UsersService,
   private jwtService: JwtService
 ) {}

We are injecting the usersService into the constructor.

I hope this article will help you configure your modules for your own NestJS projects; feel free to leave any comments in the form of feedback.

References
1: https://docs.nestjs.com/modules

Javascript callbacks

adarsh04 — Thu, 14 Dec 2023 03:49:47 +0000

This post intends to figure out how to use Javascript callbacks by understanding how they are used in various Javascript libraries.

Let’s start with the simple setTimeout function. If we consider the code below

 const startTimer = (printAction) => {
    setTimeout(printAction, 3);
 };

 const printAction = () => {
    console.log('print Action');
 }

startTimer(printAction);

We are passing another function (printAction) into setTimeout. setTimeout will then call this function once the timer has finished. The printAction function that is called is a callback.

Since the term callback is used, let’s consider this an analogy to a phone call. We make a phone call to setTimeout and inform it of the callback details, i.e. printAction. setTimeout hangs up the phone, waits till the timer is done and then calls us back with printAction.

Let’s consider another use of callbacks in the example below with the readFile function in the node.js file system to realise a significant advantage of callbacks.

import { readFile } from 'node:fs';

readFile('/etc/passwd', (err, data) => {
  if (err) throw err;
  console.log(data);
});

The readFile function takes in the file it needs to read and a callback. The callback is an arrow function with err and data as params. Once readFile is done, it calls the arrow function (callback). We then throw an error if err is present or log the data.

The advantage is that the file is read asynchronously, which is essential in the Javascript world. The main program can continue to execute and respond to other events, whilst the readFile will execute asynchronously and inform us about the results via a callback.

Feel free to suggest anything in the comments section to improve someone’s understanding of callbacks.

References:

https://developer.mozilla.org/en-US/docs/Web/API/setTimeout 2.https://nodejs.org/api/fs.html#fsreadfilepath-options-callback

How to use Async/Await in place of Promises

adarsh04 — Fri, 08 Dec 2023 05:55:48 +0000

In this post, I will teach you how to async and await in place of promises. It took me a while to grasp the concepts of async/ await, and I hope you can catch the idea in a few short minutes by reading my article :D

Promises are a way to handle asynchronous operations in the Javascript world. Whenever a long-running task is being run, the method to await the results and still carry out the other functions is to use Promises.

Let us consider a system with a long-running task (returning data from a database), and we need to print out the results to the screen.

The code below leverages Promises to achieve this.

function longRunningTask() {

  return new Promise((resolve, reject) => {
    const data = db.getAllData();
    if (data) {
      resolve(data);
    }
    reject('Error')
  });
}

longRunningTask()
  .then((data) => console.log(data))
  .catch((e) => console.log(e));

Conceptually, I shall use the diagram below to map out different parts of the code here.

The long-running task will return a promise whose result is still pending. Once it is resolved, it will output the results.

Now, let’s leverage async/await to do the above operation.

async function longRunningTask() {
  try {
    return await db.getAllData();
  } catch(e) {
    console.log(e);
  }
}

async function currentTask() {
  try {
    const data = await longRunningTask();
    console.log(data)
  } catch(e) {
    console.log(e);
  }
}

currentTask();

Let's depict what’s going on above with a diagram.

As you can see, I have removed the need to return a Promise (with resolve and reject) in the long-running task. Instead, I marked the long-running task as async and then marked the data returned from the DB with an await keyword.

Similarly, I marked the current task as async and the results returned from the long-running task with an await, rather than calling the Promise then method.

The significant advantage of using async + await is that the code is much easier to follow for someone who isn’t an expert on Promises. It tells us what is an async operation and what data we are waiting for. I’ve also found it much faster to code with async + await due to its simpler syntax.

Feel free to leave any comments in the form of feedback.