퍼미션(permission), 롤(role), ACL(Access Control List)와 같은 개념을 사용하여 유저가 가지고 있는 속성으로 사용을 허용할지 판별
보통 가드로 구현
💡 인가를 미들웨어가 아닌 가드로 구현하는 이유는 무엇일까 ? 미들웨어는 실행 콘텍스트에 접근하지 못하고,작업완료 후 next() 호출함으로 다음 어떤 핸들러가 실행되는지 알 수가 없습니다. 하지만 가드는 실행 컨텍스트 인스턴스에 접근할 수 있어 다음 실행될 작업을 알고 있기 때문입니다.
JwtGuard와 Strategy
Express 메서드로서의 미들웨어는 NestJS에도 존재하는데 즉, Express 미들웨어의 의미에서 일반적인 미들웨어가 아닙니다.
AuthGuard() #canActivate()는 적절한 PassportStrategy를 호출하게 됩니다.
(Passport의 코드를 읽는 것은 훨씬 더 혼란스럽기 때문에 원할 때 실행할 수 있습니다.)
canActivate() 메서드에 몇 가지 논리를 추가하려면 super.canActivate(context)를 호출하여 원래의 canActivate() 메서드를 호출할 수 있습니다. 결국 Passport.authenticate()를 호출하여 <Strategy>#validate를 호출할 수 있습니다.
@Injectable()
export class CustomAuthGuard extends AuthGuard('jwt') {
async canActivate(context: ExecutionContext): Promise<boolean> {
// custom logic can go here
const parentCanActivate = (await super.canActivate(context)) as boolean; // this is necessary due to possibly returning `boolean | Promise<boolean> | Observable<boolean>
// custom logic goes here too
return parentCanActivate && customCondition;
}
}
NestJS는 효율적이고 확장 가능한 Node.js 서버측 애플리케이션을 구축하기 위한 프레임워크입니다. Express 또는 Fastify 프레임워크를 래핑 하여 동작합니다. (기본으로 설치하면 Express를 사용합니다.) OOP (객체 지향 프로그래밍 Object Oriented Programming), FP (함수형 프로그래밍 Functional Programming) 및 FRP (함수형 반응형 프로그래밍 Functional Reactive Programming) 요소를 결합합니다.
NestJS의 특징
NestJS는 Angualr로부터 영향을 많이 받았습니다. 모듈/컴포넌트 기반으로 프로그램을 작성함으로써 재사용성을 높여줍니다.
IoC(Inversion of Control, 제어 역전), DI(Dependency Injection, 의존성 주입), AOP(Aspect Oriented Programming, 관점 지향 프로그래밍)와 같은 객체지향 개념을 도입하였습니다.
프로그래밍 언어는 타입스크립트를 기본으로 채택하고 있어 타입스크립트가 가진 타입 시스템의 장점을 가집니다.
Node.js는 손쉽게 사용할 수 있고 뛰어난 확장성을 가지고 있지만, 높은 자유도로 인해 Architecture 구성이 어렵습니다. 이러한 단점을 보완하기 위해 NestJS가 탄생하게 되었습니다.
NestJS의 장단점
NestJS는 데이터베이스, ORM, 설정(Configuration), 유효성 검사 등 수많은 기능을 기본 제공하고 있어 편리합니다.
필요한 라이브러리를 쉽게 설치하여 기능을 확장할 수 있는 Node.js 장점도 그대로 가지고 있습니다.
NestJS를 사용하여 개발하면서 느낀 점
러닝 커브가 낮아서 쉽게 접근 가능한 프레임워크인 것 같습니다. 저도 처음에는 영어문서이긴 하지만 문서도 잘 나와있는 편이라서 혼자 문서 보면서 간단한 서비스 만드는 것부터 시작했습니다. (한글문서도 나왔었는데 갑자기 사라짐..) 하지만 아직 사용하는 사람이 많지 않아서 오류 발생 시 찾기가 수월하지는 않습니다. 그래도 점점 Nest를 공부하는 사람들이 많아지는 것 같아서 너무 좋습니다.
그리고 Java의 Spring과 Architecture 구성이 유사하기 때문에 Spring 경험이 있는 분들은 금방 익힐 수 있을 것 같습니다. 다음에는 Spring과 NestJS의 차이점을 들고 오도록 하겠습니다.
getOne(id: number): Movie {
console.log(id);
...
}
id 값 잘 넘어옴
Insomnia에서 확인
빈 배열이 들어간 것을 확인
POST로 데이터를 담고 getOne()으로 테스트합니다.
insomnia 에서는 잘 나옴
💡 근데 테스트할 때는 왜 안 나올까요?
id의 type을 확인해봅니다.
getOne(id: number): Movie {
console.log(typeof id);
... }
number가 나옵니다.
반응형
npm run test:e2e로 확인해봅니다.
→ 테스트에서는 string으로 나옵니다.
→ movie.id 는 number이고, id는 string이기 때문에 찾을 수 없다고 뜨는 것
💡 왜 실서버에서의 id는 number이고, 테스트 서버에서는 string으로 나올까요?
main.ts
async function bootstrap() {
const app = await NestFactory.create(AppModule);
app.useGlobalPipes(new ValidationPipe({
whitelist:true, // 아무 decorator 도 없는 어떤 property의 object를 거름
forbidNonWhitelisted: true, // 잘못된 property의 리퀘스트 자체를 막아버림
transform: true, // 실제 원하는 타입으로 변경해줌
}));
await app.listen(3000);
}
transform이라는 것을 넣었습니다.
그래서 getOne()을 호출할 때 id 가 내가 원하는 number 타입으로 변경됩니다.
getOne(id: number): Movie
하지만 문제는 url 은 string입니다.
어떤 이유인지 e2e 테스트에서 transform 이 작동하지 않습니다. → 왜냐하면 e2e 테스트할 때 새로운 앱을 생성을 하는데 어떤 pipe 에도 올리지 않음..
💡 테스트에도 실제 애플리케이션 환경을 그대로 적용시켜줘야 합니다!!
app.e2e-spec.ts
...
beforeAll(async () => {
const moduleFixture: TestingModule = await Test.createTestingModule({
imports: [AppModule],
}).compile();
app = moduleFixture.createNestApplication();
app.useGlobalPipes(new ValidationPipe({
whitelist:true, // 아무 decorator 도 없는 어떤 property의 object를 거름
forbidNonWhitelisted: true, // 잘못된 property의 리퀘스트 자체를 막아버림
transform: true, // 실제 원하는 타입으로 변경해줌
}));
await app.init();
});
...
💡 새로 파일들을 생성하면 파일명 뒤에 .spec.ts 라고 붙은 파일들이 같이 생성되는데 그 파일들이 테스트를 포함한 파일입니다.
Nestjs에서는 jest 가. spec.ts 파일들을 찾아볼 수 있도록 설정되어있습니다.
npm run test:cov
모든 .spec.ts 파일을 찾아서 몇 줄이 테스팅됐는지 알려줍니다.
npm run test:watch
모든 테스트 파일들을 찾아서 거기서 무슨 일이 일어나는지 관찰합니다.
Unit Testing
서비스에서 분리된 유닛을 테스트한다.
모든 function 을 따로 테스트 ex) movie.service.ts > getAll() 함수 하나만 테스트하고 싶을 때 사용
e2e Testing (end-to-end)
모든 시스템을 테스팅한다. ex) 이 페이지로 가면 특정 페이지가 나와야 하는 경우 사용
Jest
자바스크립트 테스팅 프레임워크
Unit Test
💡 afterAll() 안에는 데이터베이스를 모두 지우는 function을 넣을 수 있음 beforeEach, afterEach, beforeAll, afterAll 등 많은 훅이 있습니다.
간단한 프로젝트를 통해 unit test를 진행해보도록 하겠습니다.
movies.service.spec.ts
import { Test, TestingModule } from '@nestjs/testing';
import { MoviesService } from './movies.service';
describe('MoviesService', () => { // 테스트를 묘사..?
let service: MoviesService;
beforeEach(async () => { // 테스트하기전에 실행
const module: TestingModule = await Test.createTestingModule({
providers: [MoviesService],
}).compile();
service = module.get<MoviesService>(MoviesService);
});
it('should be defined', () => {
expect(service).toBeDefined();
});
});
맨 하단에 이런 함수를 넣어서 실행해봅니다.
...
it('should be 4', () => {
expect(2+2).toEqual(4);
})
...
npm run test:watch
a 를 누른다.
Unit Testing
getAll()
getAll() 메소드를 호출한 후 result 인스턴스가 배열인지 테스트
describe('getAll', () => {
it('should return an array', () => {
const result = service.getAll();
expect(result).toBeInstanceOf(Array);
});
});
npm run test:watch
→ getAll : shold return an array
getOne()
getOne() 메소드가 잘 호출되는지 테스트
999 id 값을 가진 movie 가 없을 때 에러 메시지를 던지는지 확인
describe('getOne', () => {
// getOne() 을 테스트 할 때 Movie 가 create 되어 있지 않다면 문제가 생길 수 있음
it('should return a movie', () => {
service.create({
title: 'Test',
genres: ['test'],
year: 2020,
});
const movie = service.getOne(1);
expect(movie).toBeDefined();
expect(movie.id).toEqual(1); // movie id 값이 1이 맞는지 확인
});
it('should throw 404 error', () => {
try{
service.getOne(999);
}catch(e){
expect(e).toBeInstanceOf(NotFoundException);
expect(e.message).toEqual('Movie with ID 999 not found.');
}
})
});
