[WebDevCurriculum] node.js

Hyo Kyun Lee·2021년 11월 3일

목록 보기

16/44

개요

node.js에 대해 이해한다.

Checklist

node.js는 무엇인가요?
→ javascript 언어로 동작하는(javascript 엔진 기반의) 웹어플리케이션 프레임워크이다.
→ non-blocking I/O 및 단일 스레드 동작을 통해 효율적인 네트워킹을 가능하게 하며, 이에 따라 기존 client 기반의 javascript 특징을 server 영역까지 확장할 수 있게 되었다.
node.js의 내부는 어떻게 구성되어 있을까요?
→ node.js의 가장 강력한 기능이자 특징은 single thread, asynchronized pattern이다.
→ 전통적인 web 프레임워크에 비해 훨씬 간단하고 효율적인 방식으로, 다수의 request 처리가 가능하고 빠른 응답을 구현할 수 있게 되었다.
npm이 무엇인가요?
→ node package module, 노드패키지의 관리에 중점을 둔 명령어이다.
→ npm을 사용하는 목적은 기본적으로 특정 기능 수행을 위해 라이브러리를 저장하고 관리하는 것에 있다.
→ 이 라이브러리를 npm을 통해 설치할 경우 전역설치를 하거나, 지역설치(특정 프로젝트에서만 적용)를 할 수 있다.
→ npm으로 설치한 라이브러리는 쉽게 말하면 영구적으로 저장되기 때문에, 패키지가 업데이트되면 관리자가 각 패키지들의 버전을 확인하고 업데이트를 적용해주어야 한다.
npx는 어떤 명령인가요?
→ node pacakage execution, 노드패키지의 실행에 중점을 둔 명령어이다.
→ npm의 영구적인 설치, 관리 등의 부가적인 절차없이 원하는 패키지를 npm 레지스트리에 접근시켜 실행만 할 수 있도록 설치하는 일종의 실행도구이다.
→ 말그대로 실행목적의 실행도구이기 때문에, 빠른 실행결과를 보고자 할때 별도의 패키지 업데이트나 관리할 필요없이 손쉬운 실행이 가능하다.
npm 패키지를 -g 옵션을 통해 글로벌로 저장하는 것과 그렇지 않은 것은 어떻게 다른가요?

npm install -g <package>
→ node package를 전역적으로 설치하여, 말 그대로 PC내부에서의 프로젝트 전역적으로 참조할 수 있는 package가 설치된다.
→ window의 경우 전역 node_modules directory에 설치된다.

npm install <package>
→ 설치 옵션을 별도로 지정하지 않을 경우엔 package가 지역적으로 설치되며, 해당 프로젝트 내부에서만 사용할 수 있다.
→ 프로젝트 내부 디렉토리(지역적) node_modules에 설치되며, 실행파일 역시 지역적 디렉토리에 설치된다.

CommonJS
→ 전통적인 웹 프레임워크의 범주에서 벗어나, javascript를 기반으로 모듈 시스템을 표준화하기 위한 프로젝트이다.
(※쉽게 말하면 ES도입이전, broswer보다 모듈화를 빨리 진행하기 위한 노력의 일종)
→ node.js의 표준이기도 한 commonjs(모듈화) 방식은, 점차 규모가 커지는 application 구성에서 script 파일이 방대해져 이를 분할하고 관리하기 위해 고안되었다.
→ 보통 require을 통해 다른 파일을 불러오고, module.exports.component 을 통해 파일을 export하는 방식이다.
→ 동기적인 환경에서 모듈을 읽어오는데, 보통 디스크 등에서 읽어와 passive I/O interface 및 side effect를 동반하면서 script를 실행한다.
ES6 module
→ 최근 script 언어의 표준화를 위해 javascript를 기반으로 진행되는 ECMA Script에서, 해당 표준에 정의되어 있는 module화 방식을 의미한다(import/export 이용).
→ commonJS와 달리 모듈로더 자체가 비동기적인 환경에서 모듈을 읽기 때문에, import와 export 문을 파악하고 script를 parsing 한다.
→ import할 요소가 없을때까지 parsing한 후 최종적으로 실행하며, 이는 순차적으로 진행된다.
→ commonJS보다는 ES6가 최근에 구성된 개념이고 strict mode를 활용해야 하다보니, 두 모듈화 방식의 공존이 어렵고 혼용 시 번거로운 점이 매우 많다.
ES Modules와 commonJS의 차이점은 무엇이 있을까요?

commonJS
→ file system(disc)에서 file을 로드하고, 동기방식이므로 로드하는 동안은 주 스레드를 차단(block)한다.
→ 파일로드 - 파싱(구문분석) - 인스턴스화 - 평가(최종 response)가 각 시점마다 즉시 실행된다.
→ 모듈 지정자에 변수를 넣을 수 있고, export 객체 값을 복사할 수 있다.

ES Modules
→ 모듈로더가 모듈을 읽은 후, 의존적으로 형성된 import 구문을 모두 탐색 및 파싱하는 작업을 종료할 때까지 반복한다.
→ 비동기 처리 방식이기 때문에 파싱하는 동안 다른 스레드를 block하지 않으며, import할 구문이 더이상 없을 때 최종적으로 실행한다.

node.js에서 ES Modules를 사용하려면 어떻게 해야 할까요? ES Modules 기반의 코드에서 CommonJS 기반의 패키지를 불러오려면 어떻게 해야 할까요? 그 반대는 어떻게 될까요?

export 예시

변수, 함수 export

export const a = 1
export function fn(){}
export class Class{}

여러 변수, 함수, 객체 export

