스프링으로 개발할 때 보통 Response DTO를 간편하게 만들기 위해 파라미터로 entity를 받는 생성자를 하나 만들곤 했는데, NestJS로 개발할 때는 이 방식에 좀 문제가 있더라고.Nest CLI로 NestJS 프로젝트를 만들면 기본적으로 tsconfig.j
옛날에 C/C++로 코딩할 때면 하지만 이제는 IntelliJ에서든, VS Code에서든 import ...\`를 손수 타이핑하는 거의 없지. 아래의 1번이나 2번 방식으로 자동으로 import하니까.이런 식으로 여기저기 많은 import를 추가하게 되는데,이때 Nes
ACID ? 제대로 된 "트랜잭션"이라면 네 가지(Atomicity, Consistency, Isolation, Durability)는 충족해야 한다라는 의미로 만든 건데, Consistency(일관성)에 대한 설명들이 참 불친절하다. 읽어도 제대로 이해되지 않는다.
number string 허용, nullable, custom decorator, undefined vs null
@prisma/client를 먼저 설치하면@nestjs/config 설치 후AppModule의 @Module 데코레이터의 imports에다가 아래처럼 '.env.dev'를 명시하여 DynamicModule을 추가하더라도 .env.dev는 안 읽고 .env만 읽는다.@p
. 별개의 작업을 하나의 작업처럼 처리해야 될 때가 있어. 예: 송금할 때 내 계좌 잔고를 빼고, 상대방 계좌 잔고를 늘리는 것 어느 하나의 작업만 성공하면 엉망이 되겠지. 다 성공하거나 다 실패하거나 해야 할 거야. 이걸 가능하게 하는 게 트랜잭션이야. . Spri
NestJS는 DTO를 재사용할 수 있는 유용한 기능들을 제공해.PartialType()부모 DTO의 모든 속성들을 물려받지만 전부 OptionalPickType()부모 DTO의 속성 중 몇 개만 골라서 물려받음OmitType()부모 DTO의 속성 중 몇 개만 제외하고
함수(increment) 스코프({}) 밖에 변수(count)가 하나 있어.당연히 함수 안에서도 count를 사용할 수 있지.대충 위의 count랑 increment를 묶어서 클로저라고 생각해.이제 실용적으로 접근해 보자.아래 counter()는 클로저를 이용해서 어떤
배운 지 얼마 되지 않았을 때 setXxx() 함수로 업데이트할 때마다 즉시 함수 컴포넌트가 다시 실행될 거라 오해한 적이 있었다.\+ 버튼을 클릭할 때마다 카운트가 3씩 증가하는 카운터콘솔 출력초기 렌더링첫 번째 클릭두 번째 클릭부터발견setCount() 함수를 호출
없었던 unique constraints를 새로 만들 때는 주의해야 함. 추가로 있었던 여러 컬럼 unique 날릴 때도.
async 함수는 기본적으로 Promise(상태: fulfilled, 결과: undefined)를 반환한다.만약 이 async 함수를 await와 함께 호출했다면 반환되는 Promise가 이미 fulfilled이니 바로 undefined가 튀어나왔을 것이다.그렇다면,
saveAll()에서 매번 save()를 호출하기 때문에 구현상 차이는 없음(SimpleJpaRepository.java를 참고함)그러나 분명 성능 차이가 존재엔티티를 100만 개 저장해 보았을 때 걸린 시간save(): 9.738s, 10.196s, 10.449s,
다음의 글을 재밌게 읽어서 관련 내용을 이해하고 재서술해 보았다. TypeScript 타입 시스템 뜯어보기: 타입 호환성, 김병묵, 토스 기술 블로그 특히, Branding 부분을 보강하고 좀 더 쉽게 풀었다.
코틀린에도 있는 문법. 그러나 백엔드의 경우, 통제 가능한 영역에서는 최대한 nullable type을 줄이고, 통제가 어려운 데이터는 가능하면 받자마자 처리 후 내부적으로는 non-nullable type으로 다루는 것이 편하다고 생각한다.그래서 지금까지는 사용할 일