전체 글 (24) 썸네일형 리스트형 토큰 검증시 캐시 처리하기 이번에 인증서버 작업을 신행하면서 리소스서버에 접근할시, 토큰을 검증하는 부분이 필연적으로 발생하게 되는데, 페이로드안의 유저아이디가 db상에 존재하는지를 확인하기 위해 API 호출마다 쿼리가 발생하는 것을 보게되었다. 이 부분은 나중에 db 부하지점이 될 수 있고, 반복적인 읽기에 대한 호출이기에 캐시로 처리를 하기로 했다. 캐시의 읽기 전략은 look aside 패턴을 사용했다. 플로우는 대략 아래와 같다. - 데이터를 찾을때 우선 캐시된 데이터를 우선 확인하여 있으면(cache Hit) 캐시데이터를 제공한다. - 캐시된 데이터가 없으면 DB에서 조회한다. - DB에서 조회해온 데이터를 cache store에 업데이트 한다. 캐시의 만료시간 TTL을 accessToken의 만료 시간(1시간)으로 잡았.. 모듈의 철학 nest에서는 모듈로 DI를 관리하게하는데, 각 기능을 컴포넌트화해서 조립해서 쓰는 것 처럼 느껴진다. 네스트의 모듈은 앵귤러에서 영감을 받았다고 하는데 앵귤러 도큐먼트를 찾아보니 '모듈은 부트스트랩 메커니즘을 제공한다'라는 말을 한다. 부트스트랩 메커니즘이란 무엇일까? DI의 장점과 단점 NestJs는 의존성 주입 시스템을 지원한다. 네스트는 생성자를 통한 의존성 주입 방법을 사용하고 있다. 생성자 주입방식은 생성자의 호출시점에 한번 호출되는 것을 보장할 수 있다. 따라서 불변하게 설계할 수 있다. 의존성 주입의 주요 목적은 클래스간 결합도를 낮추는 것이다.( 클래스간 결합도가 높으면 테스트가 어려워진다.) 의존성 주입의 장점 코드의 재사용성, 유연성이 높아진다. 하나의 작업만 수행하는 작은 객체는 많은 상황에서 재결합하고 재사용하기가 쉽기 때문이다. 객체간 결합도가 낮기 때문에 한 클래스를 수정했을 때 다른 클래스도 수정해야 하는 상황을 막아준다 유지보수가 쉬우며 테스트가 용이해진다 확장성을 가진다 의존성 주입의 단점 책임이 분리되어 있기 때문에 클래스 수를 늘림으로써 복잡성이 증가한다.. 이전 1 2 3 4 ··· 8 다음