이 글은 Typescript + TSLint + Mocha + Chai + ts-node + NYC로 모던한 프론트 엔드 테스트 환경 구축하기,
rollup.js를 통해 모듈 번들링하기에서 이어지는 내용이며,
여러 주제를 다루다보니 깊게 다루지는 않고 각각이 무엇을 하는 것인지만 간단하게 설명과 예제를 곁들여 진행하고 있습니다.
또한 예제 진행은 IntelliJ를 통해 진행했습니다.
WebStorm으로 진행해도 상관 없고, VS Code와 진행하면 더 짱짱맨일지도 모르겠습니다.
각 단계 별 깃헙 저장소 브랜치를 제공하고 있고, 이 포스트의 최종 결과물은 front-test-setting 저장소에서 확인 가능합니다.
이 글은 Typescript + TSLint + Mocha + Chai + ts-node + NYC로 모던한 프론트 엔드 테스트 환경 구축하기에서 이어지는 내용이며,
이 글을 본 이후에 travis-ci와 coveralls를 이용하여 좀 더 안전하게 협업하기를 보는 걸 추천드립니다.
여러 주제를 다루다보니 깊게 다루지는 않고 각각이 무엇을 하는 것인지만 간단하게 설명과 예제를 곁들여 진행하고 있습니다.
또한 예제 진행은 IntelliJ를 통해 진행했습니다.
WebStorm으로 진행해도 상관 없고, VS Code와 진행하면 더 짱짱맨일지도 모르겠습니다.
각 단계 별 깃헙 저장소 브랜치를 제공하고 있고, 이 포스트의 최종 결과물은 rollup-umd 브랜치에서 확인 가능합니다.
typescript 컴파일러나, ES2015+ to ES5 트랜스파일러인 바벨의 경우에는 모듈 간의 의존관계를 알지 못한다.
따라서 Webpack이나 Rollup, parcel과 같은 모듈 번들러로 번들링해야한다.
이 글은 rollup.js를 통해 모듈 번들링하기, travis-ci와 coveralls를 이용하여 좀 더 안전하게 협업하기을 읽기 전에 읽어야할 포스트이며
여러 주제를 다루다보니 깊게 다루지는 않고 각각이 무엇을 하는 것인지만 간단하게 설명과 예제를 곁들여 진행하고 있습니다.
또한 예제 진행은 IntelliJ를 통해 진행했습니다.
WebStorm으로 진행해도 상관 없고, VS Code와 진행하면 더 짱짱맨일지도 모르겠습니다.
각 단계 별 깃헙 저장소 브랜치를 제공하고 있고, 이 포스트의 최종 결과물은 nyc 브랜치에서 확인 가능합니다.
ts 브랜치에 예제 파일이 올라가있습니다.
이 포스트는 2017 GDG Seoul에서 Github와 CloudFlare를 이용한 무료 고성능 웹 어플리케이션 호스팅을
주제로 발표하신 박병진 님의 세션을 듣고 삘이 꽂혀서 바로 실행에 옮긴 삽질을 포스팅했습니다.
기본적으로 github page는 지킬이 내장돼있다.
따라서 지킬에서 사용한 템플릿들은 별도의 static html 파일로 빌드하지 않아도 서비스가 가능하다.
하지만 지킬을 설치하기 어려운 환경이거나 윈도우 유저(과거엔 윈도우에서 지킬 설치가 좀 힘들었다.), 비 지킬 유저(hexo, hugo, etc.)의 경우에는
웹 개발을 배울 때 항상 나만의 도메인을 가지고 싶었다.
github.io 라는 간지나는 도메인을 가지고 있긴 했지만, 지킬 내장이라 hexo를 쓰는 나로선 조금의 불편함이 존재했다.
따라서 io 도메인을 사려고 했지만 6만원이 넘어갔다…
그래서 값은 싸지만 나름 구리지 않은 닷컴 도메인을 사기로 마음 먹고 가장 저렴한 곳을 찾았다.
우선 기본적으로 회원가입을 진행해야 한다.
나는 귀찮아서 소셜 로그인(페북)을 이용했다.
그 이후에 메인 페이지로 가서 도메인을 검색하자.
똑같은 도메인이라 하더라도 사람들이 많이 찾는 단어일 수록 가격이 높으니 적당한 단어(자신을 알릴 수 있는?)를 선택하자.
MySQL의 데이터를 Elasticsearch로 마이그레이션 할 때 다음과 같은 방법이 존재한다.
logstash-input-jdbc 같은 경우에는 다음과 같은 단점이 존재한다.
자바스크립트 알고 쓰자. (잘 쓰자는 의미도 담겨있다.)
자바스크립트라는 언어 자체는 내 기준에서는 설계 상 미스가 참 많다.
함수 단위의 스코프, 호이스팅, 동적 타입 등등
자바와 같은 깐깐(?)한 언어를 배우고 바라본 자스는 허점 투성이처럼 보였다.
애초에 자바스크립트는 어떠한 프로그램을 만들기 위해서 탄생했다기 보다는
웹 페이지에 입력값에 대한 유효성 검사(데이터가 공란인지 아닌지 등등)와 같은
페이지의 동적 제어가 주된 목적 + 짧은 개발 기간(넷 스케이프 사의 새로운 브라우저에 탑재 예정) 때문에
설계 상에 미스가 있을 수 밖에 없다고 나는 생각된다.
일종의 안전 장치가 없어서 개발자가 일일이 구현해주고, 신경써야 하는 느낌이었다.
그렇다고 해서 자바스크립트를 극혐하거나 그런 것은 아니고 매우 사랑한다.
또한 그 허점을 아는 사람은 허점을 보완해서 요리조리 피해서 잘 쓰겠지만…
잘 모르는 부분들은 잘못 써도 동작이 잘 되기 마련이다.
이는 지금 당장에는 큰 문제가 안 될지 모르겠지만, 추후에 대규모 웹 어플리케이션을 만들거나
직면할 문제로부터 미리 해방시키기 위해 처음부터 좋은 습관을 들여가는 것이 좋다고 생각한다.
그 열 네 번째 시리즈는 call by value vs call by reference를 주제로 진행하겠다.
Call by 뭐시기 하는 것은 평가 전략(Evaluation Strategy) 중에 하나이며 위키피디아에서는 아래와 같이 서술하고 있다.
redirect를 위한 HTTP 상태 코드 301과 302에 대해 잘 모르겠다면 아래 링크를 참고하고 글을 읽도록 하자.
301리디렉션 & 302리디렉션의 차이(사용법)
307은 302와 유사하고, 308은 301과 유사하다.
다만 차이점이 있다면 전송 받은 HTTP Method를 유지한다는 것이다.
301과 302는 redirect 시킬 때 method를 get으로 바꿔서 전송한다.
따라서 get 요청을 보낼 때는 문제가 없지만 post 메소드를 요청했을 때 문제가 발생할 수 있다.
http to https redirect를 구현할 때 301 또는 302 상태 코드를 쓰게 되면
http 프로토콜을 통해 post 메소드로 날아온 게 https 프토토콜을 통해 get 메소드로 변경되면서 컨트롤러나 라우터에 매핑되는 URI가 없어서 오류가 나게 된다.
따라서 301 대신에 308을, 302 대신에 307을 쓰면 좀 더 안전하게 redirect 시킬 수 있다.
또한 이제 301과 302를 redirect라는 명칭으로 부를 수도 없다.
301은 Moved Permanently로, 302는 Found로 명칭이 변경되었다.
ELB가 요청 분산 및 오토 스케일링을 위한 것도 있지만 SSL 암호화 지원도 해줘서
인스턴스에 SSL 인증서를 물리면 인스턴스에서 암/복호화 등등의 리소스 낭비가 이뤄지지만 ELB에 물리면 ELB에서 다 처리되기 때문에
서버 입장에서는 부담이 더 줄어들게 된다.
하지만 역시 공짜는 아니니 Elastic Load Balancing 요금 파트를 참조하자.
돈이 없거나(ㅜㅜ) 공부 목적이 있는 사람은 직접 EC2 인스턴스(서버)에 HTTPS 서버 열기를 참고하자.
L4를 생성하기 전에 HTTPS 프로토콜을 위한 SSL 인증서를 만들어야한다.
공짜라고 하니 걱정하지말고 만들자.
기본적으로 서버와 도메인(SSL 인증서에 넣을)은 확보가 돼있는 상태로 진행을 해야한다.
자본이 빵빵하고(?) 좀 더 간단한 걸 원한다면 AWS ELB로 HTTPS 서버 열기를 보자.
해당 포스트는 ELB 말고 인스턴스에 직접 도메인을 달고, 인스턴스에서 직접 HTTPS 서버를 서비스 하고자 하는 포스트이다.
HTTP 통신은 데이터를 암호화하지 않아서 보안에 취약하다.
따라서 HTTPS 프로토콜로 통신을 해야하는데 암/복호화를 하려면 키가 존재해야하고,
그 키는 인증된 기관에서 만든 게 아니면 신뢰할 수 없는 키가 된다.
이 키에 대한 정보가 SSL 인증서에 들어가있는 것이고 이 SSL 인증서를 발급해주는 기관들이 따로 있다.
(사실 SSL의 이름은 TLS로 바뀌었지만 계속해서 SSL로 쓰이는 듯…)
그런데 그 인증서를 발급해주는 기관에서는 돈을 받고 SSL 인증서를 발급해주고 일정 기간마다 돈을 추가로 내서 갱신해야한다.