취미였던 점보기에 대하여
친척 중 무당이 계셨지만 20대 중반까지 사주팔자 같은 것에는 전혀 관심이 없었던 나. 그러나 어느순간 사주에 꽂혀 몇 년 공부를 하고 지금은 취미로 점사를 보는 중.
그러나, 누가 요즘 산통을 들고다닌단 말인가. 요새는 카니타로처럼 온라인 페이지에서 카드를 뽑을 수 있는 경우도 많으니.
기존에 이용하던 방식은 늘 난수발생기를 돌리고 괘의 해설을 찾는 불편이 있었다. 대단한 프로젝트가 아니어도 좋으니, 일단 나 자신을 위한 육효 사이트가 있다면 좋을 것 같았다.
타로 사주 사이트는 이미 많기도 하고 달력의 복잡함도 있고 하여, 최근 자주 이용하는 육효로 하기로 결정. 육효도 세응 잡고 동효 설정하고 하면 복잡하지만, 그런 육효 이론은 나도 모르니 정말 단순하고 간단하게 카테고리 별로 나눌 예정.
어떤 기술 스택으로 만들어볼까
일단 지금 할 줄 아는 것은 Node밖에 없으니 Node 서버로 만들자. 웹에는 이만한 것이 없다는 생각을 하며... 아 스프링 공부도 다시 해야 하는데. (?)
나는 Express.js만 써왔는데, 반드시 익스프레스를 써야할까? 다른 서버 프레임워크도 있을텐데, 내가 이 프로젝트에서 익스프레스를 써야하는 이유와 그렇지 않은 이유가 있다면 뭘까?
Koa.js, Hapi.js, Nest.js, LoopBack 등 여러 프레임워크가 있다. 보통 Express의 라이벌(?)로 인식되는 것은 Nest.js 인 것 같다. 참고 사이트들을 토대로 둘의 특징을 한번 정리해보자.
MDN 공식문서 - Express(Node.js)
위키독스 - Express가 좋을까 NestJS가 좋을까?
참고 블로그1 - Node.js 백엔드 프레임워크 종류와 특징
참고 블로그2
참고 블로그3
Express의 특징
- MDN 공식 추천 프레임워크
- 가볍게 테스트용 서버를 띄울 수 있다
- 단순하고 자유도 높음. 하지만 그때문에 라이브러리를 위해 발품 팔아야함
- 타입스크립트는 추가설정을 통해 사용가능
- 커뮤니티가 크다 (언어 생태계가 넓다)
NestJS의 특징
- 타입스크립트용 오픈소스 서버 프레임워크
- 미들웨어, IoC(제어의 역전), CQRS 등 많은 기능이 포함됨.
자바 스프링을 많이 차용하여 스타일이 비슷함- Express 기반으로 만들어져 req, res 등의 객체 사용 가능
- 타입스크립트를 상정하고 만든 것이라 TS 기본 지원
- 다만 핵심 개념에 TS 특화 내용들이 들어가기 때문에 TS 모르면 러닝커브 높음
파이썬에 비유하자면 Express는 Flask, Nest는 Django 라고 한다.
결정: Express
현재는 러닝커브에 많은 시간을 쏟을 여유가 없고,
단순하고 높은 자유도가 필요하며,
큰 생태계에서 빠르게 정보를 입수해야 하는 상황이기 때문
NestJS 조사 중 의문 - 타입스크립트는 왜 필요한걸까?
예전에 항해 노드 매니저님께서도 Node를 하려면 타입스크립트는 필수라고 하시며 책을 추천해 주셨다. 그런데 왜 필수인걸까?
예전 항해 동기분이 타입스크립트는 자바스크립트의 자유분방함이 문제가 되어 자바에서 타입을 차용하여 안전성을 도모한 언어라고 하셨었다.
우선 버그 예방의 목적이 가장 크다고 한다. 자바스크립트처럼 무타입 언어는 런타임 시에 자료형이 결정되기 때문에 모르는 새에 형변환이 되어있는 경우가 꽤 된다. 타입스크립트는 컴파일 단계를 거치기 때문에 에러가 있으면 미리 알 수 있는 것이 장점.
Express를 쓰기로 결정했으면 초기 설정을 해보자
- npm install -g yarn
- yarn init (다 쓰기 귀찮으면 -y/--yes)
- yarn add express
- package.json에 "type" : "module" 추가
- 아래 코드를 자신의 실행파일(나는 app.js) 에 작성
- 작성 다 했으면 터미널에 node app.js 입력
- 3000번 포트가 이미 열려있다면 taskkill /f /im node.exe 입력
(Mac은 killall node)
import express from 'express';
const app = express();
const PORT = 3000;
app.get('/', (req, res) => {
res.send('Hello World!');
});
app.listen(PORT, () => {
console.log(PORT, 'port is listening...');
});
- 강사님처럼 이모지가 표시되게 하고 싶은데 맥이 아니라 안되나?
-> 아니다. yarn (아무 명령어. init, add, 생략 등) --emoji 라고 하면 된다.
ES6 문법의 ES는 엘라스틱 서치가 아니다 - ECMA Script Module
항해때 스프링을 하면서 내배캠을 하기 전까지 ES5 ES6가 엘라스틱 서치에 버전이 붙은 줄 알았다. ESM(ECMA Script Module)에 버전이 붙은 것.
ESM은 최신 Javascript에서 지원하는 모듈 시스템. 모든 Javascript 환경에서 통합적인 인터페이스를 제공하기 위해 시작된 체계라고 한다.
CommonJS와는 다르게 정적으로 모듈을 가져오며 비동기적 모듈 로딩과 순환 종속을 처리한다고 한다.
정적 모듈 로딩, 동적 모듈 로딩, 순환 종속에 대해 공부해볼 것
ES6와 CJS의 차이 중 하나는 require문은 아무데나 붙을 수 있지만 import문은 맨 위에 위치해야 한다는 점이다.
Express에서 Router의 일반적인 구조
라우터의 기본 골자는 다음과 같다.
router.METHOD(PATH, HANDLER);
이게 대체 뭔 소리냐? 하면 예시로 보자.
router.get('/', console.log('Hello Express!'));
METHOD에는 get, post, put, delete, update 등...
PATH는 출력할 JS파일의 상대경로.
HANDLER는 라우트가 일치할 때 실행되는 함수.
만든 라우터를 엔드포인트에서 사용하려면 app.use()를 쓰자.
나의 경우는 일단 home.router.js를 만들고 homeRouter 라는 이름으로 import 해와서 다음과 같이 썼다.
const app = express();
app.use('/api', [homeRouter]);
하다보니 생긴 고민 - 프론트는 뭘로 만들어야 할까? React vs Vue
수료했던 교육기관에서는 프론트엔드에게 리액트를 가르쳤지만, 이 참고 블로그의 내용을 읽어봤을 때는 리액트는 Redux를 별도로 필요로 하고, 상탯값 변경 등에 대한 유연성이 상당히 떨어진다는 평이 있다. 애초에 리액트는 프레임워크가 아니라 라이브러리라고. 다만 모든 것이 자바스크립트 문법이기 때문에 별도로 문법을 배울 필요가 없다는 것이 장점.
Vue는 구조가 HTML과 아주 유사하지만 전용 문법을 어느정도 익혀야 한다는 주의점이 있다. 뷰도 프레임워크와 라이브러리 그 사이 어딘가에 있는 것 같지만 일단은 프레임워크로 분류된다.
지금의 나에게는 러닝커브나 추가 리소스 투입이 가능한 적은 프레임워크가 필요하다. 가능한 바닐라 HTML과 형태가 비슷하면 좋겠지만, 아니어도 내가 손볼 수만 있으면 된다는 주의. 프론트 프레임워크는 둘 다 나름대로 매력적인 것 같아 조금 고민.
내가 React보다 Vue를 좋아하는 이유 라는 블로그 글을 보면, 리액트가 가장 어렵기 때문에 취업을 위해서라면 리액트를 추천한다고 한다. 내가 추구하는 목적과는 부합하지 않아 Vue로 결정. MDN 공식문서에서 소개되었다는 것 또한 고려 요소.