묶어서 내보내기
const a = 1
function fn(){}
class Class{}

export { a, fn, Class }
default export

export default

내보내고자 하는 변수, 함수 앞에 export default 붙이기

//export default에서의 export와 선언은 동시에 진행할 수 없다.
export default const a = 1 //실행불가

// fn.js
export default function fn(){}

// Class.js
export default class Class{}

default export는 모듈 당 하나만 가능하다.

선언 후 export
//a.js
const a = 1
export default a

// fn.js
function fn(){}
export default fn

// Class.js
class Class{}
export default Class

import 예시

위에서 export한 import module을 import할 경우

//named export를 import하는 경우
import {a} from 'a.js'
import {fn} from 'fn.js'
import {Class} from 'class.js'

//defualt export를 import하는 경우
import a from 'a.js'
import fn from 'fn.js'
import Class from 'class.js'

//default의 경우 export하는 영역에서 원하는 변수명으로 바꿔줄 수 있다.
import DD from 'class.js'

참조개념

node.js의 배경
→ WWW(World Wide Web)과 javascript의 launching 이후, javascript를 기반으로 한 백엔드 프레임워크 개발이 진행되었으나 그리 좋은 평가를 받지 못하였다.
→ 하지만 그 이후 Web2.0 개발, Chrome V8 engine가 진행되면서 javascript가 다시 각광받기 시작하였고, server-side에서의 강력한 특징들이 주목받았다.
→ 비동기처리, event-driven, light-weightedness, 속도, 확장성 등의 javascript 특징이 node.js에서도 적용되어 간편한 네트워크 처리가 가능하게 되었다.

traditional Web frameworks
→ 전통적인 네트워크 처리방식은 mutli-thread 방식으로, 제한된 thread pool을 통해 client가 server에 접근하여 request/response를 처리한다.
→ 프로세스 처리는 동기적, 순차적으로 이루어져 한 시점에서 반드시 하나의 operation(request)만을 수행할 수 있었다.
→ thread pool이 제한적이기 때문에 request 역시 제한적일 수 밖에 없었고, 네트워크 처리를 하는데 매우 비효율적이었다.
→ 또한 동기처리의 특성상 다른 operation에 대한 blocking이 진행되어 어플리케이션을 운영하는데 매우 큰 제한점으로 작용하였다.
Single Thread / event-driven
→ node.js에서의 네트워크(request/response) 처리는 오직 한 thread에서만 진행하는데, event loop를 통해 다른 operation을 blocking하지 않고도 작업처리가 가능하다.
→ event loop는 다수의 thread의 처리결과(response, return)를 전달받고 처리하면서, 그와 동시에 thread 처리도 같이 진행되어 전통적인 방식보다 훨씬 효율적이다.
→ 최종적으로 event loop가 처리한 결과는 client에 전달되어 보여진다.
node.js를 효율적으로 사용하기 위한 12가지 원칙

관심사 분리
→ 기능을 분리한다.
→ 처리영역을 Controller/Service/Data-access의 3가지로 세분화하여 구성한다.

folder structure
→ 구획에 따라 folder path를 분할하고, 적절히 organization 한다.
→ 코드관리가 용이하도록 structure를 구성한다.

Publisher/Subscriber model의 원리
→ Subscriber은 여러 경로를 통해 message, request를 전달할 수 있고, Publisher은 특정(하나의) 경로를 통해서만 전달할 수 있다.
→ 즉 이벤트는 되도록이면 하나의 경로, 기능(function)을 통해서만 처리할 수 있도록 구성한다.

코드의 가독성
→ 코드를 읽기 쉽게, clean 하도록 작성한다.

비동기 처리의 사용
→ async/await 나 promise 등을 활용하여 비동기 처리를 진행한다.
→ 효율적인 네트워크 처리방식을 이해하고 이를 적용한다.

환경설정, 환경변수
→ 어플리케이션의 규모가 확장됨에 따라 특정환경변수나 환경설정이 필요한 경우가 생긴다.
→ .env파일이나 .config() 등 환경변수나 관련 method 등을 활용하여 application에 따라 적절하게 사용할 수 있어야 한다.

Error handling
→ javascript는 compling step이 아닌 runtime step에서 오류를 찾아내므로, 디버깅을 최소화하기 위해선 error handling이 필수적이다.
→ promise/then, catch/err 등을 통해 error처리를 반복적으로 확인하고 구현할 수 있도록 해야한다.

코드와 파일의 압축
→ Gzip 압축 파일을 이용하면 node.js에서의 response 전송 등을 빠르고 효율적으로 할 수 있다.
→ 프론트엔드에서 작업한 요소 역시 특정 프로그램을 통해 압축할 수 있고, 이후 백엔드에서 처리하는 과정은 불필요한 기능여백을 줄일 수 있다.

module의 활용
→ 한 script에서 모든 코드를 담으려 하는 것보다, module을 통해 기능을 철저히 분리하여 필요에 따라 특정 module을 활용하는 것을 권장한다.

적당한 npm, library의 활용
→ node.js가 가지는 여러 강력한 기능이나 library를 과하게 사용하지 않고, 적당한 범위 내에서 활용하는 것이 좋다.

연습하기
→ 좋은 코드를 작성하기 위해 지속적으로 연습한다.

application monitoring tools의 활용
→ application을 지속적으로 monitoring하는 tool을 활용한다.

pacakage.json 파일의 구성
→ version : install npm의 version
→ description : project 설명
→ keywords : project 부가설명, 핵심단어
→ homepage : prject 사이트에 대한 링크
→ bugs : project debugging / issue tracker
→ license : author information