개인적으로 사용하던 빵판(https://github.com/deptno/next.js-typescript-starter-kit)을 공개도 한겸 겸사겸사해서 글을 쓴다.
이 글은 Next.js를 TypeScript를 다루는 글이 아니다. 조금의 소개만 있을 뿐이다.
단지 이런 선택을 선택지로 고려하고 있는 분에게 조금의 도움이 되고자 하는 글이며 이 선택을 한 분에게 조금 먼저간 사람이 이런 거라고 얘기하는 글이 될 것 같다.
목차
- prolog
- why Next.js? Static HTML!
- why TypeScript
- Next.js TypeScript Starter Kit
prolog
Next.js를 처음 사용했을때는 버전이 1.3x였던걸로 기억하는데 어느센가 버전이 5로 업데이트가 됐다. 5는 바벨이 버전업 되면서 드디어 TypeScript를 제대로 지원하게 되었다.
Next.js를 처음 썼을때 글을 썼더라면 더 많은 사람들에게 도움이 되었을까 싶지만 지금 TypeScript와 Next.js에 대해 니즈가 있다고 판단했다.
why Next.js? Static HTML!
Next.js는 SSR(Server Side Rendering) + React로 잘 알려진 Node기반의 프레임웍이다. SPA의 궁극은 Static HTML, 즉 asset 자체로의 서빙으로 마무리되어야 한다는 지론을 가지고 있으므로 SSR은 Static HTML의 과정으로 보고 있었고, 이 또 한 버전 2.x인가 부터 지원되기 시작했다. 회사에서는 두개의 웹사이트를 하나는 SSR을 위한 서버, 하나는 Static HTML로 구현했다.
Static HTML은 뚜렷한 장점이 있다. 5xx 에러는 서버엔지니어에게 논쟁없이 던질 수 있을 뿐 아니라 부하 측면에서도 상당히 유리하며 실제로 SPA의 완전체이자 인스턴스가 필요없어 AWS등 클라우드 서비스에서 지원하는 서비스와 CDN등을 이용하여 안정적이고 빠른 서비스가 가능하다. 인스턴스가 필요 없으므로 그에 따른 비용이나 서버 사망 이슈, 그리고 이를 위한 로드밸런싱등 여러면에서 관리 포인트를 줄여준다.
directory based routes
또 하나의 장점으로는 디렉토리 기반의 라우팅이다. 사실 올드한 방법이긴 하지만 SPA는 기본적으로 접속할 수 있는 엔드포인트가 하나기 때문에 다른 패스를 통해 들어오면 이를 index.html(일반적으로)으로 고정시키거나 #(해쉬뱅)등 무언가 많이 봐서 익숙하지만 핵같은 기술을 통해 코드레벨에서 라우팅을 하게 된다.
일단 이 보다는 디렉토리 구조를 보면서 코드를 짜면 직관적으로 페이지 위치를 인식하면서 코드를 짤 수 있다. 이 부분은 엔지니어에 따라 생각이 다를 수 있으므로 이 정도로 Next.js의 소개는 마무리 한다.
why TypeScript
TypeScript는 Angular(이전에는 2.0이라 불리던)가 Dart언어가 드랍되고 TypeScript로 흡수합병(?) 되면서 이슈화 되기 시작했는데 사실 나온지는 이미 좀 되었고 특정 니즈에 의해 1.0 이전 시절부터 계속 사용해 오고 있었다.
그래서 이전 직장을 그만두고 한동안 쉬다가(하필 쉬는 타이밍에 ES6으로 인한 천지 개벽이 이루어져서 바보가 되어있었다.) Angular와 React를 선택해야했는데 React의 JSX, 그리고 간결하고 직관적인 Life Cycle 메소드를 보고 React 를 선택했다.
개인적으로 Angular 이전 순수 JS로 SPA를 올리던 엔지어로써 Angular 1.x는 배우기 매우 어렵다고 생각했으며 특히 스코프 문법에서 혀를 내둘렀던 경험이 있다.
이 즈음해서 TypeScript와 Babel을 왔다 갔다해서 프로젝트마다 언어가 바뀌곤 했는데 문제는 React에서 필요로 하는 핵심 문법, 예를 들어 Object Spread(일명 …문법)이 지원되지 않는등의 이슈였는데 1.8을 버전으로 해소되었고 2.8이 나온 현재에서는 그냥 TypeScript를 선택하면된다.
TypeScript와 Flow
React를 만든 페이스북도 타입에 대한 니즈를 인지하고 우울한 propTypes를 만들었으며 이 우울함을 극복하기 위해 Flow를 만들었다.
Flow는 문법 자체도 TypeScript와 상당히 유사하며 컴파일이라기보다는 바벨 플러그인을 통해 Flow를 통해 타입을 검증하고 strip하는 형식이므로 사실 이미 TypeScript를 쓰고 있었다면 걍 못본척하고 지나가는 것이 여러모로 시간을 절약하는 길이다.
마침내 TypeScript
이런 제목을 달기에는 사실 꽤 늦은 타이밍이다. 지금은 이 조합이 너무 성숙했기 때문인데 지금 시작하려는 사람들에게는 삽질은 별로 필요없다는 뜻이다.
TypeScript는 기본적으로 Typing을 위한 언어고 Typing언어이기 때문에 얻을 수 있는 코드 어시스트등에서 도움을 받을 수 있게 된다.
이외에 이 글을 읽는 분이라면 이미 장점은 알고 계시리라 생각하고 생략하겠지만 이 말은 꼭 하고 싶다.
ES2015+ 문법을 사용하기 위해서 필요한 바벨 셋업 시간보다 TypeScript에 대한 셋업이 더 효율적이므로 이를 선택할 수도 있다는 점이다. 실제로 TypeScript를 실제 프로젝트에 도입함에 있어 인터넷에 떠도는 그런 장점만으로는 설득이 쉽지 않다. 어차피 바벨로 ES문법 적용할 시간에 이걸 적용했을때 얻는 이점이 앞으로 매니징등에 더 장점이 있다고 어필하는 편이 더 직접적으로 와 닿을 수 있다. 특히 이미 ES2015+ 문법을 사용하고 있는 조직이라면.
Angular가 처음 나왔을때 사내, 외 세미나에서 양방향 바인딩이 대단한 장점인양 설명했지만 개인적으로 이 부분이 의아했고(매직은 존재하지 않는다) 이로 인해 개인적으로 Angular(1.x)가 사양길로 갔다고 본다.
Next.js TypeScript Starter Kit
개인적으로 만들어 쓰던 빵판이기에 훌륭하다 할 순 없지만 레퍼런스등이 많이 부족한 상황에서 빠르게 개발할 수 있는 스타터 킷을 만들어 공개했다.
Next.js@5에 와서 드디어 TypeScript를 js로 컴파일해서 돌리는 찜찜함 없이 코드작성이 가능해졌다.
이 스타터킷에는 부가적으로 아래와 같은 것들도 포함되어 있다.
- Jest(with enzyme)
- PostCSS(css module)
- Storybook
여기서 Storybook같은 경우는 완벽하지 않다(특히 module css 적용시 등). 현재의 FE개발 환경은 웹팩이 기본으로 들어가면서 문법이 상한것들이 꽤 존재하는데 일반적으로 로더를 통해서 해결하나 이런 것들에 TypeScript가 함께 한다면 더 고도화된 설정을 필요로 한다.
또 Next.js같은 프레임웍은 자체 설정을 품고 있는데 이를 외부에서 사용할 테스트 프레임웍등에서 같은 설정을 유지하기에는 프레임웍 밖에선 무리가 존재한다.
그럼에도 불구하고 많은 시행착오를 줄여 줄 수 있길 바래본다.
아래는 Next.js@5가 나오면서 기쁜마음으로 컨트리with-typescript example 링크다.