W dokumentacji NestJS możemy znaleźć następujące zdanie:

“Nest provides an out-of-the-box application architecture which allows developers and teams to create highly testable, scalable, loosely coupled, and easily maintainable applications”

Przetestujmy tą tezę przez sprawdzenie czy NestJS pozwala na łatwe postępowanie zgodnie z jedną z zasad SOLID – z Zasadą Odwrócenia Zależności!

NestJS jest silnie inspirowany Angularem, dlatego wszystkie rady z tego artykułu działają także w Angular.

Dla szybkiego przypomnienia, Zasada Odwrócenia Zależności mówi że:

Wysokopoziomowe moduły nie powinny zależeć od niskopoziomowych modułów. Powinny zależeć od ich abstrakcji (np. interfejsów).
Abstrakcja nie powinna zależeć od szczegółów. Szczegóły (konkretna implementacja) powinna zależeć od abstrakcji.

Podczas implementacji DIP będziemy korzystać z wbudowanego w NestJS i Angular mechanizmu Wstrzykiwania Zależności (DI). Jest on kluczowy, aby w naszym wysokopoziomowym module otrzymać odpowiedni serwis niższego poziomu. Nie będziemy się jednak dokładnie zagłębiać w sposób działania DI, a jedynie skupimy się na tym jak wykorzystać go w implementacji DIP.

Przykład

Aby wyjaśnić sposób implementacji DIP rozważmy najpierw następujący przykład.
Tworzymy aplikację, która będzie analizować dane o naszych repozytoriach na platformie Github. Naszym aktualnym zadaniem jest zaimplementowanie endpointa, który będzie zwracał liczbę aktywnych pull requestów dla danego repozytorium.

Podaną funkcjonalność można szybko zaimplementować w przedstawiony poniżej sposób, jednak nie jest ona zgodny z naszą zasadą.

import { Controller, Get, HttpModule, HttpService } from '@nestjs/common';

import { Observable } from 'rxjs';

import { map } from 'rxjs/operators';

import { PullRequest } from 'app/domain';

@Controller()

