728x90

Module은 @Module() 데코레이터가 달린 클래스를 말한다.

이 데코레이터는 Nest가 애플리케이션 구조를 효과적으로 구성하고 관리 할 수 있도록 메타데이터를 제공한다.

 

모든 Nest 애플리케이션은 적어도 하나의 모듈을 가진다.

바로 application graph에서 출발점에 해당하는 루트 모듈이다.

이 그래프는 Nest가 관계와 의존관계를 해결하기 위해 사용하는 내부구조이다.

작은 애플리케이션은 하나의 모듈만 가질 수 있지만, 보통은 그렇지는 않다.

모듈은 구성 요소들을 조직할 때, 굉장히 추천되는 방식이다.

대부분의 애플리케이션에서, 기능들에 따라 밀접에서 관련되어 캡슐화된 멀티 모듈 구조를 가지게 될 것이다.

 

@Module() 데코레이터는 모듈을 명시한 하나의 싱글 오브젝트를 가진다.

providers Nest injector에 의해 인스턴스화 되거나, 모듈간에 공유되어야 하는 Provider들
controllers 해당 모듈에서 인스턴스화 되어야 하는 Controller들
imports 이 모듈에서 필요한 Provider를 내보내는 Module들
exports 이 모듈에 있는 Provider 중에 다른 모듈에서도 사용 할 수 있도록 내보내야 하는 Provider들

 

모듈은 기본적으로는 provider들을 캡슐화 한다.

이 말은 현재 모듈에서 사용하는 일부의 provider들을 주입받거나, 다른 모듈에서 명시해서 주입받아야 한다는 말이다.

 

  • Feature modules

우리의 예시에서 CatsController와 CatsService는 매우 밀접한 관계가 있었으며, 같은 애플리케이션 도메인에서 제공되었었다.

그러면 이것들을 기능 모듈에 그룹 지을 수 있을 것 같다.

기능 모듈은 특정한 기능들의 코드를 조직해서 편리하게 영역을 만들어준다.

이것은 SOLID원칙을 준수하며, 팀과 애플리케이션의 성장에 굉장히 중요하다.

 

cats를 모아서 cats module로 묶어 모듈로 분리해보자.

nest g module cats

이렇게 cats 모듈을 만들고, 이 곳으로 모든 코드들을 다 옮겨준다.

 

import { Module } from '@nestjs/common';
import { CatsModule } from './cats/cats.module';

@Module({
  imports: [CatsModule],
})
export class AppModule {}

이렇게 AppModule에 CatsModule을 넣어준다.

 

이제 다음과 같은 구조가 될 것이다.

 

  • Shared modules

Nest에서 모듈들은 기본적으로 싱글톤이다.

그렇기에 같은 인스턴스를 멀티 모듈에서 쉽게 공유가 가능하다.

모든 모듈은 기본적으로는 공유 모듈이다.

모듈은 일단 생성되면 어느 모듈에서든 사용이 가능하다.

우리가 CatsService를 다른 모듈간에 공유한다고 상상해보자.

일단 CatsModule에서 해당 CatsService를 export 해야한다.

import { Module } from '@nestjs/common';
import { CatsController } from './cats.controller';
import { CatsService } from './cats.service';

@Module({
  imports: [CatsModule],
  controllers: [CatsController],
  providers: [CatsService],
  exports: [CatsService],
})
export class CatsModule {}

이제 CatsModule을 import한 모듈은 CatsService에 접근이 가능하며 해당 인스턴스를 공유한다는 것도 굉장히 중요한 포인트이다.

 

만약 직접 CatsService를 가져가서 등록하게 된다면, 물론 이것도 가능은 하다.

하지만 그렇게하면 각각의 모듈이 각각의 인스턴스를 만들며, 같은 서비스가 또 생성되기에 메모리가 낭비되고 만약 해당 서비스에 상태가 존재했다면 이런 상태가 일치하지 않는 상태 불일치 문제가 발생하기도 한다.

 

이것을 모듈에서 감싸고 export 하는 방법은 CatsModule을 import하는 모든 모듈들에 같은 인스턴스가 공유되는 것을 보장한다.

이것은 메모리의 낭비를 줄이고 같은 상태를 공유하기에 예상치 못한 에러를 줄일 수 있다.

이런 서비스를 효율적으로 애플리케이션 간에 공유하는 것은 모듈화와 DI가 가능한 프레임워크의 핵심적인 기능이다.

 

  • Module re-exporting

모듈은 자신의 내부 provider를 export 할 수 있다.

그리고 추가적으로 자신이 import 했던 모듈을 다시 export 할 수 있다.

아래처럼 CommonModule은 CoreModule에게 import, export 되고 있으며, 이것은 다른 모듈이 이거 하나로 다 import 될 수 있도록 만든다.

@Module({
  imports: [CommonModule],
  exports: [CommonModule],
})
export class CoreModule {}

 

 

  • Dependency injection

모듈 클래스는 provider를 주입 받을 수 있다.

@Module({
  imports: [CatsModule],
  controllers: [CatsController],
  providers: [CatsService],
  exports: [CatsService],
})
export class CatsModule {
	constructor(private catsService: CatsService){}
}

그러나 순환참조 문제 때문에 모듈 자체에서 provider를 주입받을 수는 없다.

 

  • Global modules

만약 어디에서 항상 사용하는 모듈이 있다면, 그것을 모두 추가해주기는 힘들것이다.

Nest에서 전역으로 제공되는 provider를 만들고 싶다면, @Global 데코레이터로 글로벌 모듈로 만드는 것이 좋다.

@Global()
@Module({
  controllers: [CatsController],
  providers: [CatsService],
  exports: [CatsService],
})
export class CatsModule {}

@Global() 데코레이터는 모듈을 전역으로 만든다.

글로벌 모듈은 한 번만 등록하며, 보통 루트 혹은 코어 모듈에서 한다.

 

  • Dynamic modules

Nest에서 다이나믹 모듈은 런타임에 생성되도록 만들어준다.

만약 유연한 설계가 필요한 개발자라면 굉장히 유용한 기능이다.

특정한 옵션에 따라 모듈을 커스텀 할 수 있기 때문이다.

@Module({
  providers: [Connection],
  exports: [Connection],
})
export class DatabaseModule {
  static forRoot(entities = [], options?): DynamicModule {
    const providers = createDatabaseProviders(options, entities);
    return {
      module: DatabaseModule,
      providers: providers,
      exports: providers,
    };
  }
}

'Node > Nest 공식문서' 카테고리의 다른 글

Providers  (0) 2025.08.21
Controllers  (0) 2025.08.20
First steps  (2) 2025.08.18
Introduction  (4) 2025.08.18
728x90

Prodiver는 Nest의 가장 핵심적인 개념이다.

Service, Repository, Factory, Hepler와 같은 Nest의 기본 클래스들이 모두 Provider로 다루어진다.

Provider의 핵심적인 개념은 각각의 형태로 관계를 가지고, 의존성에 맞도록 주입되는 것이다.

이런 객체들을 연결해주는 것은 Nest runtime system의 큰 과제이다.

 

이전 장에서 CatsController를 만들었던 것을 생각해보자.

컨트롤러는 단순히 Http 요청을 처리하고, 복잡한 작업은 Provider에게 위임해야 한다.

여기서 Provider는 Nest에서 providers로 선언된 자바스크립트 클래스를 말한다.

 

  • Services

이번에는 예시로 CatsService를 만들어보자.

해당 서비스는 데이터의 저장과 조회를 담당하며, CatsController에서 사용할 예정이다.

이런 애플리케이션 로직을 다루기 때문에, provider 모듈에서 다뤄지게 되는 것이다.

 

import { Cat } from './interfaces/cat.interface';
import { Injectable } from '@nestjs/common';

@Injectable()
export class CatsService {
  private readonly cats: Cat[] = [];
  create(cat: Cat) {
    this.cats.push(cat);
  }
  findAll(): Cat[] {
    return this.cats;
  }
}

CatsService는 하나의 멤버 변수와 두개의 메서드를 가지고 있다.

