분류 Nodejs

Node.js 12 : 서버 측 JavaScript의 미래

컨텐츠 정보

  • 조회 333 (작성일 )

본문

Node.js는 2009년 첫 출시 이후 게임을 변화 시키는 기술이었습니다. 

요컨대, 개발자는 자바 스크립트를 사용하여 페이지가 사용자의 웹 브라우저로 전송되기 전에 서버 측에서 스크립트를 실행하여 동적 웹컨텐츠를 생성 할 수 있습니다. 따라서 Node.js는 "JavaScript everywhere"패러다임을 나타내며 서버측 및 클라이언트측 스크립트에 대해 서로 다른 언어가 필요하지 않고 단일 프로그래밍 언어를 중심으로 웹 응용 프로그램 개발을 통합합니다.


https://blog.logrocket.com/node-js-12/ 


JavaScript와 Node.js에 대한 팬이라면, 나도 그렇듯이 훨씬 더 나아질 것임을 알게 될 것입니다.


새롭고 향상된 노드 12 


JavaScript가 더 좋아질 이유는 무엇입니까? Node.js 12는 몇 달 전에 발표되었습니다.


2019 년 4 월 23 일에 Node.js 12가 공식적으로 출시되었고 모든 곳에서 자바스크립트 매니아가 기뻐했습니다. 그리고 이것은 분명히 정식 이전 버전 업데이트가 아니라 주요 업그레이드로 크게 개선 된 것입니다. 하이라이트 목록을 살펴 보겠습니다.


V8 JavaScript 엔진 업그레이드 


JavaScript V8 엔진의 모든 새 버전에서 제공되는 예상되는 성능 조정 및 개선 외에도 이번에는 정말 주목할 만한 업그레이드가 있습니다. 여기에는 다음이 포함됩니다.

  • 제로 비용 비동기 스택 추적 – V8 엔진에 런타임을 추가하지 않고도 비동기식 호출 프레임으로 error.stack 속성을 보강하는 역할을 합니다.
  • 인수가 일치하지 않는 호출이 빠릅니다.- 과거에는 V8이 동일한 방식으로 너무 많거나 적은 매개 변수로 모든 함수 호출을 처리해야 했습니다. 이는 성능 비용으로 발생했습니다. 이제는 이 단계를 건너 뛸 수 있는 시기를 알기에 충분하여 통화 오버 헤드를 최대 60%까지 줄일 수 있습니다.
  • 더 빨라진 비동기 함수와 약속 - 사실, 비동기 사용은 약속보다 익숙하지 않은 개발자에게 async / await를 제공하는 동기식 스타일 구문 이외의 이유가 필요한 경우 실제로 약속보다 현재 2 개의 추가 마이크로틱이 빠릅니다.
  • 더 빠른 JavaScript 구문 분석 – 웹 페이지 시작시 V8 시간의 10 % 미만이 JS 구문 분석에 사용됩니다. 최신 JavaScript 파서가 데스크탑에서 파싱 속도를 최대 30% 향상 시켰습니다.

TLS 1.3을 사용한 보안 강화 


전송 계층 보안을 나타내는 TLS는 노드가 암호화 된 스트림 통신을 처리하는 방법입니다.


Node.js 12가 출시되면서 TLS는 1.3 버전으로 업그레이드 됩니다.이 버전은 중요하지 않지만 실제로는 성능 및 보안 기능이 많이 개선 된 주요 업데이트입니다. 처음에는 반 직관적으로 들리지만 TLS 1.3은 실제로 TLS 1.2보다 구현하기가 더 간단한 프로토콜이므로 응용 프로그램 간의 세션을 보다 안전하고 구성하기가 쉽고 빠르게 협상 할 수 있습니다.


TLS 1.3을 사용하면 노드 응용 프로그램이 최종 사용자의 개인 정보를 보호하면서 HTTPS 핸드 셰이크에 필요한 시간을 줄임으로써 요청 성능을 향상 시킬 수 있습니다.