export class AppController {

constructor(private http: HttpService) {}

@Get('repository/:id/pending-prs')

getNumberOfPendingPrs(id: string): Observable<number> {

return this.http

.get<PullRequest[]>(`https://api.github.com/repos/${id}/pulls`)

.pipe(map(res => res.data.length));

}

Nawet przeniesienie zapytania HTTP do dedykowanego serwisu nie jest wystarczającą drogą, aby ukryć implementację przed kontrolerem.

import { Controller, Get, HttpService } from '@nestjs/common';

import { Observable } from 'rxjs';

import { map } from 'rxjs/operators';

import { GithubService } from 'app/infrastructure';

@Controller()

export class AppController {

constructor(private githubService: GithubService) {}

@Get('repository/:id/pending-prs')

getNumberOfPendingPrs(id: string): Observable<number> {

return this.githubService.getPullRequests(id).pipe(map(prs => prs.length));

}

import { HttpService, Injectable } from '@nestjs/common';

import { Observable } from 'rxjs';

import { map } from 'rxjs/operators';

import { PullRequest } from 'app/domain';

@Injectable()

export class GithubService {

constructor(private http: HttpService) {}

getPullRequests(id: string): Observable<PullRequest[]> {

return this.http

.get<PullRequest[]>(`https://api.github.com/repos/${id}/pulls`)

.pipe(map(res => res.data));

}

Implementacja DIP

Prawidłowa implementacja powinna wyglądać następująco:

import { Controller, Get } from '@nestjs/common';

import { Observable } from 'rxjs';

import { map } from 'rxjs/operators';

import { RepositoryService } from 'app/interfaces';

@Controller()

export class AppController {

constructor(private repositoryService: RepositoryService) {}

@Get('repository/:id/pending-prs')

getNumberOfPendingPrs(id: string): Observable<number> {

return this.repositoryService

.getPullRequests(id)

.pipe(map(prs => prs.length));

}

import { Module } from '@nestjs/common';

import { AppController } from './app.controller';

import { GithubInfrastructureModule } from 'app/infrastructure-github';

@Module({ imports: [GithubInfrastructureModule], controllers: [AppController] })

export class AppModule {}

import { HttpModule, Module } from '@nestjs/common';

import { RepositoryService } from 'app/interfaces';

import { GithubRepositoryService } from './github-repository.service';

@Module({

imports: [HttpModule],

providers: [

{ provide: RepositoryService, useClass: GithubRepositoryService }

exports: [RepositoryService]

})

export class GithubInfrastructureModule {}

import { HttpService, Injectable } from '@nestjs/common';

import { Observable } from 'rxjs';

import { map } from 'rxjs/operators';

import { PullRequest } from 'app/domain';

import { RepositoryService } from 'app/interfaces';

@Injectable()

export class GithubRepositoryService implements RepositoryService {

constructor(private http: HttpService) {}

getPullRequests(id: string): Observable<PullRequest[]> {

return this.http

.get<PullRequest[]>(`https://api.github.com/repos/${id}/pulls`)

.pipe(map(res => res.data));

}

import { Observable } from 'rxjs';

import { PullRequest } from 'app/domain';

export abstract class RepositoryService {

abstract getPullRequests(id: string): Observable<PullRequest[]>;

}

Musimy stworzyć warstwę abstrakcji dla pobierania kolekcji pull requestów. Ta abstrakcja jest osiągnięta przez klasę abstrakcyjną RepositoryService.
Do AppControler próbujemy wstrzyknąć coś ukrytego za injection tokenem RepositoryService
GithubInfrastructureModule mówi nam, że w to miejsce powinna być wstrzyknięta klasa GithubRepositoryService.

Ok, ale dlaczego nie używamy zwykłego interfejsu jako warstwa abstrakcji?
Odpowiedzią jest to co się dzieje z interfejsami podczas procesu transpilacji z TypeScript do JavaScript. Problemem jest to, że tracimy wszystkie informacje o istnieniu interfejsu RepositoryService, o tym co powinno być wstrzyknięte do AppController. Właściwie to nie można użyć interfejsu jako wartość pola “provide” przy definiowaniu dostawców modułu.
Sytuacja jest zupełnie inna jeśli użyjemy klasy. Nawet klasa abstrakcyjna po transpilacji pozostanie zwykłą klasą, która może zostać użyta jako Injection Token. W Typescript klasa może implementować inną klasę tak samo jak interfejs.

Dlaczego to jest takie istotne?

Powiedzmy że wymagania naszej aplikacji się zmieniły. Musimy także wspierać repozytoria na platformie Bitbucket na dedykowanej instancji aplikacji.

Jeśli nie przygotowalibyśmy się na to wcześniej, teraz musielibyśmy dodać wiele warunków w naszych serwisach i kontrolerach, aby wykonać odpowiednie zapytania HTTP po potrzebne dane.

Z elegancko ukrytą warstwą dostępu do danych możemy po prostu stworzyć dedykowany moduł z serwisami dla Bitbucketa i odpowiednia zaimportować go w module z naszą funkcjonalnością:

import { Module } from '@nestjs/common';

import { AppController } from './app.controller';

import { GithubInfrastructureModule } from 'app/infrastructure-github';

import { BitbucketInfrastructureModule } from 'app/infrastructure-bitbucket';

@Module({

imports: [

...(process.env.provider === 'GITHUB' ? [GithubInfrastructureModule] : []),

...(process.env.provider === 'BITBUCKET' ? [BitbucketInfrastructureModule] : [])

controllers: [AppController]

})

export class AppModule {}

Teraz do AppController zostanie wstrzyknięty GithubRepositoryService lub BitbucketRepositoryService zależnie od środowiska.

Dobrymi przykładami gdzie ma to swoje zastosowanie w aplikacji napisanej w Angular są sytuacje gdy:

tworzymy aplikację webową oraz mobilną i wyróżniają się sposobem pobierania danych
tworzymy aplikację z SSR i przy pobieraniu danych po stronie serwera chcielibyśmy dodatkowo ustawić je w TransferState, a po stronie przeglądarki chcemy je stamtąd pobrać.

W obu tych przypadkach postępowanie zgodnie z Zasadą Odwrócenia Zależność tak jak było to opisane powyżej pomoże nam w implementacji i ograniczy zmiany oraz logikę w wysokopoziomowych modułach, które wykorzystują naszą warstwę dostępu do danych.

Podsumowanie

Postępowanie zgodnie z Zasadami SOLID daje nam mnóstwo korzyści. Powoduje że nasza aplikacja staje się łatwiej reużywalna, utrzymywalna, skalowalna, testowalna i wiele więcej. NestJS i Angular pozwalają nam na używanie ich w łatwy i elegancki sposób.

Jeśli interesuje Cię sposób w jaki możemy wykorzystywać GithubRepositoryService i BitbukcetRepositoryService w tej samej instancji aplikacji, zajrzyj tutaj.

Reasumując, tezę z dokumentacji NestJS można uznać za prawdziwą!

Jak postępować zgodnie z Zasadą Odwrócenia Zależności (DIP) w NestJS i Angular

Przykład

Implementacja DIP

Dlaczego to jest takie istotne?

Podsumowanie

O autorze

Dodaj komentarz Anuluj pisanie odpowiedzi