여기서 가장 중요한 포인트는 @Injectable() 데코레이터이다.

해당 데코레이터는 클래스에 메타데이터를 추가해서, CatsService가 Nest의 IoC 컨테이너에 의해 관리될 수 있도록 한다.

 

이 CatsService는 클래스의 생성자를 통해 주입되게 된다.

import {
  Controller,
  Body,
  Get,
  Post,
  Put,
  Delete,
  Param,
  Query,
} from '@nestjs/common';
import { CreateCatDto } from './dto/create-cat.dto';
import { CatsService } from './cats.service';

@Controller('/cats')
export class CatsController {
  constructor(private readonly catService: CatsService) {}
  @Post()
  create(@Body() createCatDto: CreateCatDto): string {
    console.log(createCatDto);
    return 'This action adds a new cat';
  }
  @Get()
  findAll(@Query('age') age: number, @Query('breed') breed: string): string {
    return `This action returns all cats filtered by age: ${age} and breed: ${breed}`;
  }
  @Get(':id')
  findOne(@Param('id') id: string) {
    return `This action returns a #${id} cat`;
  }
  @Put(':id')
  update(@Param('id') id: string, @Body() createCatDto: CreateCatDto) {
    return `This action updates a #${id} cat ${createCatDto.name}`;
  }
  @Delete(':id')
  remove(@Param('id') id: string) {
    return `This action removes a #${id} cat`;
  }
}

 

  • Dependency injection

Nest는 의존성 주입이라고 많이 알려진 강력한 디자인 패턴을 통해 빌드된다.

이것에 대해서는 Angular의 문서를 참고하면 좋다고 한다.

https://angular.dev/guide/di

 

Angular

The web development framework for building modern apps.

angular.dev

TypeScript를 활용하기에 Nest에서는 타입을 통해 이러한 의존성들이 관리될 수 있다.

나중에 저 Angular의 문서를 읽고서도 블로그를 써보도록 해야겠다.

 

  • Scopes

provider는 생명주기를 가지게 되며, 그 생명주기는 보통 애플리케이션의 생명주기와 동행한다.

애플리케이션이 부트스트랩되면, 모든 의존성들은 해결되어야 할 것이며 모든 provider가 instantiated되어야 한다는 것이다.

비슷하게 애플리케이션이 종료된다면, 이런 Provider는 모두 같이 종료되어야 한다.

그러나 이런 Provider를 범위를 지정해서 넣도록 할 수 있다.

그럴 때는 이 생명 주기가 애플리케이션이 되는 것이 아니라, 특정 요청에 대해 묶이게 되는 것이다.

나중에 Injection Scope에서 더 자세히 알아보도록 하자.

 

  • Optional providers

가끔은 항상 해결할 필요가 없는 의존성이 있을 수도 있다.

예를 들어, 특별한 구성 요소에 의존할 수 있지만, 해당 객체가 제공되지 않는 경우 기본값을 사용하도록 할 수 있다.

이런 경우 해당 의존성은 선택적으로 간주되며, 설정을 따로 해주지 않더라도 에러가 발생해서는 안된다.

 

공급자를 선택적으로 표시하기 위해서는, 생성자에 @Optional() 데코레이터를 사용하면 된다.

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

@Injectable()
export class HttpService<T> {
  constructor(@Optional() @Inject('HTTP_OPTIONS') private httpClient: T) {}
}

여기 예시에서는 custom provider를 사용하기에 HTTP_OPTIONS라는 커스텀 토큰을 포함하고 있다.

여기서는 의존성을 생성자의 클래스로 지정했다.

나중에 해당 챕터에서 더 자세히 알아보자.

 

  • Provider registration

이번에 CatsService라는 Provider와 CatsController라는 Consumer를 정의했었다.

우리는 이것들을 Nest에 등록해서 주입과정에서 다룰 수 있도록 해야한다.

등록은 app.module.ts를 수정해서 진행해야 하며, providers에 service를 넣어주면 된다.

import { Module } from '@nestjs/common';
import { CatsController } from './cats/cats.controller';
import { CatsService } from './cats/cats.service';

@Module({
  controllers: [CatsController],
  providers: [CatsService],
})
export class AppModule {}

 

'Node > Nest 공식문서' 카테고리의 다른 글

Modules  (0) 2025.08.23
Controllers  (0) 2025.08.20
First steps  (2) 2025.08.18
Introduction  (4) 2025.08.18
728x90

컨트롤러는 사용자로부터 오는 요청을 받고 다시 응답을 돌려주는 것에 대한 책임이 있다.

 

컨트롤러는 사용자로부터 온 특정한 요청을 어디로 보낼 것인지에 대한 목적으로 만들어졌다. 라우팅 메커니즘은 어떤 컨트롤러가 각각의 요청을 받을 것인지를 결정한다. 종종, 컨트롤러는 여러개의 라우트를 가지며, 그 각각의 라우트는 다른 동작을 수행한다.

 

컨트롤러를 만들기 위해서, 우리는 클래스와 데코레이터를 사용한다. 데코레이터는 해당 클래스의 메타 정보를 통해, Nest가 일치하는 응답을 라우팅 해 줄 수 있도록 도와준다.

 

  • Routing

예시에서 우리는 기본적인 컨트롤러를 만들기 위해 필요한 @Controller() 데코레이터를 사용할 것이다. cats라는 접두사를 가진 경로를 명시하며, @Controller에 접두사를 작성하는 것은 이후에 추가적으로 해당 경로를 더 명시할 필요없이 그룹화 할 수 있도록 도와준다. 예를 들어 우리가 Cats와 상호작용하는 라우트를 만들고 싶다면, 해당 경로의 접두사는 /cats가 될 것이며, @Controller('cats')로 작성하면 이 경로들을 그룹화 해주는 것이다. 그렇기에 컨트롤러에 추가할 라우트들에 'cats를 반복해서 작성 할 필요가 없다.

 

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

@Controller('cats')
export class CatsController {
  @Get()
  findAll(): string {
    return 'This action returns all cats';
  }
}

 

@Get()이라는 Http 요청 데코레이터는 findAll()이라는 메서드 이름 앞에 위치하며, Nest가 특정 경로에 대한 라우트를 생성하도록 한다. 이제 이 route path는 controller에 이미 명시해둔 경로와 메서드에 작성한 데코레이터의 경로를 조합하여 만들어진다. 여기에서는 @Get()에 경로 명시가 없기 때문에 /cats로 들어오는 @Get() 요청에 대해 동작하는 것이다.

 

위의 예시에서 해당 경로로 Get 요청이 들어온다면, Nest는 라우트하여 findAll() 메서드를 호출한다. 여기서 메서드의 이름은 임시이며, Nest는 이 컨트롤러의 메서드 이름에 의미를 부여하지 않는다.

 

해당 메서드는 아마 200 status code를 리턴할 것이다, 저기 작성해둔 문자열과 함께 말이다. 이것에 대해 설명하기 위해서는 2가지의 응답을 바꾸는 방법에 대해 알아야 한다.

 

standard
(recommended)
해당 내장 메서드를 이용하면, Javascript가 객체 혹은 배열을 리턴 할 때, Json으로 자동 변환되어 돌려주게 된다. 하지만 만약 Javascript의 원시타입(string, number..)만 응답한다면, 직렬화를 시도하지 않는다. 
Library-specific 만약 @Res()로 사용하는 response object와 관련된 라이브러리를 사용할 수 있다. 이것을 사용하면, 개발자는 response.status(200).send()과 같이 작성해서 객체를 응답 할 수 있다.

 

  • Request object

핸들러는 종종 클라이언트에서 보낸 요청의 세부 정보를 알아와야 할 때가 있다. Nest는 이런 요청 객체에 대한 접근을 허용한다. 개발자는 @Req() 데코레이터를 사용하여 사용자가 보낸 요청의 객체에 접근이 가능하다.

 

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

@Controller('cats')
export class CatsController {
  @Get()
  findAll(@Req() request: Request): string {
    console.log(request);
    return 'This action returns all cats';
  }
}

 

위와 같은 코드로 request를 출력해보니, 

