Deno 에 대한 생각
노드의 약점은 대부분의 비동기 작업이 EventEmitter 를 기반으로 진행되었다는 점이다. 반면 Deno 는 이런 제약이 상대적으로 적다. 노드가 개발될 당시 자바스크립트는 Promise 를 네이티브로 지원하지 않았다.
러스트의 Future 타입을 Promise 로 바인딩 했다는 점에서 Node.js 가 가진 약점을 극복했다고 본다.
타입스크립트 지원은 또 다른 문제다. 동적 타입 스크립트 언어가 가지는 생산성의 장점이 일부 희석되고 동적 타입 기반의 유연한 코드들이 강타입 언어로 즉시 변환되는 것은 어려움이 있을 것이다.
이는 패러다임의 변화라고 생각한다. 자바스크립트를 대용해서 타입스크립트를 사용하지 않아야 한다.
설계와 구현이 달라지는 기회나 목적이 있다면 타입스크립트의 도입은 긍정적으로 본다. 다양한 프로젝트에서 node 에서 deno 로 런타임의 변화는 크게 없을 것 같다. 파이썬 2 에서 파이썬 3 로 변화하는 과정보다 한참 더딜 것이다.
스트롱루프의 Loopback
스트롱루프의 loopback 프레임워크 그냥 express 감싸놓은 것인 줄 알았는데 아니네.
스프링 타겟의 자바스크립트 프레임워크
sail.js 보다 괜찮은 걸로 생각되고 최신 트랜드의 nest.js 보다 빅브러더 느낌이 난다.
레이블 필드의 타입에 대해
RDB 에 저장되는 값 중 실제 표현은 라벨인데 저장되는 값은 Number 타입을 사용하는 경우가 있다. 보통 공간 절약이나 인덱스를 염두해 두고 설계를 하는데 이는 약간 안티 패턴이 될 수 있다.
랜더링 될 화면의 타입이 A, B 또는 미적용(출력하지 않음)인데 이를 0, 1, 2 로 하는 것이 과연 얼마나 큰 이득일까를 생각하자는 것이다.
그동안 나는 후자의 선택을 했다.
(tbc)
서비스 구현과 인프라 리소스 분리
서비스에 남는 로그를 통해 대시보드로 데이터를 전달하는 일은 어느 곳에나 늘 필요한 일이다.
최근 서비스에서 애플리케이션 로그 뿐 아니라 API 퍼포먼스 로그 및 관리자 감사 로그도 남기고 있는데 이를 우선 StackDriver 서비스로 취합하기로 했다.
로거는 pino 를 사용하고 있는데 pino 에서 StackDriver 로 직접 스트리밍을 지원한다. 하지만 이를 사용하는 것은 적당하지 않다는 조언을 받았다.
그래서 Pino 는 가장 심플하게 file 로 로그를 남긴다. GCS 를 사용하고 있기에 이 로그 파일을 스택 드라이버로 올리는 작업을 추가하고 StackDriver 는 여기에 올라온 파일을 취합 하는 것으로 인프라를 구성하는 과정으로 진행되었다.
서비스와 인프라가 커플링되는 것을 막는 것은 여러모로 중요한 일임을 깨닫는데는 오래 걸리지 않았다.
링크들
