아장아장 키보드소리 아장아장 키보드소리

Swagger가 뭐야? API 문서화 툴로서, API의 요청/응답 데이터, 파라미터, 경로, 헤더 등 API를 이용하는 데 필요한 모든 정보를 제공합니다. 또 API를 이용하는 클라이언트가 API를 쉽게 이해하고, 테스트할 수 있으며, 개발자는 API의 사용 방법을 명확하게 이해할 수 있습니다. 저희는 NestJs에서 소개하는 @nestjs/swagger 모듈을 사용하여 스웨거 문서를 만들도록 하겠습니다. @nestjs/swagger를 사용하여 swagger 문서 만들기 1. 모듈 install npm install --save @nestjs/swagger 2. main.ts에서 swagger setup main.ts async function bootstrap() { ... const config = ..

오브젝트 스캔 유형 1.테이블 스캔 (Table Scan) : 인덱스를 거치지 않고 바로 디스크에 위치한 테이블 데이터에 접근 (1) 테이블 풀 스캔 (Table Full Scan) 테이블의 처음부터 끝까지 데이터를 훑어보는 방식으로 인덱스를 사용하지 않는 유일한 방식 사용 where 접의 조건문을 기준으로 활용할 인덱스가 없는 경우 전체 데이터 대비 대량의 데이터가 필요할 경우 (보통 20%~25%) 2.인덱스 스캔 : 인덱스로 테이블 데이터를 찾아가는 유형 (1) 인덱스 범위 스캔 (Index Range Scan) 인덱스를 범위 기준으로 스캔한 뒤 스캔 결과를 토대로 테이블 데이터를 찾는 방식 사용 BETWEEN ~ AND 구문이나 , LIKE 구문 등 비교 연산 및 구문에 포함될 경우 특징 좁은 범..

예제 코드 select 유저.등록번호, 유저.이름, 유저상세.전화번호, 유저상세.주소 from 유저 join 유저상세 on 유저.등록번호 = 유저상세.등록번호 where 유저.등록번호 IN (1,100); 위 예제 코드를 보면 두개의 테이블을 조인하여 쿼리를 수행하고 있습니다. 두 테이블에 동시에 접근할 수 없기 때문에 선후 관계를 갖고 먼저 접근하는 테이블을 드라이빙 테이블(유저), 후에 접근하는 테이블을 드리븐 테이블(유저상세)이라고 합니다. 드라이빙 테이블에서 많은 건수가 반환되면 해당 결과를 가지고 드리븐 테이블에 접근하기 때문에 드라이빙 테이블을 선정하는 과정은 매우 중요합니다. 가능하면 적은 결과가 반환되는 테이블을 드라이빙 테이블로 선정하고 조인 조건절의 컬럼이 인덱스로 설정되도록 구성해야합..

간단한 설문조사 프로젝트를 만들던 중 문득 의문이 들었다. 의문 인바운드 포트와 아웃 바운드 포트의 인풋, 아웃풋이 같은 경우가 상당히 많은데 구지 똑같은 타입을 여러개 선언할 필요가 있을까?? TypeOrm을 사용하기 때문에 엔티티의 클래스와 TypeScript의 유틸리티 타입을 사용하면 유지보수 측면에서 더 좋지 않을까? 리펙토링 도전 before survey/out-port/survey-findone.op.ts 인바운드 포트, 아웃바운드 포트의 output 타입은 같습니다. export type SurveyFindOneOutPortOutputDto = { id: number; name: string; description: string; question: Array; }; after survey/t..

컨트롤러의 엔드포인트에서 @Query 데코레이터를 사용하여 page, size, sort 변수값을 핸들링 하는 과정을 기록하는 포스팅 통과 기준 page, size, sort 변수값을 입력하지 않을 경우 default value 리턴 page, size, sort의 타입이 일치하지 않는 경우 에러 리턴 page, size, sort 변수 중 일부를 제외한 요청에 정상 작동해야 한다 @Query() 변수에 기본값을 설정한 후 리턴 실험 코드 enum SORT_OPTION { ASC ='ASC', DESC = 'DESC' } @Get('find') async findAll( @Query('page') page: number = 1, @Query('size') size: number = 10, @Query( ..

소프트웨어를 개발하면서 예외처리는 필수 사항이다. 만약 예외 상황이 발생할 경우 프로그램이 강제로 종료될 수 있어 사용자에게 나쁜 경험을 제공하며 심각할 경우 데이터 손실을 초래할 수 있다. 예외 처리를 통해 발생한 오류 메시지를 적절하게 처리하면, 디버깅과 오류 추적이 용이해지고 오류가 발생한 원인과 위치를 파악할 수 있다. 또 예기치 않은 입력이나 상황에 대응할 수 있어 안정성을 높이고 예외 상황에 대한 처리 방법을 명시적으로 나타내 코드의 가독성을 높여준다. 목표 예측 가능한 에러 httpException 처리 Http Response 값 체크 후 에러 처리 query error 전부 핸들링 데이타베이스 에러는 전부 500 에러로 처리 개발자의 실수로 발생한 서버에러 핸들링 개발자의 실수로 발생하는..

TypeOrm을 사용하여 엔티티를 선언할 때 공통적으로 들어가는 컬럼들을 모든 엔티티에 하나하나 선언하는건 유지보수 측면에서 너무 불편하다고 판단했다. 예를들어 id, created_at, updated_at가 있다. 공통적으로 여러 엔티티에서 사용하는 컬럼들은 쉽게 관리할 수 있도록 추상클래스에 선언한 후 추상 클래스를 extends사용할 계획이다. 클래스가 아닌 추상 클래스를 선택한 이유 : 직접 사용할 일이 없기 때문에 추상 클래스를 선택 1. 공통적으로 사용될 id, created_at, updated_at 컬럼이 선언된 BaseEntity 추상 클래스를 선언한다. import { CreateDateColumn, Entity, PrimaryGeneratedColumn, UpdateDateColum..

NestJs + TypeOrm을 사용해서 프로젝트를 진행하던 도중 Option 엔티티의 테이블명을 따로 지정하지 않고 프로젝트를 진행했다. seed data를 넣고 테스트를 하던 중 option 테이블의 인덱스 목록을 확인하고자 SHOW INDEXES FROM option 명령을 진행하니 아래와 같은 에러가 발생했다. 테이블 명을 question_option 과 question-option으로 바꿔서 진행했지만 동일한 에러가 발생했다. 1. index 확인 불가 2. 테이블 명을 question-option 또는 question_option으로 변경 후 select 명령 실행 시 아래와 같은 에러가 발생 해결 방안 1. `option` 와 같이 백쿼드로 감싸고 사용한다. -> 여러가지 상황을 고려한다면 ..