Swagger 등을 사용해 API 에러를 문서화하라
Swagger와 같은 라이브러리를 사용하여 API 에러를 문서화 하는 것도 중요합니다.
API 호출자에게 어떤 에러가 발생할 수 있는지 미리 알려주어 에러를 충돌없이 신중하게 처리할 수 있도록 하는 것입니다.
REST API는 HTTP 상태코드를 사용하여 결과를 반환합니다.
API 사용자는 API 스키마 뿐만 아니라 API 사용 중 발생할 수 있는 잠재적인 오류에 대해서도 알 수 있어야, 알고 있어야 합니다.
예를 들어, 이미 존재하는 고객 이름으로 사용자를 등록할 때
API 문서에 HTTP 상태 409가 반환될 수 있음을 명시하여 API 사용자가 주어진 상황에 적합하게 대처할 수 있도록 할 수 있습니다.
낯선 접근이 있을 경우 프로세스를 적절하게 중단하라
이전 글에 작성한 것처럼, 알 수 없는 에러(프로그래머 에러)가 발생할 경우 어플리케이션의 건강상태가 불확실해집니다. 일반적인 경우 Forever나 PM2같은 '재시작' 도구로 프로세스를 다시 시작할 수 있습니다.
Node.js 공식 문서
"불안정하고 정의되지 않은 상태를 만들지 않으면서 안전하게 떠날 수 있는 방법은 없습니다"
(No safe way to leave without creating some undefined brittle state)... 자바스크립트에서 throw가 작동하는 방식의 특성상 참조를 누출하거나 다른 종류의 정의되지 않은 취성 상태를 생성하지 않고 안전하게 "중단한 부분부터 선택"하는 방법은 거의 없습니다. 던져진 오류에 응답하는 가장 안전한 방법은 프로세스를 종료하는 것입니다. 물론 정상적인 웹 서버에서는 많은 연결이 열려 있을 수 있으며 다른 사람에 의해 오류가 발생했기 때문에 갑자기 연결을 종료하는 것은 합리적이지 않습니다. 더 나은 접근 방식은 오류를 트리거한 요청에 대해 오류 응답을 보내고 나머지는 정상 시간에 완료하도록 하고 해당 작업자의 새 요청 수신을 중지하는 것입니다.
알 수 없는 에러(프로그래머 에러 등)에 대한 적절한 방법은 프로세스를 중단하는 것이지만,
웹 서버에서는 많은 연결이 열려 있을 수 있고, 따라서 갑자기 연결을 중단하는 것이 합리적이지 않다고 Node.js 공식문서는 이야기 합니다.
따라서 오류를 트리거한 요청에 대해 오류 응답을 보낸 후, 해당 요청자에 대한 새로운 요청을 거부하는 방법도 고려할 수 있습니다.
안정된 에러 확인 로거를 사용하라
Winston, Bunyan, Log4js 같은 안정적인 로깅 도구는 에러를 발견하고 이해하는 속도를 높여줍니다.
로그 검색 도구나 로그 뷰어 없이 console.log를 훑어보거나 복잡하게 꼬인 텍스트 파일을 읽는 것은 효과적이지 못하기 때문에 console.log의 사용을 지양합니다.
Winston Logger 예시
// your centralized logger object
var logger = new winston.Logger({
level: 'info',
transports: [
new (winston.transports.Console)()
]
});
// custom code somewhere using the logger
logger.log('info', 'Test Log Message with some parameter %s', 'some parameter', { anything: 'This is metadata' });로그 폴더 쿼리(항목 검색) 예시
var options = {
from: new Date - 24 * 60 * 60 * 1000,
until: new Date,
limit: 10,
start: 0,
order: 'desc',
fields: ['message']
};
// Find items logged between today and yesterday.
winston.query(options, function (err, results) {
// execute callback with results
});블로그 StrongLoop
"로거 요구 사항"
- 각 로그 줄에 타임스탬프를 지정합니다. 이것은 매우 자명합니다. 각 로그 항목이 발생한 시간을 알 수 있어야 합니다.
- 로깅 형식은 기계뿐만 아니라 사람도 쉽게 소화할 수 있어야 합니다.
- 여러 구성 가능한 대상 스트림을 허용합니다. 예를 들어, 하나의 파일에 추적 로그를 작성하고 있을 수 있지만 오류가 발생하면 동일한 파일에 작성한 다음 오류 파일에 작성하고 동시에 이메일을 보내십시오…
선호하는 테스트 프레임워크로 에러 흐름을 테스트하라
테스트가 없다면 우리의 코드가 올바른 에러를 반환하는지 알 수 없습니다.
코드가 올바른 에러를 처리하고 반환하는 지 확실히 해야합니다.
Mocha & Chai 와 같은 테스트 프레임워크를 쓰면 쉽게 처리할 수 있습니다.
우수한 테스트 코드 커버리지는 예외적인 경로를 포함해야 합니다. 그렇지 않다면 예외가 실제로 올바르게 처리된다는 신뢰를 얻을 수 없습니다.
보통 Mocha & Chai 와 같은 단위 테스트 프레임워크는 예외 테스트를 지원합니다.
모든 내부 기능과 예외를 테스트하는 것이 지루하다면, REST API HTTP 오류만 테스트할 수 있습니다.
Mocha & Chai를 사용하여 올바른 예외가 발생하는지 확인
describe("Facebook chat", () => {
it("Notifies on new chat message", () => {
var chatService = new chatService();
chatService.participants = getDisconnectedParticipants();
expect(chatService.sendMessage.bind({ message: "Hi" })).to.throw(ConnectionError);
});
});API가 올바른 HTTP 오류 코드를 반환하는지 확인
it("Creates new Facebook group", function (done) {
var invalidGroupInfo = {};
httpRequest({
method: 'POST',
uri: "facebook.com/api/groups",
resolveWithFullResponse: true,
body: invalidGroupInfo,
json: true
}).then((response) => {
// if we were to execute the code in this block, no error was thrown in the operation above
}).catch(function (response) {
expect(400).to.equal(response.statusCode);
done();
});
});