이런식으로 긴데이터가 들어왔던 것을 볼 수 있었다.

이렇게 많은 데이터에서 원하는 속성을 찾아서 가져오기는 힘들 것 같고, @Body()와 @Query()같은 전용 데코레이터가 있기에 이것들을 사용해서 객체에 접근하게 될 것이다.

 

아래는 각각의 데코레이터들이 어떤것과 대응되는지를 보여주는 표이다.

@Request(), @Req() req
@Response(), @Res() res
@Next() next
@Session() req.session
@Param(key?: string) req.params/req.params[key]
@Body(key?: string) req.body/req.body[key]
@Query(key?: string) req.query/req.query[key]
@Headers(name?: string) req.headers/req.headers[name]
@Ip() req.ip
@HostParam() req.hosts

 

만약 @Res()나 @Response()를 사용하면, Nest에서 해당 핸들러가 응답까지 알아서 처리한다고 생각하고 끝까지 처리해주지 않는다.

그렇기에 해당 데코레이터를 사용하면 응답까지 개발자가 완성해서 리턴해줘야 한다.

 

  • Resources

이전에 cats의 GET API를 만들어보았다. 이번에는 POST를 통해 새로운 핸들러를 만들어보도록 하자.

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

@Controller('cats')
export class CatsController {
  @Get()
  findAll(): string {
    return 'This action returns all cats';
  }
  @Post()
  create(): string {
    return 'This action adds a new cat';
  }
}

굉장히 간단하며, Nest는 표준의 Http 메서드를 데코레이터를 통해 모두 지원한다.

만약 모든 메서드를 지원하는 엔드포인트를 만들고 싶다면 @All() 데코레이터를 사용하면 된다.

 

  • Route wildcards

패턴을 통해서 라우트하는 기능도 Nest는 지원한다. *을 사용하면 와일드카드로 해당 위치에는 어떤 조합의 경로도 라우트해준다. 

아래의 예시처럼 사용하면 seungkyu/ 뒤의 경로로 어떤 문자열이 오더라도 해당 핸들러로 라우팅해준다.

@Get('abcd/*')
findAll(){
	return 'This route uses a wildcard';
}

 

 

  • Status code

기본적인 응답 코드는 항상 200이고, POST 메서드의 응답코드는 항상 201이다.

이거를 @HttpCode()를 통해 핸들러 레벨에서 쉽게 바꿀 수 있다.

@Post()
@HttpCode(204)
create(){
	return 'This action adds a new cat';
}

 

물론 중간에 에러가 발생하면 바뀌기도 하며, @Res() 혹은 @Response()를 사용해서 직접 넘길 때도 바뀌기도 한다.

 

  • Response headers

response의 header를 직접 명시하기 위해, @Header() 데코레이터를 사용할 수 있다.

물론 res.header()를 통해서 직접 접근도 가능은 하다.

@Post()
@Header('Cache-Control', 'no-store')
create(){
	return 'This action adds a new cat';
}

 

  • Redirection

특정 주소로 리다이렉트 하고 싶다면, @Redirect() 데코레이터에 url과 statusCode를 명시해주면 된다.

만약 statusCode를 명시하지 않는다면, statusCode의 기본값은 302이다.

@Get()
@Redirect('https://nestjs.com', 301)

 

  • Route parameters

정적인 경로만으로 요청하면, 원하는 동적 데이터들을 받을 수 없다.

만약 id와 같은 값을 동적으로 받아오고 싶다면, 파라미터 토큰을 넣어서 가져올 수 있다.

아래 @Get() 데코레이터 예제의 라우트 매개변수 토큰이 바로 그 방식이다.

라우트에 정의한 파리미터는 메서드에 @Param() 데코레이터를 통해 접근 할 수 있다.

@Get(':id')
findOne(@Param() params: any): string{
	console.log(params.id);
    return `This action returns a #${params.id} cat`;
}

 

@Param() 데코레이터는 메서드의 파라미터 데코레이터며, 경로 파라미터에 정의된 값을 메서드가 사용 할 수 있도록 해준다.

위에서는 id에 접근하기 위해 params.id를 사용했지만, 라우트 파라미터의 이름에 직접 접근하여 바로 값을 가져올 수도 있다.

 

@Get(':id')
findOne(@Param('id') id: string): string{
	return `This action returns a #${id} cat`;
}

 

  • Sub-domain routing

@Controller() 데코레이터는 host 옵션을 받을 수 있다.

host 옵션은 해당 주소에서 온 HTTP 요청만 처리하겠다는 의미이다.

@Controller({host: 'admin.example.com'})
export class AdminController{
	@Get()
    index(): string {
    	return 'Admin page';
    }
}

 

여기서도 주소에서 동적인 값을 찾아서 올 수 있다.

host에서 선언된 매개변수는 @HostParam() 데코레이터를 추가해서 접근 가능합니다.

@Controller({host: ':account.example.com'})
export class AccountController{
	@Get()
   	getInfo(@HostParam('account') account: string) {
    	return account;
    }
}

 

  • Asynchronicity

자바스크립트의 기능을 최대한 활용하기 위해, 비동기 데이터 핸들링을 사용한다.

모든 async 함수들은 해당 데이터를 다루며 자동으로 값을 반환하는 Promise 타입을 반환한다.

@Get()
async findAll(): Promise<any[]>{
	return [];
}

 

해당 코드도 충분히 멋지지만, Nest는 RxJs를 통한 observable stream도 지원한다.

Nest가 해당 데이터를 구독하며, 내부적으로 알아서 값을 반환하게 된다.

@Get()
findAll(): Observable<any[]>{
	return of([]);
}

 

  • Request payloads

이전에서 했던 POST는 사용자가 보내는 파라미터들을 받지 않았었다.

그것을 @Body()로 해결해보자.

 

우선 사용하기 전에 DTO를 정의해보자.

DTO는 네트워크를 통해 데이터를 전송할 때, 어떻게 보내야할지 명시하는 객체이다.

Nest에서는 인터페이스 혹은 클래스를 사용해 DTO 스키마를 정의한다.

하지만 이 중에서도 class로 정의하는 것을 추천한다.

클래스는 ES6 자바스크립트 문법이기에 javascript 자체로 컴파일이 가능하다.

그에 비해, 인터페이스는 변환 과정에서 삭제되기 때문에 Nest는 런타임 중에 해당 인터페이스를 참조 할 수 없다.

이것은 파이프같은 기능들이 런타임 중 변수의 타입에 접근해야 하기에 중요하다.

 

export class CreateCatDto{
	name: string;
    age: number;
    breed: string;
}

 

이제 CatsController에 넣어보자.

 

import { Body, Controller, Get, Post } from '@nestjs/common';
import { CreateCatDto } from './dto/create-cat.dto';

@Controller('cats')
export class CatsController {
  @Get()
  findAll(): string {
    return 'This action returns all cats';
  }
  @Post()
  create(@Body() createCatDto: CreateCatDto): string {
    console.log(createCatDto);
    return 'This action adds a new cat';
  }
}

 

이렇게 @Body() 데코레이터를 통해, POST에서 사용자가 보낸 데이터를 사용할 수 있다.

 

  • Query parameters

@Query()를 사용해 요청에서 들어온 쿼리 파라미터를 가져올 수 있다.

  @Get()
  findAll(@Query() age: number, @Query() breed: string): string {
    return `This action returns all cats filtered by age: ${age} and breed: ${breed}`;
  }

 

이런 핸들러에 다음과 같은 요청을 보내면

http://localhost:3000/cats?age=2&breed=thief

 

이렇게 응답이 오는 것을 볼 수 있다.

 

  • Getting up and running

CatsController를 완벽하게 다 작성했어도, 동작이 바로 되는 것은 아니다.

컨트롤러는 모듈의 일부이며, 우리는 @Module 데코레이터에 이 컨트롤러를 넣어줘야 한다.

import { Module } from '@nestjs/common';
import { CatsController } from './cats/cats.controller';

@Module({
  controllers: [CatsController],
})
export class AppModule{}

'Node > Nest 공식문서' 카테고리의 다른 글

