basic authentication은 http를 사용하는 agent가 서버에 요청할때 username과 password 제공하는 방법으로, http header Authorization 필드에 username과 password 를 결합하여 base64 encoding 한 값을 value로 설정한다.
ex) Authorization: Basic ${encodingUsernamePassword}
웹 리소스에 대한 가장 간단한 인증 기능을 제공하지만, http를 통해 전달되는 텍스트가 base64를 활용하여 누구나 복호화 할 수 있는 기법이므로 basic authentication 만을 사용하는것은 절대로 안전하지 않기때문에 민감정보나 귀중한 정보를 다룰때는 사용하지 않는 것이 좋으며 사용한다고 하더라도 HTTPS / TLS가 함께 사용하여야 한다.
es2015
javascript 모듈 문법
import { odd, even } from './var';
function checkOddOrEven(num) {
if(num%2) {
return odd;
}
return even;
}
export default checkOddOrEven;위의 문법은 node.js 에서 제공하는 require / module.exports 와는 차이가 있다.
es2018
Promise.all 을 대체할 수 있는 async/await 문법
const promise1 = Promise.resolve('성공1');
const promise2 = Promise.resolve('성공2');
(async () => {
for await (promise of [promise1, promise2]) {
console.log(promise);
}
})();
JavaScript 런타임
"Node.js는 Chrome V8 JavaScript 엔진으로 빌드된 JavaScript 런타임입니다." Node.js는 이벤트 기반, 논블로킹 I/O 모델을 사용해 가볍고 효율적입니다. Node.js 패키지 모듈 매니저인 npm은 세게에서 가장 큰 오픈 소스 라이브러리 생태계이기도 합니다.
런타임은 프로그램을 실행할 수 있게 해주는 환경입니다. 기존에는 javascirpt 프로그램을 인터넷 브라우저위에서만 실행할 수 있엇습니다.
브라우저 외의 환경에서는 속도의 문제때문에 호응을 얻지 못했고 2008년 구글이 V8엔진을 사용하여 크롬을 출시하자 좋은반응을 얻었습니다.
노드는 V8과 더불어 libuv라는 라이브러리를 사용합니다.
V8 과 libuv는 C와 C++로 구현되어 있고 이벤트 기반, 논블로킹 I/O 모델을 구현하고 있습니다. 노드의 내부 구조는 다음과 같습니다.
| Node.js Core Library | |
| Node.js Bindings | |
| V8 (자바스크립트 엔진) | libuv (비동기 I/O) |
이벤트 기반
이벤트기반은 이벤트가 발생할 때 미리 지정해준 작업을 수행하는 방식을 의미합니다.
이벤트 기반 시스템에서는 이벤트가 발생할때 수행할 일들을 미리 등록해 놓아야 합니다. 이런일들을 이벤트리스너, 콜백 함수를 등록한다고 표현합니다.
이벤트루프
non-blocking i/o를 위해 사용하는 libuv에서 이벤트 루프를 제공하며 아래와 같이 동작한다.
이벤트큐 (태스크큐)는 콜백들이 대기하는 큐(FIFO)형태의 배열이고, 이벤트 루프는 호출스택이 비워질 때마다 큐에서 콜백함수를 꺼내와 호출스택에 넣고 실행하는 역할을 해줍니다.
+ 태스크큐는 nextTick(우선순위 1)과 promise(우선순위 2)를 다루는 마이크로태스크 큐와 타이머(우선순위 2보다 낮음)등의 콜백을 지원하는 태스크 큐로 나뉩니다.
이벤트기반 시스템의 실행 예시
동작주체
이벤트루프: 이벤트 발생시 호출할 콜백 함수들을 관리, 실행순서를 결정. 서버 종료시 까지 루프
태스크 큐: 이벤트 발생후 콜백함수들이 실행되기전 대기하는 배열
백그라운드: 타이머나 I/O작업 콜백 또는 이벤트 리스너들이 대기하는 곳
코드:
function test() {
console.log('3초 후 실행');
}
console.log('start');
setTimeout(run, 3000);
console.log('end');
(참조: Node.js 교과서 조현영 지음 )
1. 호출스택에 main함수, setTimeout함수 순서로 쌓입니다 (LIFO)
2. setTimeout이 먼저 실행되고 호출스택에서 집니다. 그리고 run + 타이머 3초 가 백그라운드로 보내집니다.
3. 백그라운드에서 3초가 지난뒤에 run은 태스큐 큐에 보내집니다.
4. 호출스택에서 main함수가 실행이되고 호출스택이 모두 비워지면 이벤트큐가 태스크큐에 있는 작업중 가장 첫번째로 할 작업인 run함수를 호출스택으로 보냅니다.
5. 호출스택에서 run함수가 실행되고 실행 완료 후 호출 스택에서 비워집니다.
6. 이벤트 루프는 태스크 큐에 함수가 들어올때 까지 계속 대기하게 됩니다.
비동기 API의 컨텍스트 실행
$('.btn').click(function() { // (A)
try {
$.getJSON('/api/members', function (res) { // (B)
// 에러 발생 코드
});
} catch (e) {
console.log('Error : ' + e.message);
}
});(출처: https://meetup.toast.com/posts/89)
node.js 환경에서는 비동기 함수 사용에 대해 유의해야 합니다.
A와 B코드를 비동기로 수행할때 A와 B모두 이벤트 기반 시스템 동작으로 실행되는데 A에서 작성된 try-catch 구문이 B에게는 전혀 영향을 주지 않는것을 명심해야합니다. 좀 더 자세히 설명하자면 A가 먼저 호출스택에 들어가서 수행되고 호출스택에서 제거됩니다. A가 제거되고 난후 B가 태스크 큐에 들어간 후 호출스택에 쌓여서 실행되기 때문에 A에서 사용된 context와 B의 context는 독립적인 컨텍스트 환경에서 전혀 영향을 받지 않습니다.
논블로킹 I/O
논블로킹이란 이전작업이 완료될때까지 멈추지 않고 다음 작업을 수행하는것을 말합니다.
이벤트루프, 태스크큐에서 논블로킹 방식으로 작업을 처리하게 되면 오래걸리는 작업들을 나중에 수행하고 먼저 수행할 작업들을 빠르게 숭행할 수 있기때문에 작업을 효율적으로 수행할 수 있습니다.
싱글 스레드
싱글 스레드는 주어진 작업을 혼자서 처리하는것을 말합니다. 싱글스레드를 블로킹 방식으로 처리하게 되면 현재작업을 완료할때 까지 다음 작업은 무기한 대기해야하는 상황이 생겨서 비효율적입니다. node.js 에서는 싱글스레드에서 논블로킹 방식을 사용하고 있기 때문에
이전작업이 끝날때까지 기다리지 않고 작업을 요청받고 순서를 정한뒤 수행합니다.
| Best Pratices of Node.js Error Handling (0) | 2019.09.17 |
|---|
서로 다른 테스트가 종속되지 않아야 하나의 테스트가 실패하더라도 다른 테스트가 영향을 받지 않는다.
테스트는 Atomic한 속성(모두 성공 / 실패)을 따라야하며 중간에 실패를 하는경우가 있으면 안된다.
또한 테스트중인 데이터는 모든 테스트마다 분리하여 적용하지 않으면 테스트를 사용하는 전체적인 결과의 싱크를 보장할 수 없다.
-> 유저의 행동에 초점을 맞춰서 테스트를 설계하고 테스트하며 모든 사건에 대해서 독립적으로 다룬다. 각 테스트 별로 인과관계가 있지 않으며 모듈테스트시 필요한 작업들은 before / after 시점에서 하도록 한다.
-> 모듈 / 기능별 테스트를 작성하며 어떤 상황에서 어떤 시나리오로 전개되는지 명확히 작성하고 기대되는 결과를 반드시 적는다.
Assertion은 프로그래밍시 테스트에 사용되며 테스트를 보기 쉽게 설계하고 참과 거짓으로 결과를 알려준다.
예를들어 expect('age').to.be.equel('32')의 경우 변수의 연령에 따라 32와 같은지 아닌지 참/거짓의 결과를 알 수 있다.
일반적인 테스트 보다 코드라인의 설명이 쉬워서 테스트에 사용하기 용이하고 결과 또한 테스트 설계시 어떤 값을 예상하는지에 대해 명확하게 설계하기 때문에 일반적인 테스트와 같이 결과값에 대해 해석할 필요없이 참/거짓 값으로 테스트의 성공 유무를 알 수 있다.
-> chai를 사용. Should, Expect, Assert 등의 Assertion 모듈을 사용한다. 이는 chain문법이 사용 가능 하므로 읽기 쉽고 표현이 자유로우므로 BDD스타일의 테스트를 설계하는데 이점이 있다. ex) expect.(jake).to.have.property('develoiper');
테스트 러너는 테스트파일을 읽어들어 작성한 코드를 실행하고 결과를 콘솔 또는 로그로 출력해준다. 또 구현코드가 변경될시에 테스트를 재실해주는 Watcher의 기능도 제공한다. 테스트러너가 있으면 설정한 데이터베이스값( dummy/real )으로 테스트를 실행할 수 있다.
-> Mocha를 사용한다. 최초의 테스트도입으로 Mocha, Jest, Jasmine 이 셋 중에 고민이 있었다.
| Mocha | Jest | Jasmine |
|
|
모두 허용합니다.
|
Mocha가 라이브러리, 유틸리티 설정에 있어 어려울 수 있는 단점과, atomic test까지 지원하지 않지만 휴먼스케이프의 프로그램 특성상 전산상의 장애가 엄청나게 치명적인 결과를 일으키지 않는다는 판단과 라이브러리선택과 유틸리티 설정의 경우 그리 단점이 될것 같지 않아서 Mocha를 선택 하였다.
테스트커버리지를 잘 예상해야 한다. 테스트를 반드시 해야 하는지, 아닌지 판단을 해야 한다. 테스트에 들어간는 공수 또한 비용으로 책정되기때문에 테스트전 이를 잘 판단해보고 테스트를 진행해야 한다. 커버리지를 잘 판단하고 효율적으로 운용해야 한다.
-> 커버리지 설정에 고려해야 한다.
테스트 범위를 테스트하는 플러그인 사용할 수 있다. 플러그인은 테스트를 분석하고 테스트를 건너뛰었는지 여부를 알려준다. 모든 테스트 사례가 적용되었는지, 작성된 코드에 테스트가 적용되었는지 백분율을 알 수 있다.
-> 이스탄불 사용 예정.
테스트 커버리지를 분석하고 실패한 테스트의 이유를 분석하고 문제가 있는지 확인한다.
-> 이스탄불 사용 예정.
Mutation testing은 테스트의 조건을 수정하여 의도적으로 fail시키거나 fail의 경우 테스트를 통과시켜 코드내에 존재할 수 있는 애매모호한 부분을 찾는다. stryker와 같은 모듈을 사용하는것을 추천한다.
-> 도입생각 없음.
코드상에서 표절을 항상 확인해야 한다. 작업자가 인터넷에서 코드를 복사하여 동작시키는것은 흔히 있는 일이며 이는 라이센스상의 문제를 일으킬 수 있다. 이를 해결하기 위하여 plagiarism-checker 를 사용할 수 있다.
-> 라이센스 문제가 있을 수 있으니 도입 예정.
property 기반테스트는 엔터티의 property를 확인하기 위해 사용된다. 예를들어 input a, b가 있을때 b가 항상 짝수property를 가지는지 여부를 확인한다. 속성기반 테스트는 검사해야할 항목이 특정되어 있을때 함수의 임계값을 매우 쉽게 얻을 수 있으므로 예측가능한 장점이 있다.
-> Property 기반인것도 있고 아닌것도 있다.
Assertion라이브러리를 사용하여 테스트코드를 보기쉽게 작성한다.
-> supertest (http 관련 모듈) + chai 사용중이다.
예외적으로 일어나는 상황에 대해서 확인해야 한다. 일어날 수 있는 상황을 만들어서 응용프로그램이 어떻게 동작하는지 확인하고 어떤값이 반환되는지 알수 있어야 한다.
-> 시스템 전반적인 부분에 대해서 아키텍처를 보고 업무와 연관지어 예외적인 시나리오를 설계할 수 있어야 한다.
테스트는 단위테스트(독립적인 단위모듈) -> 통합테스트(모듈을 결합하여 테스트) -> 사용자 인터페이스 테스트(Selenium)를 수행한다.
모든 테스트 계획을 컴포넌트 모듈별로 나누어서 테스트한다. 단위테스트후에 컴포넌트테스트를 수행하며 컴포넌트 테스트는
단위 테스트보다 큰 범위와 빠른속도를 가진다.
-> 단위테스트로 구성한 후에 도입 고려.
테스터들은 보통 코드레벨에서의 테스트만 고려하여 인프라에서 발생하는 문제들을 놓치는 경우가 있다.
인프라에 대해서 테스트를 수행하고 피드백 보고서를 분석해야 한다.
-> 예외적인 시나리오와 동일.
테스트를 수행하기 위해서는 많은 라이브러리와 도구가 필요하다. 종속성이 오래된경우 테스트수행을 올바르게 수행하지 못할 수 있으므로 종속성에 대한 업데이트가 필요하다. 이러한 문제는 업데이트를 자동화하여 해결할 수 있다.
-> 적용해야한다.
ESLint와 같은 Lint플러그인은 코드 작성시에 오류, 문법을 검사하기 위해 제작되어있다.
Lint는 테스트시에 잘못 작성된 문법들을 catch하는데 도움을 주기 때문에 test시 같이 사용하면 좋다.
-> eslint 5.6.0 사용중 + prettier 적용해야함.
테스트를 병렬처리 하게 되면 피드백 루프에 대한 범위를 줄일 수 있고 이는 테스트시간을 줄일 수 있으므로 리소스 절약에도 도움이 된다.
-> isolate만 고려 병렬화에 대한 테스트까지는 공부를 좀 더 해야함.
-> 추후에 공부하여 선택.
단방향 해시 함수
단방향 해시함수의 문제점
단방향 해시함수 보완하기
CSRF(Cross-site request forgery, 사이트 간 요청 위조): 사용자가 웹사이트에 로그인 상태에서 사이트간 위조 공격 코드가 삽입된 페이지를 열면, 서버는 해당요청을 신뢰할 수 있는 사용자의 요청으로 인지하여 공격을 받을 수 있다.
[공격과정]
1. 서비스 이용자가 로그인하여 쿠키를 발급받는다.
2. 공격자는 링크를 서비스 이용자에게 전달한다. (이메일, 게시판등의 경로)
3. 공격용 html 페이지가 변조된 URL경로를 가진다. ( 변조된 URL 경로는 어떤 공격의 의미를 가지고 있다. )
4. 서비스 이용자가 공격용 페이지를 열면 브라우저는 이미지 파일을 받아오기 위해 공격용 html에 포함되어있는 변조된 URL을 요청한다.
5. 서비스 이용자의 승인이나 인지 없이 변조된 URL요청이 해당서버에 전달된다. 해당 서버는 인증에 있어 단순하게 쿠키로 확인을 하기 때문에 사용자 인증에 있어서 전혀 문제가 없으므로 공격자가 의도한대로 요청이 전달되어 수행된다.
1. Use Async-Await or promises for async error handling
비동기식 콜백 오류를 다루는것은 매우 어려운 일이므로 reputable promise library를 사용하거나 async-await 에 try-catch 와 같이 친숙한 구문을 사용하는 것이 좋다.
2. Use only the built-in Error object
error object는 내장객체만을 사용하는것이 통일성이 향상되고 정보손실을 방지할 수 있어 좋다. custom 객체를 사용하는경우 상호 운용성이 복잡해진다. ( ex: stack trace 정보가 손실될 수 있음 )
3. Distinguish operational errors vs programmer errors
운영상의 오류와 프로그래머가 내는 오류를 분류한다.
운영상의 오류는 프로그래머가 이해할 수 있는 내의 범위의 오류를 말한다.
프로그래머 오류는 알 수 없는 코드장애로 응용프로그램을 다시 시작하는 오류를 말한다.
( 알려지지 않은 오류로 응용프로그램을 다시 시작해야한다면 다중사용자에 대응도가 매우 떨어지기 때문에 상황에 대한 대처법을 적용해야 한다. )
4. Handle errors centrally, through but not within middleware
모든엔드포인트의 에러는 캡슐화를 잘해서 메일 또는 로그로 중앙에서 관리할 수 있도록 해주어야 한다.
5. Document API errors using Swagger
스웨거에 에러에 대한 가이드를 명시한다. 사용자가 에러에 대한 대처를 작성할 수 있다.
6. Shut the process gracefully when a stranger comes to town
알 수 없는 오류가 발생할 경우. 애플리케이션 운영 상태에 대한 보장을 할 수 없으므로 Forever 나 PM2 같은 restarter를 사용하여 프로세스를 다시 시작한다.
7. Use a mature logger to increase errors visibility
Winston, Bunyan, Log4J 와 같은 로깅 도구를 사용하면 오류 발견을 쉽게할 수 있다.
console.log를 사용하는 것보다 오류 디텍팅 비용을 아낄수 있다.
8. Test error flows using your favorite test framework
코드가 작성자가 의도한 시나리오를 충족하는지, 올바른 오류를 처리하고 있는지 확인한다.
9. Discover errors and downtime using APM products
모니터링 및 성능측정 제품을 사용하여 오류 및 다운타임을 검색한다.
10. Catch unhandled promise rejections
unhandled promise rejections을 catch 한다. 오류에 대해 기록을 남기고 처리할 수 있는 방법을 생각해 본다.
11. Fail fast, validate arguments using a dedicated library
arguments에 대해 검증할 수 있는 library를 사용한다.
| Node.js 핵심개념정리 (0) | 2019.10.15 |
|---|
Backup Process
1. Databases -> DB선택 -> Schemas -> public -> 우클릭 -> 메뉴에서 Backup을 선택
2.1 General 탭
-> Filename: 저장할 경로와 Backup File명 작성
-> Format: Custom or tar 선택
-> Role name: DB User 선택
2.2 Dump options 탭
-> Sections: Pre-data, Data, PostData Yes로 선택
-> Type of objects: 설정 변경하지 않음
-> Do not save: Owner, Previlege Yes로 선택
-> Queries: Include CREATE DATABASE statement, Use Insert Commands Yes로 선택
-> Disable: 설정 변경하지 않음
-> Miscellaneous: 설정 변경하지 않음
2.2까지 설정을 완료하고 General탭에서 Backup 버튼을 클릭! 하면 아래와 같이 Backup 스케쥴이 생성된다.
백업이 완료되면 아래와 같은 화면이 나타나고 사용자가 지정한 위치에 백업파일이 생성됩니다.
Restore Process
1. Databases -> DB선택 -> Schemas -> public -> 우클릭 -> 메뉴에서 Restore를 선택
2.1 General 탭
-> Format: Custom or tar 선택
-> Filename: Restore 대상 File명 선택
-> Role name: DB User 선택
2.2 Restore options 탭
-> Sections: Pre-data, Data, PostData Yes로 선택
-> Type of objects: 설정 변경하지 않음
-> Do not save: Owner, Previlege Yes로 선택
-> Queries: 설정 변경하지 않음
-> Miscellaneous / Behavior: 설정 변경하지 않음
Restore가 완료되면 다음과 같은 창이 나타납니다.
테스트 주도 개발 (TDD)는 더 나은 소프트웨어를 만들기 위한 기법 중 하나다.
테스트 코드를 작성해야 하는이유?
1. 코드의 정상작동 유/무를 확인하기 위해서, 소프트웨어에 대한 피드백 과정이 줄어든다.
( 소프트웨어 출시에 있어 피드백 과정이 줄어드는 것이 프로젝트 전체의 일정으로 보았을때 매우 효율적이다 )
2. 새로운 하부시스템을 전체 프로젝트에 통합하기 전에도 매우 유리하다.
3. 운영되는 코드에 대해 문제를 빨리 알수 있고 수정이쉽고 비용이 낮아진다.
테스트 코드 작성시 알아아두어야 할것.
1. 최대한 많은 개발자 테스트를 자동화 하는것이 핵심.
2. 테스트 코드 작성에 따라 코드 작성시간이 올라갈 수 있지만 코드의 품질을 생각하여 테스트를 수행하는것이 좋다.
3. 잘못된 테스트 코드는 불필요한 리소스를 낭비할 수 있지만 테스트 코드 작성자가 테스트 코드에 대해 이해하고 적절한 테스트 전략을 세운다면 테스트 코드는 작성하지 않을 이유가 없다.
4. 모든 단계의 소프트웨어 스택과 개발 프로세스에 대해 테스트를 수행해야 한다. 특히 가장 작은 범위에서 테스트를 수행해야 피드백 과정 ( 문제발견 / 수정 )을 줄일 수 있다.
테스트의 유형
- 유닛 테스트
가장 작은 단위의 기능에 대한 테스트를 단독으로 수행하는 것. 각각의 함수가 정확히 작동하는지 확인하기 위한 것.
- 통합 테스트
통합 테스트를 통해 각각의 단위 모듈을 더 큰 결합체로 통합하여 작동시키는 복합 기능을 검증할 수 있다.
- 시스템 테스트
'end-to-end tests' 이 테스트를 통해 전체 시스템에 대한 요구사항 명세를 확인할 수 있음. 통합된 소프트웨어 스택 전체에 수행되는 테스트로서, 프로젝트에 대한 검수 기준으로 사용됨.
테스트 작성 시기
1. 코드를 작성할때 ( 테스트코드를 같이 작성, 나중에 할 수록 테스트 효과가 줄어듬 )
2. 출시코드에 대해 버그를 수정할 때 ( 코드수정을 바로 하지말고 버그의 원인을 설명하는 실패 유닛 테스트를 작성하라 )
3. 빌드과정에서 테스트를 끼워넣을 수 있도록 하자.
테스트 대상
요구사항에 맞게 테스트하라 ( 어떠한것도 테스트대상이 될 수 있다 )
좋은테스트
1. 짧고 명확한 이름을 가지고 있어 실패했을때 원인파악이 쉬움.
2. 유지보수가 쉬움.
3. 수행에 오랜 시간이 걸리 지않음.
4. 최신 구현 코드(작업물)에 맞춰져 있음.
5. 특별히 머신 설정이 필요 없다.
6. 다른 테스트에 대한 의존성이 없어서 특정 테스트 전후에 실행할 필요가 없다. 외부 상태나 코드상의 어떤 공유 변수에 대한 의존성이 없다.
7. 실제 구현코드를 테스트 한다. ( 복제본이 아님, 복제본은 쓸모없을 수 있음 )
나쁜테스트
1. 일정한 결과값을 갖지 않음 ( 때로는 성공, 때로는 실패 )
2. 유지보수하기 힘든 테스트
3. 지나치게 큰 테스트
4. 하나의 테스트케이스에서 둘 이상을 수행하는 테스트
5. 직접 작성하지 않은 서드파티 코드에 대한 테스트
6. 필요하지 않은 기능에 테스트하는 테스트
7. 기능이 보장되어있는것까지 하는 테스트 ( ex: 속성의 getter, setter에 대한 테스트 )
8. 단 하나의 머신에서만 수행 가능한 테스트
테스트의 형태
- 테스트의 기본 프로세스
배치( 검사를 실행할 준비 ) - 실행 - 검증 ( 예측된 값이 맞는지 검사 실행 )
- 테스트 이름
명확한 테스트 명명을 하는것이 좋음.
테스트의 구조
- 테스트가 코드의 중요 기능을 모두 다른 점을 보장하라.
- 테스트는 중복해서 수행하지 않는다. ( 중복 수행은 노력과 혼란, 유지 보수 비용을 가중시킴 )
- 코드의 특정 행태를 확인하는 테스트를 작성하라.
테스트 유지 보수
- 테스트코드는 깔끔하게 다듬고 리팩토링을 하라.
- 코드를 수정하고 테스트케이스를 제거하지마라 테스트케이스 또한 유지보수를 하라.
출처: 훌륭한 프로그래머 되는 법
| 7장 ( 똥통에서 뒹굴기 ) - (0) | 2017.10.12 |
|---|---|
| 4장 (코드 줄여 개선하기) - 6장 ( 경로 탐색하기 ) (0) | 2017.10.10 |
| 1장 (코드에 신경 쓰기) - 3장 ( 코드 적게 쓰기 ) (0) | 2017.10.09 |
4장. 라이브러리
라이브러리 사용시의 장점
| CI. 3_컨트롤러 사용법과 유효 범위 (0) | 2017.11.17 |
|---|---|
| CI. 2_설정과 명명 규칙 (0) | 2017.11.15 |
| CI. 1_입문 (0) | 2017.11.13 |