Seonglae ChoNode 문제점
- 중앙 집중형 모듈 시스템
- 추가 지원이 필요한 legacy API들
- 빈약한 보안
Node는 웹 서버로 시작되었습니다. 모듈들을 어디에 넣을까 고민하다가, 아.. node modeuls에 넣을까? 해서 만들어진 것이 node_modules 디렉토리입니다. 디자인적으로 아쉬운 점이 있습니다. 그래서 어쩔 수 없이 npm과 같은 중앙 서버가 존재해야 합니다. 웹은 원래 분산 형태여야 하는데 말이죠
보안에서도 아쉬운 점이 있습니다. 리소스에 대한 권한 설정이 전혀 없기 때문에 주요 자원들을 누구나 접근 할 수 있습니다. 예를 들어, SSH Key같은 것들 말입니다. 이러한 것들을 샌드박스로 감싸는 것으로 문제를 해결 할 수 있습니다. 이 문제는 Node 뿐만이 아니고 Python이나 Ruby도 가지고 있긴 합니다
좋은 스크립팅 플랫폼은 현상에 안주하지 말고 계속 발전해야 합니다. 오랫동안 정적 컴파일 언어 전문가로 지내면서, rust나 go로 low-level 시스템 프로그래밍을 하는 것은 당연한 일이었습니다. 하지만, 그보다 훨씬 간단한 일들을 하기 위해 그런 무거운 도구들을 이용하고 싶지는 않습니다. 이 것이 동적 언어가 가야 할 길이라고 생각합니다
Deno는 Node의 디자인 실수를 교정하기 위해 호환성을 과격하게 깨버립니다.
- 단 하나의 유일한 모듈 시스템으로 ES 모듈 사용
- 보안을 강화
- 브라우저 호환성 유지
변화
Third-party 코드를 링크 시키는데 Http URL을 사용 할 수 있습니다. 이 URL을 이용해 스스로 리소스를 다운로드 하고 패치하게 됩니다. Deno 스스로가 패키지 매니저인 셈입니다
사용자는 디스크나 네트워크, 또는 허락이 필요한 기타 작업에 접근 할 때 기본적으로 권한을 요구합니다.
- V8 JavaScript Runtime
- Rust (C++를 대체)
- Event Loop
- TypeScript
Deno는 node보다는 OS와 비슷하게 설계되었습니다. 기본적으로 사용자 코드를 신뢰하지 않고, 보통의 프로세스가 하는 것 처럼, Web Worker로 다른 프로세스를 구동 할 수 있습니다.
Deno의 디자인 철학은 ‘모든 것들은 Ops와 Typed Array로 주고 받는다’입니다. 이 것이 VM을 관리하는 좋은 방법이라고 생각합니다.
고급
Deno는 독립적으로 실행 가능하게 배포 되지만, 임베디드 시키는 것 역시 가능합니다. V8을 직접 이용하는 것은 너무 복잡합니다. 그래서 중간자적인 역할로 Deno가 다른 티어tier로 접근 할 수 있습니다. Rust crates로 publish되는 low-level API는 V8과 Typed Array를 주고 받는 방법으로 사용 됩니다. 이걸로 모든 것들을 해결 할 수 있습니다.
하지만 이 문제를 해결하는데 어려운 부분은, JavaScript의 promise와 Rust의 future를 매핑하는 것입니다. future는 JavaScript의 promise와 같은 기능으로, 이것들은 자동으로 매핑되지 않기 때문에 외부 함수 인터페이스FFI가 강력한데, 이는 다음과 같은 콜백 구현으로 해결 할 수 있습니다
