Deno

생소한 Deno에 대한 기본적인 개념을 정리 하고자 한다.
사용법은 어렵지 않으므로 document를 읽어본다.

deno 출현 배경

• 라이언 달(Ryan Dahl)은 JSConf.EU 행사 첫날의 저녁 세션에서 "Things | Regret About Node.js"라는 제목으로 nodejs 설계실수를 발표하며 deno를 소개함.
• Node.js 사용자는 너무나 많기 때문에 Node.js의 잘못된 것들을 당장 바로잡는 것이 어렵게됨.
• TypeScript와 같은 파생 프로젝트도 생겨나면서 빌드 시스템과 프로젝트 자체를 관리하는 툴만으로도 굉장히 복잡해졌음.
  
• 외부 라이브러리가 꼭 npm 저장소를 통해야만 한다는 것은 웹의 이상적인 방향과도 맞지 않음.

NodeJS 설계 실수

1. Promises를 고집하지 않은 것(Not sticking with Promises)

Node.js의 비동기 호출은 여전히 콜백 API를 기준으로 되어 있다.
Promises는 Async, Await을 제공하기 위해서 필수이다.
라이언 달은 2009년에 Promises를 추가했다가 2010년에 삭제한 것을 언급하면서 자신이 Promises를 계속 고집했다면 커뮤니티 소스가 더 빨리 Async Await으로 진보했을 것이라며 후회하였다.

2. 보안 문제에 더 신경 쓰지 못한 것(Security)

V8에 대해서는 그 자체로 훌륭한 샌드박스 모델을 가지고 있다는 것을 언급하였지만
Node 응용 프로그램이 어떻게 유지ᆞ발전될지를 고려했다면 다른 언어들이 갖지 못한 보안성을 갖출 수 있었을 거라는 후회를 남겼다.

3. 빌드시스템(GYP) 1

크롬 브라우저가 GYP라는 메타 빌드 시스템을 사용하다가 GN으로 업그레이드한 반면, Node.js는 GN으로 변경하지 않아 이를 후회했다. (구글의 GN이 GYP보다 20배 정도 빠르게 빌드 된다고한다.)(GYP_메타 빌드 시스템은 여러 플랫폼(윈도우즈, Mac, Linux)에서 소스코드를 빌드하기 위해 사용되는 빌드 시스템이다.)

4. 빌드시스템(GYP) 2

GYP를 이용해 빌드 시스템을 만들면서 네이티브 콜을 하기 위해서 사용자가 필수적으로 C++ 바인딩을 하도록 했는데, FFI(Foreign Function Interface)를 제공했어야 했다는 아쉬움을 토로함.

5. 패키지 매니저 파일(package.json) 1

노드는 npm이라는 패키지 매니저가 관리하는 package.json 파일이 main() 함수에서 찾도록 되어있어 npm에 의존적인 커뮤니티로 만들었다는 점을 스스로 비판하였다.
facebook에서 만든 yarn이라는 패키지 매니저가 npm을 대체하고 있지만 package.json은 그대로 사용하고 있다.

6. 패키지 매니저 파일(package.json) 2

package.json 파일의 모듈 시스템이 파일 디렉터리를 기준으로 잡히도록 만들어서 라이선스, 리포지터리, 설명 등 모듈 시스템 자체만으로는 필요 없는 정보까지 다 포함시켜 너무 무거워졌다고 한다.

7. 모듈 시스템(node_modules)

모듈을 가져오는 알고리즘이 복잡해졌고, 브라우저에서 가져오는 방법과도 맞지 않아 굉장히 어려워짐. 그럼에도 불구하고 돌이킬 수 없다는 사실에 커뮤니티에 미안함을 전함.

8. Require 문법을 쓸 때 js 확장자를 안 써도 되게 한 것

9. index.js

브라우저가 index.html을 default로 갖기 때문에 index.js를 지정한 것이 당시엔 괜찮은 생각 같았으나, 결과적으로 모듈 로딩 시스템을 더 복잡하게 만들었다고 한다.

---

Deno

Deno는 보안이 기본적으로 내장되었으며 훌륭한 개발자 경험을 갖춘 타입스크립트(자바스크립트) 런타임이다.

주요 특징

• 보안이 기본 설정이며 명시적으로 허락이 되지 않는한 파일, 네트워크, OS환경에 접근 할 수 없다.
• Typescript를 기본적으로 지원한다.
• 단일 실행 파일을 제공한다.
• 의존성 검사(deno info), code formatter (deno fmt)와 같은 내장 유틸리티 도구를 제공한다.
• deno와 함계 동작하도록 검수 및 설계된 표준 모듈이 제공된다.
• 스크립트 파일은 하나의 js파일로 번들링 되는 기능을 제공한다. (deno bundle)

NodeJS와의 차이점

• deno는 npm을 사용하지 않으며 URL또는 파일 경로를 통해 모듈을 로드한다.
• deno는 모듈 결정 알고리즘에 package.json을 사용하지 않는다.
• deno의 모든 비동기적 작업은 promise를 반환하한다. 그러므로 NodeJS와는 다른 API를 제공한다.
• deno는 파일, 네트워크, OS환경 접근에 대해 명시적인 권한을 요구한다.
• deno는 핸들링하지 않은 에러 발생시 앱을 종료시킨다.

• ES Modules를 사용하며 require() 구문은 사용하지 않는다. 외부 라이브러리의 경우 URL을 통해 import한다.

import * as log from "https://deno.land/std/log/mod.ts";

설치 및 실행 (mac기준)

curl -fsSL https://deno.land/x/install/install.sh | sh
 
 
or
 
 
brew install deno

간단한 HelloWorld 서버 실행

import { serve } from "https://deno.land/std@0.57.0/http/server.ts";
const s = serve({ port: 8000 });
console.log("http://localhost:8000/");
for await (const req of s) {
  req.respond({ body: "Hello World\n" });
}

-- 명시적으로 네트워크 권한을 부여해야 실행된다. deno run --allow-net app.ts

---

나의 생각

장점으로는 위에도 나열되어 있지만 다른 셋팅없이 typescript를 바로 실행 할 수 있다는점,

package.json, node_modules가 사라져 깔끔한 소스 코드 구조를 가져 갈수 있다는 점,

test도구 및 개발시 유용한 유틸리티들이 기본적으로 내장되어있어 개발하기 편했다는 점을 들수있다.

 

단점으로는 1.0버전이 나온지 얼마 되지않아 관련 커뮤니티를 찾기 힘드며 방대한 npm의 3th party 라이브러리들을 지원하지 않는다는 점이다.

간단한 어플정도는 충분히 만들수 있는 라이브러리들이 제공되긴하나 상용에 사용하기 위한 앱을 개발하려고 deno를 사용한다면 충분히 고려후에 판단해야 할것같다.

 

개인적인 개발 용도로의 deno는 충분하다고 생각되며 typescript로 보다 빠른 개발이 가능하여 개인적으로 상당히 만족스러웠다.

---

출처

• https://deno.land/
• https://han41858.tistory.com/50
• https://www.samsungsds.com/global/ko/support/insights/github-June-Trend.html