node.ts로 애플리케이션 만들기

과학상자로 자동차를 만들면 안되는거시야

꽤나 잘 굴러가긴 하겠지만 말이야…

enum

아예 없으면 없나보다 할텐데 어설프게 있는게 더 극혐이다.

export enum ArticleEnum {
  ADOC, MD,
}

export class ArticleConstant {
  static readonly ADOC = 'ADOC'
  static readonly MD = 'MD'
}

export type ArticleType = 'ADOC' | 'MD'

export default ArticleType

괜찮은 구조인지는 모르겠지만 대략 이렇게 처리를 해 버렸다.
단순히 enum을 이용해서 ===비교를 하면
class 안의 article: ArticleEnum은 ADOC ArticleEnum.ADOC는 0이라는 값이 나온다
0나오는건 당연한거긴한데
비교하면 0이랑 비교하는것처럼 다 false가 나온다.

취소. 이상하다.. 비교가 잘 된다.
전에 이런종류의 에러를 본 것 같은데
error TS2365: Operator ‘===’ cannot be applied to types 

메모리 공유

브라우저단에서 클라이언트 프로그램을 만들 때는 큰 문제가 되지 않던 부분인 쓰레드 관련 부분도 …
노드를 빠르게 해 주는 장점이기도 하지만 단점이기도 한 이 부분…
메모리를 공유해야 할 일이 있을 때 IPC또는 클러스터링 수준의 아키텍처를 만들어내야한다.

노드의 빠른 속도의 근본 이유이기도 하다.
그래서 간단한 형태로 많은 리퀘스트를 받는 애플리케이션을 만들때는 유용할 것 같다.

익셉션 처리

좀만 잘못하면 자꾸 뒈져버리니…
언어의 문제라기보다는 적절한 프레임웤이 없는게 문제라고 해야할 것 같다.

표준형태 없는 코드의 문제

이건 타입스크립트의 문제이긴 하지만

import winston from 'winston'
import * as winston from 'winston'

이 두개가 뭐가 다를까…
namespace가 선언되어 있는 경우
class가 선언되어 있는 경우
default export가 선언되어 있는 경우에 따라 임포트 방식이 달라져야한다.

소스코드를 봐야된다. ide를 좋은거 써야겠지…도큐먼트는 제대로 안나온게 많으니까
표준없는 코드는 여기저기서 문제를 일으킨다. 프로젝트가 커질수록 문제도 커지겠고…

장난감으로는 장난감만 만들자

노드 백엔드는 토이프로젝트까지만 사용하는걸로

프로토타이핑으로는 괜찮은 것 같다.

처음 배우기가 쉽다고 하지만 스프링에서 쓰던만큼 셋팅을 하려고 하니까 이것도 시간이 만만찮게 걸리는건 별 수 없는 것 같다.

잘 갖춰진걸로 쉽게 만들려면 RoR이 좋겠고
노드는 진짜 개판으로 짜기만 좋다. 이것저것 갖추려면 시간은 어차피 그만큼 걸린다.