두루미의 개발기록 두루미의 개발기록

회사에서 개발자 간 사용하고 있는 Node 버전이 모두 다르던 때가 있습니다. 따라서 운영되는 서버의 Node 버전을 확인하고, 문서화하여 협업하는 개발자 간에 Node 버전을 일치 시키도록 했습니다.하지만 모든 개발자가 프로젝트 별로 적절한 Node 버전을 사용하고 있다는 것을 신뢰할 수 없고, 다양한 프로젝트 별로 Node 버전을 다를 수 있습니다. 만약 여러 프로젝트를 관리한다면 매번 새로운 Node 버전을 설치해주거나 Node Version Manager Tool(Nvm, Fnm 등) 를 통해 변경해줘야 합니다. 이러한 과정을 매번 반복한다면 Node 버전을 바꾸는 것을 깜빡하고 개발을 하였다가 실환경에 배포된 후에 버전이 일치하지 않아 문제가 발생할 수도 있습니다. 위와 같은 문제들은 packa..

아래 모든 예제 코드들은 Typescript Playground 에서 작성했습니다. 유저가 존재하는지에 대한 여부를 확인하는 로직이 아래와 같다고 가정해봅시다. interface User { readonly id: number; readonly name: string; readonly email: string; } declare const user: User | null; function validateNotNullUser(user: User | null) { if (!user) { throw new Error('유저가 존재하지 않습니다'); } } validateNotNullUser(user); user; // User | null validateNotNullUser 함수는 유저가 존재하지 않을 경우 ..

아래 private 으로 선언된 필드들을 가지고 있는 클래스가 있다. class Foo { private num: number; private str: string; constructor(num: number, str: string) { this.num = num; this.str = str; } } const foo = new Foo(1, 'str'); 만약 num 이나 str 필드를 읽으려고 한다면 에러가 발생할 것이다. // TS2341: Property 'num' is private and only accessible within class 'Foo'. foo.num; 에러 메시지를 확인해보면 num 속성은 private 이고, 클래스 내부에서만 접근이 가능하다는 것이다. 그렇다면 private ..

NodeJS, NestJS - Cpu Intensive 한 작업 처리하기 NodeJS 는 싱글 스레드지만 비동기 + Non-Blocking 의 특징을 가지고 있기 때문에 I/O 작업이 빈번한 경우에는 좋지만 싱글스레드이기 때문에 CPU Intensive 한 작업을 처리하기에는 좋지 않다는 특징을 가지고 있습니다. 만약 Node 기반의 서버가 CPU Intensive 한 작업을 할 경우 어떻게 될까요? import { Controller, Get } from '@nestjs/common'; @Controller('cpu-intensive') export class CpuIntensiveController { private calCount(num = 2_000_000_000_000) { let count =..

NestJS Custom Exception 기본적으로 예외를 처리하는 방법은 아래 코드의 방법과 같습니다. 표준 예외와 메시지를 통해 충분히 어떤 예외를 발생하는지 추측하고 확인할 수 있습니다. if (!product) { throw new NotFoundException('제품을 찾을 수 없습니다'); } 1. 가독성 하지만 아래처럼 Custom Exception 을 사용한다면 로직상 가독성을 높일 수 있습니다.. Custom Exception 은 클래스의 네이밍을 통해 일차적으로 어떤 예외가 발생했는지 유추가 가능합니다. // exception/product-not-founct-exception.ts import {NotFoundException} from "@nestjs/common"; export..

NestJS 는 Spring 처럼 기본적으로 생성자 기반의 DI(Dependency Injection) 을 지원합니다. DI 는 Ioc 컨테이너에 객체의 인스턴스화를 위임하는 역전의 제어(Inversion of Control) 기술입니다. 그리고 의존성 주입(DI) 은 객체지향의 5 대 원칙 중 DIP(의존 관계 역전 원칙) 를 따르는 방법 중에 하나입니다. 또한 중요한 또 다른 원칙이 있는데 바로 OCP(개방폐쇄원칙) 입니다. DIP: "추상화에 의존해야지 구체화에 의존하면 안된다" OCP: "확장에는 열려있으나 변경에는 닫혀있어야 한다" 그렇다면 어떻게 설계해야 이 원칙을 잘 지킬 수 있을까요? 아래의 예제를 통해 알아봅시다. 아래 예제는 기본적으로 NestJS 에서 DI 를 사용하는 방법입니다. M..

Docker 를 왜 사용할까? 우선 도커란 무엇일까요? 도커는 어플리케이션을 신속하게 구축, 테스트 및 배포할 수 있는 소프트웨어 플랫폼입니다. Linux 의 응용 프로그램들을 프로세스 격리 기술들을 사용해서 컨테이너로 실행하고 관리하는 오픈 소스 프로젝트이다. 그렇다면 컨테이너란 무엇이고 왜 사용해야 할까요? 컨테이너 컨테이너는 표준화된 소프트웨어 유닛 또는 패키지이며, 해당 코드가 실행하는데 필요한 종속성과 도구 등이 포함되어 있습니다. 예를 들어보면 큰 배나 트럭에 싣는 컨테이너에 비유할 수 있습니다. 컨테이너에는 다양한 것들을 담을 수 있지만, 담고 난 뒤에는 격리되어 자체적으로 보관됩니다. 왜 Docker 와 컨테이너일까? 1. 팀/회사 내에 다른 개발/생산 환경 실제로 협업에서는 팀 또는 회사..

Typescript 로 알아보는 SOLID(객체지향 설계) 주로 Express 를 통해 서버를 개발하다가, 최근 NestJS 를 사용하고 공부하다 보니 객체지향 설계에 대해 더욱 궁금하고 깊게 알고 싶어져 정리하게 되었습니다. SOLID 디자인 원칙은 더 나은, 더 깔끔한 코드를 작성하는 방법으로 Robert C. Martin 이라는 소프트웨어 엔지니어가 발명했습니다. SOLID 원칙을 Typescript 를 통해 알아볼려고 합니다. 1. Single Responsibility Principle(SRP) - 단일 책임 원칙 "어떤 클래스를 변경해야하는 이유는 단 하나뿐이여야 한다" 클래스는 하나의 목적과 책임을 가지고 있어야하기에, 변경하기 위한 이유도 하나이어야 한다. 이 원칙을 따르게 된다면 코드를 ..