Modules  (0) 2025.08.23
Providers  (0) 2025.08.21
First steps  (2) 2025.08.18
Introduction  (4) 2025.08.18
728x90

nest를 빠르게 이해하기 위해 CRUD를 만들어보도록 하겠다.

 

  • Language

TypeScript를 사용하지만, Node.js도 사용이 가능하다. 만약 Javascript를 사용하고 싶다면 Babel 컴파일러를 사용하면 된다.

 

  • 요구사항

Nest로 개발하기 위해서는 Node.js 20버전 이상으로 설치가 되어 있어야 개발이 가능하다.

 

  • 설정

npm 전역에 nest를 설치하고, nest로 프로젝트를 만들면 된다.

npm i -g @nestjs/cli
nest new {project-name}

 

이렇게 생성을 하면 다음과 같이 파일들이 생기게 될 것이다.

 

이거에 대한 간략한 설명들을 해보자면

app.controller.ts 싱글 라우트를 가지고 있는 기본 컨트롤러
app.controller.spec.ts 컨트롤러의 유닛 테스트
app.module.ts 애플리케이션의 가장 기본 모듈
app.service.ts 하나의 메서드를 가지고 있는 기본 서비스
main.ts Nest application을 생성해주는 엔트리 파일

 

main.ts는 다음과 같이 작성되어 있다.

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  await app.listen(process.env.PORT ?? 3000);
}
bootstrap();

 

Nest 인스턴스를 만들기 위해서는 저 NestFactory.create를 사용해야 한다.

 

NestFactory.create()는 다음과 같이 INestApplication 인터페이스를 반환한다. 이 인터페이스는 여러가지 메서드들을 제공하며, 이 main.ts에서는 그냥 단순히 Http Listener를 만들어주는 것이다.

 

이제 이 nest의 개발 방법에 따라 개발자가 기능을 확장해나가면 된다.

 

  • 플렛폼

Nest는 플랫폼에 종속되지 않는 것에 목적을 두었다. 플랫폼에서 독립적이라면 비즈니스 로직을 다른 타입의 애플리케이션 간에 재사용 할 수 있으니 말이다. 기술적으로 Nest는 Node의 웹 프레임워크에서나 사용가능하다. 여기 2개의 바로 사용가능한 플랫폼이 존재한다. 바로 express와 fastify다.

platform-express express는 가장 잘 알려진 경량화 node 웹 프레임워크다. 실무에서 이미 검증된 프레임워크로 커뮤니티에서 많은 리소스들을 재공한다. @nestjs/platform-express는 기본적으로 platform-express를 사용하며, 이 플랫폼을 사용하기 위해서는 별도의 조치는 필요없다.
platform-fastify Fastify는 높은 성능과 적은 오버헤드에 초점을 둔 프레임워크이다.

 

어떤 프레임워크를 사용하더라도 이렇게 상속받아서 nest를 동작할 수 있다.

 

  • 애플리케이션 실행

설치가 완료되었다면, 아래와 같은 명령어를 입력하여 들어오는 Http 요청을 받을 수 있다.

npm run start

 

그러면 이렇게 다음과 같은 로그가 나온다.

 

그리고 main.ts에 명시되어있는 포트에 요청하면

이렇게 응답이 오는 것을 볼 수 있다.

 

만약 개발 과정 중에 있다면

npm run start:dev

이 명령어를 통해 자동으로 변경되는 파일을 재컴파일 해서 서버를 재실행 할 수 있다.

 

 

'Node > Nest 공식문서' 카테고리의 다른 글

Modules  (0) 2025.08.23
Providers  (0) 2025.08.21
Controllers  (0) 2025.08.20
Introduction  (4) 2025.08.18
728x90

https://docs.nestjs.com/

 

Documentation | NestJS - A progressive Node.js framework