결론 : 통신을 사용하는 모든 사람들이 보안을 강화하고 통신하는 동안 대기 시간을 줄입니다. 그것은 저에게 큰 승리입니다.


올바르게 구성된 기본 힙 제한 


자, 더 낮은 수준의 개선에 대해 이야기 해 봅시다. 지금까지 수동으로 다르게 구성하지 않는 한 JavaScript 힙 크기는 브라우저에서 사용하기 위해 V8에서 설정 한 최대 힙 크기로 기본 설정되었습니다. 

Node.js 12 릴리스에서는 JS 힙 크기가 사용 가능한 메모리를 기반으로 구성되어 노드가 사용 가능한 것보다 많은 메모리를 사용하지 않고 메모리가 소진 될 때 프로세스를 종료하지 않습니다.


방대한 양의 데이터를 처리 할 때 - 적어도 시간의 일부 - 메모리 오류가 발생하지 않도록 하십시오. 필요한 경우 이전 --max-old-space-size 플래그를 사용하여 다른 제한을 설정할 수 있지만 이 기능을 사용하면 플래그를 설정할 필요가 줄어 듭니다.


기본 http 파서는 llhttp가됩니다. 


많은 사람들에게 알려지지 않았지만, Node에서 사용되는 현재의 http_parser 라이브러리는 유지 보수와 개선이 극도로 어려워서 llhttp가 탄생했습니다. 이 프로젝트는 TypeScript에 대한 http_parser 포트이며 llparse를 통해 실행되어 C 또는 비트 코드 출력을 생성합니다.


llhttp는 http_parser보다 156 % 더 빠르며 적은 코드 행으로 작성되었으며 모든 성능 최적화는 http_parser의 손으로 최적화 된 코드와 달리 자동으로 생성됩니다.


Node.js 12에서는 처음으로 기본 파서를 llhttp로 전환하고 더 철저히 테스트하기로 결정했습니다. 다른 요구 사항이 많은 여러 응용 프로그램을 시도 할 때 성능이 계속 좋기를 바랍니다.


수요에 대한 진단 보고서 


대화를 디버깅으로 전환하면서 Node.js 12에는 새로운 실험 기능이 있어 사용자가 요청시 또는 특정 트리거 이벤트가 발생할 때 보고서를 생성 할 수 있습니다.


이러한 종류의 실시간 보고는 충돌, 성능 저하, 메모리 누수, 높은 CPU 사용량, 예기치 않은 오류 등 프로덕션에서 발생하는 문제를 진단하는 데 도움이 됩니다. 일반적으로 디버그, 진단 및 수정에 며칠이 걸리지 않으면 몇 시간이 걸리는 작업입니다.


통합 힙 덤프 


이 릴리스에서 힙을 둘러싼 또 다른 기능은 디버깅 프로세스의 속도를 높여주는 Node.js 12와 함께 제공되는 통합 힙 덤프입니다. 

이제 메모리 문제를 조사하기 위해 새 모듈을 설치할 필요가 없습니다. 


명령 줄 또는 API 호출을 통해 원하는 JSON 형식의 진단 요약을 Node에 알리고 처리 할 수 있는 모든 정보를 구문 분석하십시오.


Node.js에서 네이티브 모듈을 쉽게 얻을 수 있습니다. 


낮은 수준의 개선을 거듭해 노드 에코 시스템의 개발자와 모듈 제작자에게도 멋진 것들이 있습니다.


Native API의 버전 4 릴리스뿐만 아니라 작업자 스레드와 함께 네이티브 모듈을 더 잘 지원하는 변경 사항을 포함하여 노드의 네이티브 모듈 만들기 및 빌드가 계속해서 향상되어 고유 네이티브용 스레드를 쉽게 구성 할 수 있습니다. 비동기 함수.


