DEV Community: Amro

Building Extendable Generic Nestjs Controller

Amro — Fri, 14 Oct 2022 09:29:52 +0000

When I was working with the Django rest framework, there was a class called ModelViewSet, just inheriting this class and specifying your database model name, all the CRUD endpoints would be created for you automatically. I really liked this idea as it gives you consistency look to your API, less code has to be written and finally lets you focus more on the business logic.

This article will provide implementation to a generic class that when it is extended will provide similar functionality to ModelViewSet.

In order to do that TypeORM library is used, as our model library. As an example, I will do the classic Article model and will show how I will do the endpoints for it, as the model would be:



@Entity('article')
export class ArticleEntity extends BaseEntity {
  @PrimaryGeneratedColumn({ name: 'article_id' })
  articleId: number;

  @Column()
  title: string;

  @Column()
  body: string;
}

The controller of this model with a GET endpoint would be normally like this:



@Controller({ path: 'article' })
class ArticleController {
 constructor(
   @InjectRepository(ArticleEntity)
   protected readonly repository: Repository<ArticleEntity>,
  ) {}
  @Get(':id')
  async get(@Param('id', ParseIntPipe) id: number):
  Promise<ArticleEntity> { 
   return this.repository.findOne({ where: { articleId: id } });
  }
}

Now we have to create an abstract generic class with a GET function, I will call it EndPointSet, and it would look like this without implementation:



abstract class EndPointSet<T extends BaseEntity> { 
  protected abstract readonly repository: Repository<T>;
  @Get(':id')
  async get(@Param('id', ParseIntPipe) id: number): Promise<T> {
    // IMPLEMENTATION HERE, KEEP READING ^^
  }
}

But now we have a problem, each different model would have a different id field name, so we can not use the findOne method, luckily Typeform provides the findOneById method, which needs only the id value, not its name, so the method implementation would be:



return this.repository.findOneById(id);

And now we can inherit the EndPointSet not only in the ArticleController but any controller as follows:



@Controller({ path: 'article' })
export class ArticleController extends EndPointSet<ArticleEntity> {
  constructor(
  @InjectRepository(ArticleEntity)
     protected readonly repository: Repository<ArticleEntity>,
  ) {super();}
}

The other endpoints will be similar to what we did in the Get function, so the final class at the end would be like that:



abstract class EndPointSet<T extends BaseEntity> {
  protected abstract readonly repository: Repository<T>;
  @Get(':id')
  async get(@Param('id', ParseIntPipe) id: number): Promise<T> {
    return this.repository.findOneById(id);
  }

  @Get('list')
  async list(): Promise<T[]> {
    return this.repository.find();
  }

  @Post()
  async post(@Body() dto: DeepPartial<T>): Promise<T> {
    return this.repository.save(dto);
  }

  @Delete()
  async delete(@Param('id', ParseIntPipe) id: number): Promise<void> {
    this.repository.delete(id);
  }

  @Patch(':id')
  async update(
    @Param('id', ParseIntPipe) id: number,
    @Body() dto: QueryDeepPartialEntity<T>,
  ): Promise<void> {
    this.repository.update(id, dto);
  }
}

So yeah that is it, we now made our generic controller with all the CRUD endpoints. That is it for the first part, in the next part, I will do more work on the list function, in order to do pagination, ordering, filter.. etc. So follow for more ^^.

Implementing Onion architecture in NestJS

Amro — Thu, 18 Nov 2021 10:52:44 +0000

What’s Onion architecture?

As shown in the picture, onion architecture is a way to structure the code by dividing it into domain-driven design layers. each layer can only access the layer below it throw its interfaces, and then using the dependency inversion principle each interface will be replaced with its class.

Onion Architecture leads to more maintainable applications since it emphasizes separation of concerns throughout the system.” Jeffery Palermo

Why apply Onion Architecture in NestJs projects?

NestJs is a service-side framework based on NodeJs. NestJs has many built-in features but most importantly for us now is the Dependency Injection and the possibility to add Dependency inversion which is what we need to apply the Onion Architecture.

Building simple server-side Blog:

In the rest of the article, I’ll try to explain the NestJs implementation using a simple blog project.