Nest is a framework for building efficient, scalable Node.js server-side applications. It uses progressive JavaScript, is built with TypeScript and combines elements of OOP (Object Oriented Programming), FP (Functional Programming), and FRP (Functional Rea

docs.nestjs.com

 

 

  • Introduction

Nest는 node.js 서버를 더 효율적이고 확장가능하도록 돕기 위한 프레임워크이다. Nest는 최신 자바스크립트 문법과 타입스크립트를 완벽하게 지원하며, 이를 통해 객체지향프로그래밍, 함수형 프로그래밍, 반응형 프로그래밍을 사용하여 개발할 수 있다.

 

Nest는 내부적으로 Express 위에서 동작하지만, 선택적으로 Fastify에서도 동작이 가능하다.

 

Nest는 node.js 프레임워크에서 직접 라우터를 짜지 않아도, 상위 추상화 개념을 이용하여 개발 할 수 있도록 한다.

 

  • Philosophy

최근 몇 년 동안 Node.js 덕분에 Javascript는 웹의 프론트와 백에서 공용어가 되었습니다. 하지만 Angular, React, Vue와 같이 훌륭한 프론트엔드 애플리케이션이 등장했지만, 서버에서의 Node.js는 아키텍처라는 근본적인 문제를 효과적으로 해결하지는 못했습니다.

 

Nest는 개발자가 효과적으로 테스트하고, 확장가능하고, 느슨하게 결합하고, 애플리케이션을 쉽게 유지보수 할 수 있도록 즉시 사용가능한 애플리케이션을 제공한다.

 

  • Installation

시작을 하기 위해서는 Nest cli 혹은, starter project를 clone 하는 방법으로 기본 틀을 가져올 수 있다.

 

Nest cli 방법을 사용하기 위해서는 다음의 명령어를 따라가면 된다. 이것은 새로운 디렉토리를 만들며, 해당 디렉토리를 Nest 파일과 모듈로 채우게 된다.

 

npm i -g @nestjs/cli
nest new {project-name}

 

이렇게 틀을 받아오고, 

npm run start

로 서버를 실행해서 http://localhost:3000/ 에 접속하면 페이지가 보일것이다.

 

'Node > Nest 공식문서' 카테고리의 다른 글

Modules  (0) 2025.08.23
Providers  (0) 2025.08.21
Controllers  (0) 2025.08.20
First steps  (2) 2025.08.18
728x90

결국 스프링이 원하는 방향에 대해 생각해 보자.

지금까지 느낀 스프링은 OOP를 제대로 적용하기 위해, IOC/DI 기술을 활용한 프레임워크라고 느껴진다.

 

스프링의 정의는 이렇다고 한다.

"자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크"

 

이거에 대해서 생각해 보면

 

  • 애플리케이션 프레임워크

스프링은 어느 분야에만 사용되는 프레임워크가 아니다.

MVC, Log, AOP, 인증, ORM 등등 웹 개발에 필요한 대부분의 기술을 가지고 있다.

스프링의 일차적인 존재 이유는 웹 기술에 담긴 프로그래밍 모델을 일관되게 적용해 애플리케이션 개발을 편리하게 만들어주는 것이다.

 

  • 경량급

솔직히 스프링이 가볍다고 생각해 본 적은 없다.

nest... 와 같은 프레임워크가 훨씬 가볍다고 생각했었다.

그럼에도 스프링이 가볍다고 말하는 이유는 불필요한 부분이 없기 때문이라고 한다.

 

스프링이 처음 등장하던 시기에는 EJB가 개발환경과 운용서버, 개발과 빌드, 테스트 과정 등등... 코드들을 엄청 무겁게 만들었다고 한다.

그렇기에 서버를 동작하기 위해서는 고성능의 무거운 자바 서버가 필요했다고 한다.

그렇기에 스프링은 가장 단순한 톰캣에서도 동작할 수 있도록 등장했으며, 이것만으로도 충분하게 애플리케이션을 개발할 수 있었다고 한다.

 

  • 자바 엔터프라이즈 개발을 편하게

스프링이 배우기 쉬웠던 기술이라고는 생각되지 않는다.

하지만 여기서 말하는 편하다라는 뜻은 그런 의미는 아니고, 개발의 비즈니스 로직에 집중하다록 만들어주었다는 것이다.

 

기존에 개발자가 로우레벨의 트랜잭션, 상태관리, 멀티쓰레딩과 같은 부분까지 신경을 쓰며 개발을 해야했다면 스프링은 그런 문제를 해결해주었다는 것이다.

물론 여기서 이런 기술을 아예 무시하고 개발한다는 것이 아니다.

이런 요구들을 스프링 엔터프라이즈 시스템에서 최대한 해결해준다는 것이다.

 

  • 오픈소스

스프링은 처음부터 지금까지 오픈소스로 개발되고 있다.

그렇기에 공개된 커뮤티니의 공간 안에서 다양한 사람이 투명하게 참여하여 개발하기에 빠르고 유연하게 성장이 가능하다.

사용자의 피드백도 빠르게 반영되고 있다.

 

라이센스에 대한 비용도 없기 때문에, 부담없이 큰 기업에서도 사용해 개발이 가능하다.

 

728x90

스프링의 현재와 미래 같은 챕터이다.

스프링의 핵심인 객체지향은 그대로지만, 이 객체지향을 지키기 위한 기술들이 많이 바뀌었다고 한다.

 

  • 어노테이션의 메타정보 활용

자바는 소스코드를 컴파일 후 클래스 파일로 만들었다가, JVM에 의해 메모리에서 로딩되어 실행된다.

이런 자바코드를 리플렉션등과 같은 방법으로 클래스내의 인터페이스, 필드 등의 메타정보를 확인 할 수 있다.

 

자바5에 어노테이션이 등장했다.

자바의 클래스나 인터페이스, 필드와 메서드들은 그 자체로 직접 이용이 가능하지만 어노테이션은 그런 방식으로는 이용이 불가능하다.

리플렉션을 이용해 메타정보를 조회하고, 어노테이션에 설정된 값을 가져와서 참고하는 방법이 전부라고 한다.

그럼에도 이렇게 직접 영향을 주지 못하는 어노테이션은 빠르게 발전했다고 한다.

어노테이션이 IOC 방식의 프레임워크, 프레임워크가 참조하는 메타정보라는 이 구성방식에 잘 어울리기 때문이라고 한다.

 

기존에 작성하던 이 긴 xml을 어노테이션으로 교체가 가능하다.

@Seungkyu
public class SK{}

이렇게만 작성해도 클래스의 정보와 해당 클래스가 어떤 인터페이스를 구현하고 있는지 알아 올 수 있기 때문이다.

 

이런 방식을 사용하여 XML을 최대한 작성하지 않도록 만들 수 있었고, 스프링 3.1에서는 대부분의 기능을 이 어노테이션으로 대체가 가능하다고 한다.

 

기존에 작성했던 xml을 어노테이션을 사용하는 방법으로 리펙토링 해보도록 하자.

 

자바 코드를 이용한 빈 설정

우선 test-applicationContext.xml을 사용하는 테스트를 타깃으로 리펙토링 해보자.

테스트가 작성되어 있기에, 바로 확인이 가능하기 때문이다.

해당 xml은 @ContextConfiguration(locations="/test-applicationContext.xml")을 붙인 클래스들이 사용 중이다.

 

이거를 그대로 가져올 클래스를 먼저 만든다.

@Configuration
public class TestApplicationContext {
}

이제 이게 xml이다.

 

@ExtendWith(SpringExtension.class)
@ContextConfiguration(classes = TestApplicationContext.class)
class UserDaoTest {

이제 테스트 클래스의 configuration을 위치가 아닌, 해당 클래스로 변경해준다.

 

일단 이거도 단계적으로 나아가기 위해 처음에는 해당 xml을 불러오는 것으로 시작한다.

@Configuration
@ImportResource("/test-applicationContext.xml")
public class TestApplicationContext {
}

 

이렇게하고 테스트를 실행하면 당연히 성공한다.

하나씩 고치면서 계속 테스트를 실행해보자.

 

우선 step1은 context:annotation-config라고 한다.

사실 이거

@PostConstruct를 위해서 작성했던 것인데, @Configuration을 사용하면 자동으로 등록해주기 때문에 바로 삭제해도 문제 없다고 한다.

 

step2는 가장 많을 bean이다.

현재 이 DataSource를 SimpleDriverDataSource 구현체로 주입받고 있다.

이거를 클라이언트가 SimpleDriverDataSource로 주입받는 것이 아니라, DataSource 인터페이스로 받도록 해야한다.

 

그렇기에 이런식으로 Bean을 생성해야 한다.

    @Bean
    public DataSource dataSource() {
        return null;
    }

 

이제 내용과 리턴 타입을 채워보자.

 

xml의 내용을 setter를 사용해 그대로 넣으면 된다.

    @Bean
    public DataSource dataSource() {

        SimpleDriverDataSource dataSource = new SimpleDriverDataSource();
        dataSource.setDriverClass(Driver.class);
        dataSource.setUrl("jdbc:mysql://localhost:3306/test");
        dataSource.setUsername("root");
        dataSource.setPassword("1204");
        
        return dataSource;
    }

 

이렇게 작성하게 테스트를 돌려보면

비록 DataSource를 찾지 못해 intellij의 xml에서는

이렇게 에러가 발생한다고 나오지만, 실제 실행하면 @Bean의 정보를 불러오기에 테스트는 정상적으로 동작한다.

 

 

마찬가지로 transactionManager도 아래와 같이 옮긴다.

    @Bean
    public PlatformTransactionManager transactionManager() {
        DataSourceTransactionManager transactionManager = new DataSourceTransactionManager();
        transactionManager.setDataSource(dataSource());
        return transactionManager;
    }

 

만약 다른 빈의 주입이 필요하면 이렇게 빈의 메서드를 직접 호출해서 넣어주면 된다.

 

여기서 현재 sqlService()를 만들지 않아서 에러가 발생 중이다.

그럴 때는 다른 곳에 있는 SqlService 빈을 불러와야 하기에, Configuration 자체에 주입 받으면 된다.

 

이렇게 주입받아서 사용하고, 테스트를 수행해보니 정상적으로 수행되는 것을 볼 수 있었다.

 

    <jdbc:embedded-database id="embeddedDatabase" type="H2">
        <jdbc:script location="classpath:schema.sql"/>
    </jdbc:embedded-database>

 

이것도 옮겨야 하는데 이 친구는 <bean>이 아니다.

하지만 저번에 EmbeddedDatabaseBuilder를 사용했던 것을 떠올리며, 결국 해당 타입으로 주입을 하게 되는 것이기에 그렇게 만들어서 넣어준다.

 

    @Bean
    public DataSource embeddedDataSource() {
        return new EmbeddedDatabaseBuilder()
                .setName("embeddedDatabase")
                .setType(EmbeddedDatabaseType.H2)
                .addScript("/schema.sql").build();
    }

 

메서드의 이름은 우리가 등록했던 bean의 id로 해준다.

 

마지막으로 트랜잭션 어노테이션을 위해 해당 어노테이션까지 TestApplicationContext에 붙여준다.

@EnableTransactionManagement

 

이렇게해서 모든 bean을 옮겼다.

초기 테스트를 위해서 붙였던 @ImportResource를 지금은 제거가 가능하다.

 

그렇게 수정하고 테스트를 돌려보니 성공하는 것을 볼 수 있었다.

 

빈 스캐닝과 자동와이어링

이렇게 만든 빈들을 생성자나 setter를 통해 주입해야한다.

 

스프링은 @Autowired가 붙은 수정자 메서드가 있으면 타입을 보고 주입 할 수 있는 빈을 주입한다.

만약 타입으로 주입 가능한 빈이 2개 이상이면, 그 중에서 해당 프로퍼티와 동일한 이름의 빈으로 주입한다.

 

그렇기에 이렇게 동일한 타입이 2개라도 각각의 이름을 통해서 빈을 주입 가능한 것이다.

@Bean
public DataSource dataSource() {}

@Bean
public DataSource embeddedDataSource() {}

 

@Autowired
public UserDaoImpl(
            DataSource dataSource,
            SqlService sqlService) {
        this.jdbcTemplate = new JdbcTemplate(dataSource);
        this.sqlService = sqlService;
    }

이렇게 DataSource로 받지만, 실제 사용하는건 JdbcTemplate과 같은 경우 JdbcTemplate을 주입받을 수는 없으니 반드시 setter나 생성자를 통해 주입 받아야 한다.

 

@Component를 통해서도 빈 등록이 가능하다.

이 @Component는 클래스에 사용하는 어노테이션이고, 이 어노테이션이 부여된 클래스는 자동으로 빈으로 등록된다.

 

현재 작성한 UserDaoImpl을 보면

@Component
public class UserDaoImpl implements UserDao { 
	//
}

 

이렇게 해당 클래스에 @Component를 붙이는 것 만으로도

    @Bean
    public UserDao userDao() {
        return new UserDaoImpl(dataSource(), sqlService());
    }

이거를 대체할 수 있다는 것이다.

 

대신에 @ComponentScan을 통해 @Component들을 검색할 범위를 지정해야 한다.

@Configuration
@EnableTransactionManagement
@ComponentScan(basePackages = "seungkyu")
public class TestApplicationContext { }

이렇게 범위를 지정해서 그 패키지들의 하위 클래스들을 검색하도록 해야한다.

 

@Component에서 클래스는 해당 클래스로 등록하고, 빈의 아이디는 특별하게 지정하지 않으면 클래스의 이름을 첫글자 소문자로 바꿔서 사용한다.

 

현재 UserDaoImpl이기에 빈의 아이디는 userDaoImpl로 지정이 되겠지만, UserDao의 구현체이기에 해당 UserDao의 타입으로도 주입이 되게 된다.

 

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Component
public @interface SeungkyuComponent {
}

이런 식으로 @Component 어노테이션을 가지고 있는 어노테이션은 빈으로 등록이 된다.

 

그런 빈 중에서도 @Service, @Repository와 같은 특별한 역할을 하는 빈들이 있기에 맞게 달아주도록 하자.

여기는 현재 데이터베이스에 접근하는 코드이니 @Repository를 붙여주도록 하겠다.

 

빈을 등록하다보면 다음과 같은 상황이 생길 수 있다.

타입으로 주입을 시도하려고 했지만, 같은 타입이 2개 있고 이름으로도 주입할 수 없는 상황이다.

기존에는 UserServiceImpl을 UserService로 id를 지정해서 빈을 등록했지만, 지금은 클래스의 이름으로 등록이 되었기에 저 중 어떤 id도 userService와 맞지 않아 어떤 빈을 주입할지 에러가 생긴 것이다.

 

이 문제를 해결해주기 위해서는 다시 UserServiceImpl을 UserService로 등록해주면 된다.

@Component("userService")
@RequiredArgsConstructor
public class UserServiceImpl implements UserService{}

 

이 방법으로 빈을 등록해주도록 하자.

 

그러면 나머지 이 testUserServiceImpl은 어떻게 사용하게 될까?

 

컨텍스트 분리와 @Import

이렇게 DI를 사용해왔던 이유는 언젠가 사용할 테스트 때문이다.

그리고 지금 이 testUserServiceImpl도 테스트 때에만 사용하기에 어떻게 처리를 할지 고민하는 것이다.

다른 애플리케이션 빈에서는 분리하는 것이 더 좋아보인다.

 

일단 테스트에서 사용할 빈들을 따로 빼두는 Configuration을 만들어보자.

@Configuration
public class TestAppContext {

    @Autowired UserDao userDao;

    @Bean
    public UserService testUserService(){
        return new TestUserServiceImpl(userDao, mailSender());
    }

    @Bean
    public MailSender mailSender() {
        return new MailSenderTest();
    }
}

 

이제 테스트 환경에서는 이거를 주입하면 될 거 같다.

그렇다고 이거를 ComponentScan의 범위로 넣을 수는 없을 것이기에, 해당 테스트 환경에서만 주입해주도록 해야한다.

 

@ExtendWith(SpringExtension.class)
@ContextConfiguration(classes = {TestApplicationContext.class, TestAppContext.class})
class UserDaoTest {}

 

마지막으로 데이터베이스 연결과 같은 부분도 분리하도록 하겠다.

결국 Configuration에도 같은 관심사끼리 모아두는 것이 유지보수에는 유리할 것이다.

@Configuration
public class SqlServiceContext {

    @Bean
    public SqlRegistry sqlRegistry() {
        return new ConcurrentHashMapSqlRegistry();
    }

    @Bean
    public SqlReader sqlReader() {
        return new YmlSqlReader("/sqlmap.yml");
    }

    @Bean
    public SqlService sqlService() {
        return new YmlSqlService(sqlReader(), sqlRegistry());
    }

    @Bean
    public DataSource dataSource() {
        return new EmbeddedDatabaseBuilder()
                .setName("embeddedDatabase")
                .setType(EmbeddedDatabaseType.H2)
                .addScript("/schema.sql")
                .build();
    }
}

 

이렇게 일단 지금 가지고 있는건 SqlServiceContext, TestAppContext, TestApplicationContext 이렇게 3개이다.

일단 혼동되지 않게 TestApplicationContext를 AppContext로 바꿔주자.

 

이거를 모두 배열로 @ContextConfiguration에 넣어줘야 할까?

하지만 여기서 의존관계를 살펴보면 SqlServiceContext를 AppContext가 필요로하고, 솔직히 테스트 클래스나 TestAppContext는 관심이 없다.

그렇기에 SqlServiceContext를 AppContext에만 직접 넣어주도록 만들어주는 것이 좋을 것 같다.

 

@Import(SqlServiceContext.class)
public class AppContext {}

이 방법으로 직접 넣어주고 다른 부분은 수정하지 않도록 만들자.

 

프로파일

현재 방법은 다음과 같은 문제가 있다.

현재 운영, 테스트가 공통으로 사용하는 AppContext와 TestAppContext 이렇게 2개가 있고 여기 모두에서 UserService 타입의 빈이 정의되어있다.

하나는 MailSenderImpl 타입이고 다른 하나는 MailSenderTest이다.

 

그럼 MailSender를 주입 받을 때, 어떤 타입을 주입받게 될까.

지금도 이렇게 충돌이 일어나고 있고, 우리는 테스트 환경에서는 testUserService를 데리고 오고 싶은 것이다.

이렇게 테스트 환경과 운영환경에서 각각 다른 빈을 가져와야 하는 경우가 많다.

 

스프링은 이렇게 환경에 따라서 빈 설정정보가 달라져야 하는 경우에 간단하게 해당 설정들을 만들 수 있도록 방법을 제공한다.

 

프로파일은 클래스 단위로 지정한다.

@Profile 어노테이션을 사용해서 프로파일의 이름을 넣어주면 된다.

 

@Configuration
@Profile("test")
public class TestAppContext {
}

이제 이렇게 하고 실행을 해보면, 당연히 실패한다.

 

MailSender를 가져오지 못해 실패하는데, 따로 저 profile을 활성화해주지 않아 에러가 발생하는 것이다.

 

@ExtendWith(SpringExtension.class)
@ContextConfiguration(classes = {AppContext.class, TestAppContext.class, ProductionAppContext.class})
@ActiveProfiles("test")
class UserDaoTest {}

이렇게 ActiveProfiles로 test를 활성화 해줘야, test의 profile들을 불러오게 된다.

 

이렇게 설정을 하고 다시 테스트를 돌려보니, 다음과 같이 성공하는 것을 볼 수 있다.

 

 

프로퍼티 소스

현재 데이터베이스의 정보가 이렇게 코드로 들어가있다.

이런 정보가 깃에 올라가면 안되기도 하고, 배포서버와 개발서버에서 다른 데이터베이스를 연결하기에 이런 정보는 코드로 작성해서는 안된다.

 

프로퍼티 파일로 빼도록 하자.

database.yml라는 파일을 만들고 데이터베이스의 정보는 그곳에다가 저장하도록 하겠다.

 

 

그리고 AppContext 내의 코드를 다음과 같이 수정해준다.

 

    @Autowired
    Environment environment;

    @Bean
    public DataSource dataSource() {

        SimpleDriverDataSource dataSource = new SimpleDriverDataSource();

        try
        {
            dataSource.setDriverClass((Class<? extends java.sql.Driver>)Class.forName(environment.getProperty("db.driverClass")));
        }
        catch (ClassNotFoundException e)
        {
            throw new RuntimeException(e);
        }

        dataSource.setUrl(environment.getProperty("db.url"));
        dataSource.setUsername(environment.getProperty("db.username"));
        dataSource.setPassword(environment.getProperty("db.password"));

        return dataSource;
    }

Enviroment를 주입받고, 거기서 하나씩 값을 빼서 사용하는 것이다.

 

이건 뭐랄까, 한번에 많이 가져오는 방법이고 하나씩 가져오는 방법도 있다.

 

    @Value("${db.driverClass}")
    private Class<? extends Driver> driverClassName;

    @Value("${db.url}")
    private String url;

    @Value("${db.username}")
    private String username;

    @Value("${db.password}")
    private String password;

 

이렇게 @Value로 값을 명시하고 값을 가져올 수 있다.

 

이 중 원하는 방법으로 변수들을 빼오면 된다.

나는 아마 @Value...?

728x90

저번에 말했던 실시간으로 수정이 가능한 UpdatableSqlRegistry를 만들어보고자 한다.

 

Sql을 업데이트 할 때, 쿼리를 호출하게 된다면 깨진 Sql이 나타날 수 있기 때문에 동시성 문제에 주의해서 구현해야 한다.

그렇기에 자바에서 동시성 문제를 도와주는 라이브러리를 사용해 만들어보도록 하겠다.

 

ConcurrentHashMap을 이용한 수정 가능 SQL 레지스트리

HashMap에서는 역시 멀티스레드 환경에서 동시성 문제가 발생할 수 있기 때문에, 이런 문제에 최적화된 ConcurrentHashMap을 사용하도록 하겠다.

ConcurrentHashMap은 업데이트시에 해당 부분에만 락을 걸기에, 성능이 많이 떨어지지 않는다.

 

우선 다음과 같은 테스트를 작성한다.

이 테스트가 통과해야 할 것이다.

public class ConcurrentHashMapSqlRegistryTest {

    UpdatableSqlRegistry sqlRegistry;

    @BeforeEach
    public void setUp() {

        sqlRegistry.registerSql("KEY1", "SQL1");
        sqlRegistry.registerSql("KEY2", "SQL2");
        sqlRegistry.registerSql("KEY3", "SQL3");
    }

    @Test
    public void find(){
        Assertions.assertTrue(
                sqlRegistry.findSql("KEY1").equals("SQL1") &&
                        sqlRegistry.findSql("KEY2").equals("SQL2") &&
                        sqlRegistry.findSql("KEY3").equals("SQL3")
        );
    }

    @Test
    public void notFoundKey(){
        Assertions.assertThrows(ChangeSetPersister.NotFoundException.class, () -> sqlRegistry.findSql(UUID.randomUUID().toString()));
    }
    
    @Test
    public void updateSql(){
        sqlRegistry.updateSql("KEY1", "U_SQL1");
        Assertions.assertTrue(
                sqlRegistry.findSql("KEY1").equals("U_SQL1") &&
                        sqlRegistry.findSql("KEY2").equals("SQL2") &&
                        sqlRegistry.findSql("KEY3").equals("SQL3")
        );
    }
    
    @Test
    public void updateMulti(){
        Map<String, String> sqlmap = new HashMap<>();
        
        sqlmap.put("KEY1", "U_SQL1");
        sqlmap.put("KEY3", "U_SQL3");
        
        sqlRegistry.updateSql(sqlmap);
        Assertions.assertTrue(
                sqlRegistry.findSql("KEY1").equals("U_SQL1") &&
                        sqlRegistry.findSql("KEY2").equals("SQL2") &&
                        sqlRegistry.findSql("KEY3").equals("U_SQL3")
        );
    }
}

동시성 관련해서는 멀티쓰레드를 만들어야 하고, 해당 환경에서도 문제가 발생할지 안할지를 잘 모르기에 테스트가 어렵다.

우선은 자바에서 제공해주는 라이브러리를 믿어보도록 하자.

 

그리고 ConcurrentHashMap을 사용하는 Registry를 다음과 같이 구현한다.

public class ConcurrentHashMapSqlRegistry implements UpdatableSqlRegistry {

    private Map<String, String> sqlMap = new ConcurrentHashMap<>();

    @Override
    @SneakyThrows
    public void updateSql(String key, String sql) {
        if(sqlMap.get(key) == null)
            throw new ChangeSetPersister.NotFoundException();

        sqlMap.put(key, sql);
    }

    @Override
    public void updateSql(Map<String, String> sqlmap) {
        sqlmap.forEach(this::updateSql);
    }

    @Override
    public void registerSql(String key, String sql) {
        sqlMap.put(key, sql);
    }

    @SneakyThrows
    @Override
    public String findSql(String key) {
        String sql = sqlMap.get(key);
        if(sql == null) throw new ChangeSetPersister.NotFoundException();
        return sql;
    }
}

 

이거를 바탕을 테스트를 돌려보면

역시 성공하는 것을 볼 수 있다.

 

현재 SqlService에 해당 빈으로 등록 하도록 하자.

<bean id="sqlRegistry" class="seungkyu.ConcurrentHashMapSqlRegistry"/>

 

내장형 데이터베이스를 이용한 SQL 레지스트리 만들기

SqlRegsitry를 ConcurrentHashMap 말고도 데이터베이스로도 만들어 볼 수 있다.

외부로 트래픽이 필요한 외장 데이터베이스보다 애플리케이션에 내장되어 애플리케이션과 함께 실행되고 종료되는 내장 데이터베이스를 사용하는 것이 더 편리하고 빠를 것이다.

 

많이 사용되는 내장 데이터베이스는 Derby, HSQL, H2가 있다고 한다.

이 친구들은 스프링에서 돌아가기에 따로 SQL 스크립트를 만들어서 같이 실행해야 한다고 한다.

초기 Sql을 통해 데이터를 삽입하고 나면 그 뒤에는 JDBC와 같은 기술들을 동일하게 사용 할 수 있다고 한다.

 

일단 이 내장 데이터베이스를 간단하게 사용해보도록 하자.

내장 데이터베이스는 DB가 실행될때마다 테이블을 새로 생성하기에, 테이블을 생성하는 SQL을 같이 넣어줘야 한다.

 

schema.sql

CREATE TABLE SQLMAP(
    KEY_ VARCHAR(100) PRIMARY KEY,
    SQL_ VARCHAR(100) NOT NULL
);

 

그리고 초기에 데이터도 넣어주기 위해 insert로 구성된 data.sql을 작성한다.

INSERT INTO SQLMAP(KEY_, SQL_) values('KEY1', 'SQL1');
INSERT INTO SQLMAP(KEY_, SQL_) values('KEY2', 'SQL2');

 

간단하게 테스트를 작성해보니

package seungkyu;

import org.junit.jupiter.api.*;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.jdbc.datasource.embedded.EmbeddedDatabase;
import org.springframework.jdbc.datasource.embedded.EmbeddedDatabaseBuilder;
import org.springframework.jdbc.datasource.embedded.EmbeddedDatabaseType;

import java.util.concurrent.atomic.AtomicInteger;

public class EmbeddedDbTest {

    EmbeddedDatabase db;
    JdbcTemplate jdbcTemplate;

    @BeforeEach
    public void setUp() {

        db = new EmbeddedDatabaseBuilder()
                .setType(EmbeddedDatabaseType.H2)
                .addScript("/schema.sql")
                .addScript("/data.sql")
                .build();

        jdbcTemplate = new JdbcTemplate(db);
    }

    @AfterEach
    public void tearDown() {
        db.shutdown();
    }

    @Test
    public void initData(){
        Assertions.assertEquals(2, jdbcTemplate.queryForObject("select count(*) from sqlmap", Integer.class));

        AtomicInteger index = new AtomicInteger();

        jdbcTemplate.queryForList("SELECT * FROM sqlmap").forEach(
                (mapEntry) -> {
                    Assertions.assertEquals("KEY" + (index.get() + 1), mapEntry.get("key_"));
                    Assertions.assertEquals("SQL" + (index.get() + 1), mapEntry.get("sql_"));
                    index.getAndIncrement();
                }
        );
    }

}

 

 통과하는 것을 볼 수 있었다.

 

이제 이 내장 데이터베이스를 사용해서 SqlRegistry를 수정해보자.

 

일단 이 내장 데이터베이스를 사용하기 위해서 빈으로 등록하도록 하자.

 

    <jdbc:embedded-database id="embeddedDatabase" type="H2">
        <jdbc:script location="classpath:schema.sql"/>
    </jdbc:embedded-database>

schema는 실행하면서 생성만 하면 되기에 여기에 넣어준다.

 

이제 embeddedDatabase 빈이 등록되어 그냥 이 데이터베이스를 사용하면 된다.

 

이 빈을 사용해서 UpdatableSqlRegistry를 만들어보자.

 

주입받은 내장 데이터베이스의 DataSource를 통해 저장하고 업데이트 하도록 만든다.

package seungkyu;

import org.springframework.dao.EmptyResultDataAccessException;
import org.springframework.data.crossstore.ChangeSetPersister;
import org.springframework.jdbc.core.JdbcTemplate;

import javax.sql.DataSource;
import java.util.Map;

public class EmbeddedDbSqlRegistry implements UpdatableSqlRegistry {

    private final JdbcTemplate jdbcTemplate;

    public EmbeddedDbSqlRegistry(DataSource dataSource) {
        this.jdbcTemplate = new JdbcTemplate(dataSource);
    }

    @Override
    public void registerSql(String key, String sql) {
        jdbcTemplate.update("INSERT INTO sqlmap (key_, sql_) values (?, ?)", key, sql);
    }

    @Override
    public String findSql(String key) {
        try
        {
            return jdbcTemplate.queryForObject("SELECT sql_ FROM sqlmap WHERE key_ = ?", String.class, key);
        }
        catch(EmptyResultDataAccessException e)
        {
            throw new RuntimeException();
        }
    }

    @Override
    public void updateSql(String key, String sql) {
        int changed = jdbcTemplate.update("UPDATE sqlmap SET sql_ = ? WHERE key_ = ?", sql, key);
    }

    @Override
    public void updateSql(Map<String, String> sqlmap) {
        for(Map.Entry<String, String> entry : sqlmap.entrySet()) {
            this.updateSql(entry.getKey(), entry.getValue());
        }
    }
}

 

 

이제 이 EmbeddedDbSqlRegistry를 테스트 해봐야 한다.

근데 재미있게도 ConcurrentHashMapSqlRegistry와 구현한 인터페이스가 같다.

그리고 우리는 그 인터페이스의 내용만 테스트하면 끝이다.

 

그렇기에 해당 테스트 코드를 공유해보자.

 

이런식으로 추상 클래스를 만들고

public abstract class AbstractUpdatableSqlRegistryTest {

    UpdatableSqlRegistry sqlRegistry;

    abstract protected UpdatableSqlRegistry injectSqlRegistry();

    @BeforeEach
    public void setUp() {
        sqlRegistry = injectSqlRegistry();

        sqlRegistry.registerSql("KEY1", "SQL1");
        sqlRegistry.registerSql("KEY2", "SQL2");
        sqlRegistry.registerSql("KEY3", "SQL3");
    }
    //.....
}

 

기존의 ConcurrentHashMapSqlRegistryTest도 이렇게 간단하게 변경했다.

public class ConcurrentHashMapSqlRegistryTest extends AbstractUpdatableSqlRegistryTest{

    @Override
    protected UpdatableSqlRegistry injectSqlRegistry() {
        return new ConcurrentHashMapSqlRegistry();
    }
}

이렇게만 작성하고 테스트를 해봐도

 

기존에 작성한 4개의 테스트를 수행하는 것을 볼 수 있다.

 

이거를 그대로 상속받아 EmbeddedDbSqlRegistryTest를 만들어보자.

public class EmbeddedDbSqlRegistryTest extends AbstractUpdatableSqlRegistryTest{

    EmbeddedDatabase db;

    @Override
    protected UpdatableSqlRegistry injectSqlRegistry() {
        db = new EmbeddedDatabaseBuilder()
                .setType(EmbeddedDatabaseType.H2)
                .addScript("/schema.sql")
                .build();

        return new EmbeddedDbSqlRegistry(db);
    }

    @AfterEach
    public void tearDown() {
        db.shutdown();
    }
}

 

이렇게 작성하고 테스트를 실행해보니, 다행하게 통과하는 것을 볼 수 있었다.

 

이제 저 EmbeddedDbSqlRegistry에 DataSource를 주입해줘야 한다.

아무생각없이 DataSource를 찾아 넣으면 MySql로 들어가기에 내장 데이터베이스를 잘 찾아서 넣어줘야 한다.

 

    <bean id="sqlRegistry" class="seungkyu.EmbeddedDbSqlRegistry">
        <constructor-arg ref="embeddedDatabase"/>
    </bean>

    <jdbc:embedded-database id="embeddedDatabase" type="H2">
        <jdbc:script location="classpath:schema.sql"/>
    </jdbc:embedded-database>

이렇게 embeddedDatabase의 빈을 또 만들고 그 빈으로 주입을 해줘야 내장데이터베이스로 설정이 된다.

 

트랜잭션 적용

만약 쿼리들이 등록되고 있는 중간에, 해당 쿼리를 조회하면 어떻게 될까?

반복문을 통해 등록하는 중간에 아직 등록되지 않은 쿼리를 조회할 수도 있을 것이다.

이런 이유로 각 메서드에 알맞은 트랜잭션 설정을 해줘야 한다.

 

우선 테스트 먼저 작성한다.


    @Test
    public void transactionTest(){
        Map<String, String> sqlmap = new HashMap<>();
        sqlmap.put("KEY1", "U_SQL1");
        sqlmap.put(UUID.randomUUID().toString(), UUID.randomUUID().toString());

        try
        {
            sqlRegistry.updateSql(sqlmap);
            Assertions.fail();
        }
        catch (RuntimeException e)
        {
            Assertions.assertTrue(
                    sqlRegistry.findSql("KEY1").equals("SQL1") &&
                            sqlRegistry.findSql("KEY2").equals("SQL2") &&
                            sqlRegistry.findSql("KEY3").equals("SQL3")
            );
        }
    }

 

중간에 없는 key로 조회를 하면 에러가 발생하는지 테스트이다.

그리고 만약 에러가 발생했다면 롤백도 되는지 테스트한다.

 

당연히 지금은 롤백이 되지 않아 실패한다.

 

트랜잭션은 마지막 부분에만 필요하기에

package seungkyu;

import org.jetbrains.annotations.NotNull;
import org.springframework.dao.EmptyResultDataAccessException;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.jdbc.datasource.DataSourceTransactionManager;
import org.springframework.transaction.TransactionStatus;
import org.springframework.transaction.support.TransactionCallbackWithoutResult;
import org.springframework.transaction.support.TransactionTemplate;

import javax.sql.DataSource;
import java.util.Map;

public class EmbeddedDbSqlRegistry implements UpdatableSqlRegistry {

    private final JdbcTemplate jdbcTemplate;
    private final TransactionTemplate transactionTemplate;

    public EmbeddedDbSqlRegistry(DataSource dataSource) {
        this.jdbcTemplate = new JdbcTemplate(dataSource);
        this.transactionTemplate = new TransactionTemplate(new DataSourceTransactionManager(dataSource));
    }

    @Override
    public void updateSql(Map<String, String> sqlmap) {
        transactionTemplate.execute(new TransactionCallbackWithoutResult() {
            protected void doInTransactionWithoutResult(@NotNull TransactionStatus status) {
                for(Map.Entry<String, String> entry : sqlmap.entrySet()) {
                    updateSql(entry.getKey(), entry.getValue());
                }
            }
        });
    }
}

해당 부분만 트랜잭션으로 감싸준다.

 

그리고 테스트를 수행해보면 다음과 같이 성공하는 것을 볼 수 있다.

+ Recent posts