요약하면 이는 노드 별 모듈의 제작자 및 관리자가 순수한 JavaScript 모듈 제작자만큼 이러한 모듈을 유지 관리하는 데 거의 시간이 걸리지 않음을 의미합니다. 

개발자가 모듈을 지원하기를 원하는 각 Node.js 버전의 배포 된 바이너리를 다시 작성해야 하는 관리자가 증가하여 복잡성이 높아짐에 따라 이제는 N-API의 도움으로 크게 추상화 되었습니다.


작업자 스레드가 나오고 실험용 플래그가 제거되었습니다. 


워커 쓰레드는 노드 10부터 주변에 있었지만 더 이상 플래그를 사용할 필요가 없으며 실험 단계를 벗어나는 데 유리합니다. Node.js 11.7.0 이전에는 명령 행에서 --experimental-worker 플래그로 노드를 시작하지 않으면 작업자 스레드 모듈에 액세스 할 수 없었습니다.


$ node -e "require('worker_threads'); console.log('success');"
internal/modules/cjs/loader.js:605
    throw err;
    ^
Error: Cannot find module 'worker_threads'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:603:15)
    at Function.Module._load (internal/modules/cjs/loader.js:529:25)
    at Module.require (internal/modules/cjs/loader.js:657:17)
    at require (internal/modules/cjs/helpers.js:22:18)
    at [eval]:1:1
    at Script.runInThisContext (vm.js:123:20)
    at Object.runInThisContext (vm.js:312:38)
    at Object. ([eval]-wrapper:6:22)
    at Module._compile (internal/modules/cjs/loader.js:721:30)
    at evalScript (internal/bootstrap/node.js:720:27)
$
$ node --experimental-worker -e "require('worker_threads'); console.log('success');"
success
$

CPU 집약적 인 JavaScript 작업을 수행 할 때 작업자가 정말 빛을 발할 수 있으므로 I / O 집약적 인 작업에 많은 도움이 되지 않습니다. 노드의 기본 제공 비동기 I / O 작업은 작업자보다 효율적입니다.


시작 시간 개선 


Node.js 11은 기본 제공 코드 캐시 지원을 사용하여 작업자 스레드의 시작 시간을 거의 60 % 단축했습니다.


노드 12는 빌드 타임에 미리 내장 라이브러리 용 코드 캐시를 생성하여 기본 스레드가 코드 캐시를 사용하여 JavaScript로 작성된 내장 라이브러리의 초기 로드를 시작할 수 있도록 하는 아이디어를 기반으로 합니다.


결과적으로 메인 스레드의 시작 시간이 30 % 더 빨라지고 사용자에게 앱이 이전보다 빠르게 로드 됩니다.


ES6 모듈 지원, 거의 다 왔어. 


나는 마지막을 위해 최선을 구했다. 나에게 가장 흥미로운 기능 중 하나는 ES6 모듈 지원입니다. 우리 중 많은 사람들이 기다리고 있습니다. 이 기능은 아직 실험 중이며 노드 팀은 이를 시도하는 사람들의 피드백을 찾고 있지만 전 세계에서 신경 쓰지 않고 프론트 엔드에서 백엔드 JavaScript로 완벽하게 전환 할 수 있다고 상상해보십시오.


--experimental-modules의 최신 버전에는 다음과 같은 것이 있습니다.

  • 상대 URL ./examples.js, 절대 URL file : ///opt.app/examples.js, 패키지 이름 example-package 또는 패키지 내의 경로 example-package / lib / examples.js가있는 JavaScript 파일을 참조하는 ES2015 가져 오기 명령문은 다음과 같습니다. 모두 지원됩니다.
// relative urls
‘./examples.js
 
// absolute URLs
file:///opt.app/examples.js’
 
// package names
example-package
 
