비동기 API를 이용할 때 Promise.all로 비동기 요청을 병렬 처리하는 경우가 많다.그런데 병렬 처리시 어떤 비동기 API를 사용하느냐에 따라서 몇몇 요청이 지연되는 케이스가 생길 수도 있다. 비동기 API 처리 과정Nodejs에서 비동기 처리는 libuv 라이브러리가 담당한다.libuv는 비동기 요청이 들어오면 커널단에서 비동기적으로 처리가 가능한지 확인한다. 커널에서의 비동기 처리 가능 유무에 따라 다음과 같이 동작한다.- 커널에서 비동기 처리 지원 O -> 메인스레드에서 커널에 비동기 작업 요청- 커널에서 비동기 처리 지원 X -> 스레드풀의 스레드에서 커널에 동기 작업 요청 libuv는 비동기 I/O를 blocking하지 않게 설계되어 있기 때문에 메인스레드에서 직접 커널에 요청을 날린다...
Nest can't resolve dependencies of the RedisCoreModule (Symbol(REDIS_MODULE_OPTIONS), ?). Please make sure that the argument ModuleRef at index [1] is available in the RedisCoreModule context. NestJS v10.0.0 부터 발생하는 이슈다. 이와 관련한 이슈에 대한 해결책으로 대부분의 블로그에서 nestjs-redis 모듈 대신 @liaoliaots/nestjs-redis 사용하라고 권하고 있다. https://www.npmjs.com/package/@liaoliaots/nestjs-redis 그런데 이 모듈 또한 에러가 발생했고, 레포지토리 이슈를 보..
해당 글은 node v16.13.0을 기준으로 작성되었습니다. 본인이 사용하는 node 버전에 따라 인터프리터가 생성하는 바이트코드가 달라질 수도 있습니다. 일반적으로는 var는 호이스팅이 되어서 중복 선언이 가능하다고 알려져있고, let, const는 호이스팅이 되지 않아 중복 선언이 되지 않는다고들 알고 있다. 여기서 더 나아가서 let, const가 호이스팅이 되지만 TDZ에 의해서 변수가 초기화되기 전까지는 접근이 불가능하다는걸 알고 있는 사람들도 많을 것이다. 그러면 여기서 더 더 나아가서, v8 엔진이 자바스크립트 코드를 어떻게 해석하길래 호이스팅이나 TDZ가 우리가 생각하는대로 동작하는지 알아보자. 바이트코드를 출력하기 위해서는 --print_bytecode 옵션을 이용하면 된다. ex) n..
User 엔티티에 managerSeq라는 Foreign Key가 존재한다면 아래처럼 관계를 명시해주어야 한다. @Entity class User { @Column() seq: number @Column() id: string @Column() name: string @Column() managerSeq: number @ManyToOne(() => Manager) manager: Manager } User 엔티티의 manager는 foreign key인 managerSeq와의 관계를 설명하기 위해 작성했을 뿐, 실제로는 User가 가지고 있지 않은 값이다. 하지만 그럼에도 find, findOne와 같은 함수로 response를 가져오면 manager가 property로써 타입 추론이 된다. 2022-10..
이 글은 NestJS를 기준으로 작성하였습니다. 데이터베이스에서 데이터를 가져올 때 TypeORM과 같은 ORM들은 클래스(엔티티)에 쿼리 결과를 매핑하여 가져온다. find, findBy와 같은 함수나 createQueryBuilder의 getMany, getOne과 같은 함수들 말이다. 본론으로 들어가기 전에 위의 함수들을 간단히 살펴보고 들어가자. find, findOne 간단한 CRUD를 만들 때 굉장히 편하다. find를 사용하면 여러 개의 데이터를 리턴받을 수 있고, findOne은 한 개의 데이터를 리턴받는다. 파라미터에 select, where, join 등을 명시해주면 원하는 데이터를 엔티티에 매핑해주어 가져올 수 있다. findBy, findOneBy는 where 조건만 파라미터로 줄 ..
쿼리를 짜다보면 Slow Query에 부딪히는 경우가 생긴다. 데이터가 쌓일수록 점점 느려지는 쿼리를 개선해야 하는데 어떻게 해야할까? EXPLAIN 명령어를 통해서 데이터베이스 옵티마이저의 실행계획을 볼 수 있다. EXPLAIN SELECT * FROM test MySQL은 내가 알기로는 표 모양으로 실행 계획을 보여준다. 다른 SQL 또한 비슷하게 잘 보여주는 것으로 안다. 하지만 PostgreSQL은 텍스트로 실행계획을 보여주기 때문에 실행계획을 파악하기가 좀 힘들다. 그래서 PostgreSQL을 사용하는 개발자라면 이 사이트를 추천한다. explain.dalibo.com explain.dalibo.com 쿼리문 앞에 EXPLAIN (ANALYZE, COSTS, VERBOSE, BUFFERS, FO..
