fluo

Fluo를 만들면서 중요하게 생각한 것 중 하나는, 이미 만든 기능을 다른 실행 환경에서도 다시 쓸 수 있어야 한다는 것이었다. 인증이나 검증, 데이터베이스 연동을 만들어 놓고 새로운 서버를 지원할 때마다 그 기능들을 다시 연결해야 한다면, 패키지를 나눠 둔 보람이 별로 없을 것 같았다…

DI가 core 패키지 안에서만 잘 동작하면 아직 절반이다. 실제 프레임워크의 가치는 다른 패키지들이 같은 규칙 위에 올라갈 때 드러난다. CQRS는 compiled module graph를 읽어 handler를 발견하고, Config는 dynamic module과 lifecycle h…

DI 구조를 여기까지 따라오면 자연스럽게 남는 질문이 있다. 이렇게 명시적으로 token을 쓰고, provider를 정규화하고, module graph와 scope를 엄격하게 나누면 테스트에서는 무엇이 좋아지는가? 단순히 테스트 helper가 몇 개 더 생기는 정도라면 조금 허무하다.…

객체를 만드는 일은 늘 더 그럴듯해 보인다. 인스턴스가 생기고, 의존성이 주입되고, 서비스가 일을 시작한다. 하지만 오래 살아남는 애플리케이션에서 더 중요한 질문은 “어떻게 만들었는가”보다 “언제, 어떤 순서로 닫히는가”일 때가 많다. 파일 핸들, DB connection, watche…

DI 컨테이너에서 가장 눈에 띄는 순간은 결국 객체가 만들어지는 순간이다. container.resolve(token)을 호출했고, 어딘가에서 new MyClass(...deps)가 실행되며, 사용자는 원하는 인스턴스를 받는다. 그런데 이 장면만 보면 너무 많은 것이 생략된다. 좋은 D…

resolve()는 겉으로 보면 token 하나를 넣고 값을 받는 단순한 함수다. 하지만 컨테이너 입장에서는 그 token이 어디에 등록되어 있는지, parent container까지 올라가야 하는지, multi provider를 합쳐야 하는지, request scope를 타야 하는지,…

컴파일된 모듈 그래프가 생겼다고 해서 애플리케이션이 곧바로 살아나는 것은 아니다. 아직 provider는 컨테이너에 들어가야 하고, controller와 middleware도 등록되어야 하며, lifecycle hook은 정해진 순서로 실행되어야 한다. 이 순서가 흐트러지면 애플리케이션…

모듈 그래프는 설계만으로 끝나지 않는다. 런타임은 실제로 이 그래프를 걸어 다니며 “이 구조로 애플리케이션을 띄워도 되는가”를 확인해야 한다. 이 단계에서 실패하지 않으면 더 뒤에서 실패한다. 그리고 뒤에서 실패하는 DI 에러는 대개 표정이 좋지 않다. request가 들어온 뒤에 “사…

DI 컨테이너에서 provider를 등록하는 일만 보면 모듈은 단순한 폴더 묶음처럼 보일 수 있다. 하지만 실제 애플리케이션은 “어디에 무엇이 있느냐”보다 “어디에서 무엇을 볼 수 있느냐” 때문에 더 자주 망가진다. provider가 존재한다는 사실만으로는 충분하지 않다. 그 provi…

DI 컨테이너에게 “이걸 넣어줘”라고 말하려면, 먼저 “이것”을 가리키는 주소가 필요하다. 사람끼리는 “그 서비스 있잖아” 정도로도 대화가 되지만, 컨테이너는 그런 눈치가 없다. 다행히 눈치 없는 도구일수록 주소 체계가 분명해야 오래 버틴다. fluo에서 그 주소가 바로 token이다.…

NestJS 프로젝트를 처음 만들면 이상하게 빠지지 않는 주문이 있다. experimentalDecorators, emitDecoratorMetadata, 그리고 엔트리 파일 어딘가의 reflect-metadata import다. 처음에는 “프레임워크가 하라는 대로 하면 되겠지” 하고…

DI 컨테이너는 겉으로 보면 꽤 조용한 도구다. 클래스를 하나 달라고 하면 인스턴스가 나오고, 모듈을 부트스트랩하면 provider들이 알아서 이어진다. 문제는 “알아서”라는 단어가 커질수록 코드가 점점 마법처럼 보인다는 데 있다. 마법은 데모에서는 멋지지만, 장애가 나면 갑자기 로그를…