개요
DCLab 팀에서 공동 개발 공부로 Deno 를 시작함.
Node.js 를 만든 라이언 달 은 Node.js 의 구조적 한계를 해결하기 위해서 Deno 를 만듦. Deno 는 Rust 를 주요 언어로 사용해서 만들어졌음.
탄생 배경
라이언 달은 Node.js 의 다음과 같은 문제점들을 지적했다.
보안이 취약한 플랫폼.
Node 가 안전하지 않은 플랫폼이며, 이를 잘 이해하지 못한 개발자가 불필요한 실행 권한을 부여하거나 안전하게 보호되지 않은 시스템 서비스에 접근하는 코드를 구현하면서 생기는 보안 구멍들이 존재하는 것을 깨달음.
모듈 시스템 문제
npm 의 중앙화되고 비공개적인 저장소 관리 방식 때문에 라이언 달은 npm 을 표준 패키지 관리자로 사용한 점을 후회함. 브라우저가 의존성을 임포트하는 방식이 더 깔끔하며 쉽게 유지보수할 수 있다고 생각했음.
그리고 가능하면 모듈을 저장하는 폴더(node_modules)를 없애고 싶었음. 폴더 크기때문에 불만을 토로하는 개발자가 많았음.
기타 사소한 문제
index.js 파일과 관련한 암묵적 동작도 문제. 개발자의 경험을 크게 개선하지 못했고, 결과적으로 모듈 로딩 시스템을 더 복잡하게 만듦. 그 외 확장자 문제 등 사소한 문제들이 있었음.
뭔가 버그를 만든 게 보이는 데 지금 당장은 그게 버그 같지 않게 동작하여 큰 문제처럼 보이지 않습니다. 하지만 버그는 버그인거죠. 그리고 설계상의 결함이 있는 걸 알면서도 지금은 그것을 고칠 수가 없습니다. 왜냐 이미 너무 많은 소프트웨어에서 사용하고 있기 때문입니다.
설치
그냥 공식 홈페이지 참고하자
완벽한 디노!
타입스크립트를 일급 시민으로!
주 언어로 타입스크립트 선택
기존에는 타입스크립트를 사용하려면 런타임이 이를 해석할 수 있도록 미리 타입스크립트 코드를 자바스크립트 코드로 바꾸는 빌드 설정(webpack, babel 등)을 해주어야 했다. 실제 실행이 되는 코드는 자바스크립트 였기 때문. 디노에서는 내부적으로 타입스크립트 컴파일러가 코드를 로드해 자바스크립트로 바꾼다. 이는 개발자가 빌드 과정의 변환을 신경 쓸 필요가 없어졌으며, 인터프리터 내에서 컴파일 시간을 최적화하므로 부트 시간이 단축됨.
Built-in dev tool
•
광범위 CLI 지원.
보안성
노드에서는 (보안상 어떤 리소스에 접근하는 것이 문제가 되고 안되고 상관 없이) 코드 실행을 제어할 수 없다. 즉 npm 에 올라온 모듈을 맹목적으로 신뢰할 수 밖에 없다. 하지만 npm 에 있는 모듈은 무조건적으로 신뢰할 수 없다. 그렇다고 수만행의 소스코드를 직접 검토하기란 불가능하다.
Node.js 런타임에서 코드를 실행하면 파일을 읽고 이를 http 로 다른 서버에 전송하는 코드를 실행하면 그대로 실행이 되지만, deno 에서는 실행 시 적절한 보안 flag (allow-read, allow-env 등)를 추가해야만 리소스에 접근이 가능해짐.
보안 플래그
•
--allow-all , -A
말 그대로 모든 보안 기능을 비활성화함. 하려는 일을 정확히 알고서 사용하는 것이 아니라면 사용하지 않는 것이 좋다.
•
--allow-env
환경 변수에 접근할 수 있는 권한. 서버의 환경변수에는 특히 중요한 데이터들이 많아서 주의해야한다. 화이트리스트로 어떤 리소스에만 접근 가능한지 설정 가능하다.
•
--allow-hrtime
정밀한 시간 측정이 가능하도록 함. 암호무력화할 때 정밀한 시간 측정 기능이 공격대상이 될 수 있기 때문에 추가(타이밍 어택 및 핑거프린팅). 이는 에러를 throw 하지는 않지만 소수점 단위의 ms 까지는 측정하지 못하도록 함.
•
--allow-net
HTTP 요청 등 외부와 통신이 가능하도록 함. 화이트리스트(네트워크 통신할 서버 주소)를 추가해서 사용하는 것이 권장된다. 화이트리스트를 추가하지 않고 사용하면 크게 의미가 없음.
•
--allow-read, --allow-write
디스크 입출력 허용. 마찬가지로 화이트리스트 지정이 가능하다.
•
--allow-plugin
공식 문서에는 존재하지 않음. 일단 제외
•
--allow-sys
OS 에 대한 정보를 제공하는 API에 접근 가능하도록.
•
--allow-ffi
동적 라이브러리 로드를 허용. 선택적 쉼표로 구분된 디렉터리 또는 파일 목록을 지정하여 로드할 수 있는 동적 라이브러리의 허용 목록을 제공 가능. 동적 라이브러리는 샌드박스에서 실행되지 않으므로 Deno 프로세스와 동일한 보안 제한이 없다. 그러므로 주의해야함
•
--allow-run
sub-process 를 실행할 수 있는 권한.
최상위 수준 await
프로젝트의 메인 파일에서 await 를 사용하는 것이 가능. ⇒ 더 깔끔한 코드 구현 가능.
표준 라이브러리 확장 및 개선
디노 팀은 라이브러리 출시 전 함수를 면밀하 검토하고 충분히 좋은 품질인지 검증 후 배포. 표준 라이브러리만드로도 필요한 도구를 갖추고 고품질 코드를 생산할 수 있는 장점.
Go의 영향을 많이 받아서 Go 에 있는 모듈이 꽤 있음. ex - fmt
npm 없는 세상
패키지 관리자가 사라짐. 그렇다고 디노가 자체적으로 패키지 관리자를 사용하는 것은 아님.
마치 모듈이 로컬에 설치되어 있는 것처럼 URL 로 코드를 임포트하는 기능을 지원. ⇒ 설치는 신경 쓸 필요 없음. 실행하면 Deno 가 설치는 알아서 함.
import {bgBlue} from 'https://deno.land/std/fmt/colors.ts'
JavaScript
복사
스크립트를 실행하면 내려받은 코드를 캐시화한다.(다시 실행하면 다운로드 없이 바로 실행) 뿐만 아니라 새 프로젝트에서도 공유된 캐시를 통해 같은 파일을 공유함. ⇒ 여러 node_modules 파일 때문에 괴로워하던 개발자를 구해줌.
•
—reload 플래그 사용하면 캐시가 아니라 새로 내려받음
•
환경 변수로 따로 지정하지 않는 한 DENO_DIR 폴더에 저장됨
•
deps.ts 라는 파일에 의존성 관리 가능
Deno-native Web Frameworks
•
◦
Javascript 를 최소화(혹은 아예 없이)해서 client 에 제공하는 모델
▪
Server Side Rendering, SEO 에 이점
▪
과도한 Javascript 로드, 실행하면서 생기는 성능 저하가 발생할 가능성 낮음
◦
major 한 컴포넌트들은 server 에서 render 하고, re-rendering 되는 요소들(interactivity 가 필요한 부분들)은 Islands Architecture 를 사용해서 랜더링함.
◦
Next.js 와 유사한 routing 제공 (편리함)
◦
Deno deploy 를 이용해서 편리하게 배포(CI / CD) 가능 (github 에 push 만 해도 배포됨)
•
◦
Next.js 와 유사하게 SSR, SSG 기능 제공 (SEO 편리)
◦
React, Vue, SolidJS 등과 같은 framework 과 사용 가능
◦
Next.js 와 유사한 routing 제공 (편리함)
◦
ES 모듈 구문을 사용하기 때문에 웹팩이나 다른 번들러가 필요하지 않다
◦
HMR
◦
Deno deploy 를 이용해서 편리하게 배포(CI / CD) 가능 (github 에 push 만 해도 배포됨)
◦
아직 Beta
◦
전체적으로 Next.js 를 따라가려는 듯한 행보를 보임.
•
그 외 사용해보고 싶은 Deno 사용처
•
•