I’ll assume most of the article readers already know Nestjs so I’ll focus on the architecture in the code example.

Project layers in NestJs

Domain entities: in the core of our application we have the domain, according to the Domain-driven design(DDD), we should focus our implementation around our Domain and all other layers are built around it.

In our case, the Domain Entity is just the Article, so let’s do its interface:




export interface IArticle {
  id: number;
  body: string;
  title : string;
}

Repository: is the layer that participates in the Domain Entity, like getting or deleting entity object but it has to abstract away database and infrastructure details, so it’ll work with any kind of database.

so let’s build ArticleRepository:



export interface IArticleRepository {
  get(id: number): Promise<IArticle>;
  delete(id: number): Promise<void>;
  save(input: IArticle): Promise<void>;
  update(input: IArticle): Promise<IArticle>;
}

As the Repository interface most likely will have the same functions for all Entities as it should mainly perform these abstract functions, I recommend using Generics that takes the Entity type as parameter to have general Repository



export interface IRepository<T> {
  get(id: number): Promise<T>;
  delete(id: number): Promise<void>;
  save(input: T): Promise<void>;
  update(input: T): Promise<T>;
}

Service: here we implement the use cases, it participates in the Repository to get the data it needs

in our case we need a service to get an article by id and count article characters:



export interface IArticleService {
  getArticle(id: number): Promise<IArticle>;
  getArticleLength(id: number): Promise<number>;
}

Controller: for the sake of simplification I made the controller the first layer, hence NestJs is a server-side framework. But normally in literature first layer suppose to be the UI or test.

As Controller is our first layer and we won’t use it as dependencies somewhere else so no need to write an interface for it and we can implement it directly.



import { Controller, Get, Param } from '@nestjs/common';
import { IArticle } from './article.interface';
import { IArticleService } from './articleService.interface';

@Controller({ path: 'article' })
export class ArticleController {
  constructor(private readonly service: IArticleService) {}

  @Get(':id')
  async article(@Param() params): Promise<IArticle> {
    return this.service.getArticle(params.id);
  }
}

So are we done?

ofc not yet, we just wrote the interfaces but still didn’t write the actual implementation of them, and then replace the interface with the class in the run time.
In the rest of the article, I’ll implement one of the Classes(ArticleService) and the rest will be the same.

Implementing ArticleService




@Injectable()
export class ArticleService implements IArticleService {
  constructor(
private readonly repository: IRepository<IArticle>) {}

  async getArticleLength(id: number) {
    const article = await this.repository.get(id);
    return article.body.length;
  }

  getArticle(id: number) {
    return this.repository.get(id);
  }
}

must add @Injectable() so NestJs can inject it later in a class as dependency.
the class implements the interface to make sure the class has the same functions
as we see here ArticleService has dependencies like the Controller but this time its dependency is IRepository

Dependency inversion( replacing the Interface by the Class):

In the ArticleModule we can specify a string token for each class and use this token when we use the class as a dependency.

so let’s apply that with ArticleService, giving it a token in ArticleModule:



@Module({
  controllers: [ArticleController],
  providers: [
    {
      provide: 'ARTICLE_SERVICE_TOKEN',
      useClass: ArticleService,
    },
  ],
})
export class ArticleModule {}

and using this token in the Controller to get the Class in run it:




@Controller({ path: 'article' })
export class ArticleController {
  constructor(
    @Inject('ARTICLE_SERVICE_TOKEN')
    private readonly service: IArticleService,
  ) {}
  ...
}

Note: as strings are bound to errors, it’s best practice to assign the token string to a const variable and export it from the IArticleService file and then use it instead of the string directly:



export const ARTICLE_SERVICE_TOKEN = 'ARTICLE_SERVICE_TOKEN';

export interface IArticleService {
  getArticle(id: number): Promise<IArticle>;
  getArticleLength(id: number): Promise<number>;
}

— that’s it 🎉 now imagine if we needed to change any class, we’ll just add the new class to the useClass parameter in the Module without having to change the controller implementation.

Don’t be so radical about it:

In the end, Onion architecture was made to make the development process easier, so don’t try to force it everywhere where it does not make much sense due to some libraries limitation or other reasons.

Thanks for writing till the end and wish we meet in another article. take care!