// paths within packages
example-package/lib/examples.js
  • js 파일에서 가져 오기 및 내보내기 구문이 작동합니다. 마지막으로 개발자는 './examples'에서 기본 내보내기 가져 오기 테스트, './examples'에서 내보내기 import {example1, example2} 및 네임 스페이스 내보내기 import *를 지정한 것처럼 './examples'의 샘플로 가져 오기 테스트를 지정할 수 있습니다. ES6이 나온 이후의 전통적인 자바 스크립트.


// default imports / exports
import test from ‘./examples
 
// named imports / exports
import {example1, example2} from ‘./examples
 
// namespace exports
 import * as samples from ‘./examples
  • "type": "module"을 프로젝트의 package.json에 추가하면 Node.js는 프로젝트의 모든 .js 파일을 ES 모듈로 처리합니다. 이 접근 방식을 사용하면 Node가 패키지 수준의 메타 데이터 및 구성에 package.json을 사용할 수 있습니다.이 메타 데이터 및 구성은 Babel 및 기타 번들 및 구성 도구에서 이미 사용 된 것과 유사합니다.
  • 파일에 대한 명시 적 확장자는 .mjs로 끝나는 모듈로 처리되고 .cjs로 CommonJS로 처리됩니다. 이들은 여전히 require와 module.exports-type 구문을 사용하는 파일입니다.

노드 12에 대한 새로운 컴파일러 및 플랫폼 최소 표준 


마지막으로 노드 자체를 실행하기 위한 새로운 요구 사항이 있습니다.


내부 개선 및 V8 엔진의 C ++ 로의 업그레이드를 통해 Node.js에 새로운 기능이 추가되면서 Node.js 12에 대한 새로운 최소 요구 사항이 제공됩니다. 이제 코드베이스에는 macOS 및 Windows 이외의 플랫폼에서 최소 GCC 6 및 glibc 2.17이 필요합니다. . 바이너리는 이 새로운 툴 체인을 최소한으로 사용하고 새로운 컴파일 타임 성능 및 보안 기능을 향상 시킵니다.


Mac 또는 Windows 컴퓨터를 사용하는 경우 괜찮습니다. Windows 최소값은 Node.js 11을 실행하는 것과 동일하며, Mac 사용자는 Xcode 8 이상, MacOS는 10.10 "Yosemite"가 필요합니다. nodejs.org의 Linux 호환 바이너리는 Enterprise Linux 7, Debian 8 및 Ubuntu 14.04를 지원하지만 기본적으로 GCC 6을 지원하지 않는 시스템의 사용자 지정 도구 체인이 필요할 수 있습니다. 빨리 필요한 것이 무엇인지 알아낼 것입니다.


결론


Node.js는 10년 밖에 되지 않았습니다. 예, 단일 스레드이고, 그렇습니다. 다른 프로그래밍 언어만큼 널리 채택되고 활용되지는 않지만, Node는 다른 프로그래밍 언어가 주장 할 수 없는 것을 자랑합니다. 자바 스크립트로 작성되었습니다. 클라이언트 및 서버 측에서 모두 실행할 수 있습니다.


그리고 Node를 지원하고 개선하기 위해 노력하는 팀과 회사는 비즈니스에서 가장 훌륭하고 밝습니다. Node는 핵심 JavaScript 및 기타 언어로부터 계속 배울 수 있으며 체리 - 올바른 조각을 선택하여 통합하여 개발자와 응용 프로그램을 위한 더 나은 플랫폼이되었습니다.


Node.js 12는 ES6 모듈 지원, 향상된 응용 프로그램 보안 및 빠른 시작 시간과 같은 몇 가지 매우 흥미로운 향상을 가져옵니다. 2019 년 10 월까지 LTS (장기 지원) 모드로 전환되지는 않지만 이 새로운 기능에 대해 연구하고 팀이 이 플랫폼을 훌륭한 서버 측 솔루션으로 계속 만들기 위해 무엇을 꿈꿀 수 있는지 알아볼 수 있습니다.