codestates / codestates/SoundBubble
[Dev_Log] 8/16 (월) 김재우
- Dominant language
- TypeScript
- Stars
- 3
- Forks
- 2
- PR merge metrics
- No merged PRs in 30d
Description
### 오늘은 어떻게 프로젝트에 기여했나요?
* 서버 응답 상태 및 응답 메시지 수정
지난주 주말부터 서버 응답 상태 및 메시지 리팩토링을 하고, API 문서도 수정하였다. 좀 더 Restful한 API를 제공하기 위해 서버의 응답 상태와 메시지를 전체적으로 수정하였다. 클라이언트에서 처리하기 쉽도록 통일성을 유지하려고 노력했다. 모든 요청에 대해 다음과 같은 템플릿을 지키며 작성하였다. 400 에러의 경우, 어떤 파라미터가 부족한지 구체적으로 클라이언트에게 알려주도록 메시지를 세분화시켰다.
400 요청 파라미터 부적절: 없거나 형식에 맞지 않음
401 인증 실패: 토큰 검증 실패 → 사용자 재로그인 필요
403 권한 없음: 비밀번호가 다르거나 본인이 작성하지 않은 버블, 댓글에 대한 삭제 요청
404 요청한 리소스 없음: 없는 페이지, 삭제된 페이지
409 충돌: 이미 존재하는 이메일, 기존과 변경되지 않은 새로운 닉네임, 비밀번호
500 서버 에러: 내부 서버 오류, DB 접속 실패
* 서버 타입 수정
코드를 작성하면서 임시로 지정했던 any 타입을 1차적으로 모두 수정하였다. 값이 안 넘어올 수도 있는 쿼리 파라미터를 체크하는 함수를 모듈화하고 구체적으로 타입을 지정했다. 커스텀 토큰 검증 함수의 경우 리턴 타입을 jwt.verify 함수와 동일한 string | JwtPayload 타입으로 지정하고, 검증 시에는 JwtPayload으로 타입 단언을 적용하여 eslint의 경고를 제거했다. 하지만 구체적으로 토큰 내부를 정의한 것이 아니고 결국 jwt 모듈 내부에 정의된 any타입에 의존하는 방법으로, 타입스크립트의 장점을 살리는 방법이 아니기 때문에 이후에도 점차적으로 수정할 예정이다.
* 서버 에러 응답 로직 수정
RequestHandler의 에러 핸들링 방법을 수정했다. 기존의 모든 컨트롤러에서 에러를 응답하는 대신에 에러를 메인 파일에 존재하는 에러 핸들링 미들웨어로 넘겨주는 방법을 사용했다.
### 오늘의 프로젝트에서 힘든 점은 무엇인가요?
* eslint 적용
타입스크립트에 eslint를 적용하면 어떤 변수에 타입이 지정되지 않았는지 경고를 통해 쉽게 알 수 있다. 하지만 내가 타입을 지정하기 어려웠던 부분이 그만큼 존재했다는 뜻인데, 대표적으로 요청 파라미터와 토큰이다. 클라이언트에서 어떤 파라미터를 넘겨줄지 모른다, API 문서를 지키지 않은 요청도 존재할 것이다 등의 생각을 가지고 처음에 any를 지정했었다.
토큰 검증의 경우 커스텀 함수를 사용하는데, 검증에 성공하면 payload, 검증에 실패하면 error 값이 그대로 리턴되도록 작성했다. 때문에 어떻게 리턴 타입을 지정해야할지 아직 구체적으로 떠오르지 않아서 JwtPayload 타입을 사용했다. 구체화시킨다면 토큰의 페이로드 타입과 모든 에러 타입을 유니온 타입으로 지정해줄 수 있고, 또는 함수 자체를 수정하는 방법도 있다. 좀 더 타입스크립트를 공부하여 수정하려 한다.
### 오늘의 프로젝트에서 배운 점은 무엇인가요?
* Express의 에러 핸들링 미들웨어 사용
에러 핸들링 미들웨어를 실제로 사용하는 방법은 이전 핸들러에서 에러를 넘겨주는 것이다. 이전 코드에서는 모든 RequestHandler마다 catch 부분에서 에러를 처리했지만 next를 이용하는 방법으로 변경하였다.
```js
// 컨트롤러 파일
// ...
} catch (err) {
logError("Failed to upload bubble");
next(err);
}
```
* 특정 라인에 eslint 적용 해제
Express의 에러 핸들링 미들웨어는 반드시 인자 4개(err, req, res, next)를 받아야 한다. next의 경우 코드 블록 내부에서 사용되지 않으므로 eslint의 no-unused-vars 속성에 걸리는데, 주석을 이용해서 특정 코드 라인에 eslint 적용을 해제할 수 있다.
```js
// 메인 파일
// ...
// eslint-disable-next-line @typescript-eslint/no-unused-vars
app.use((err: unknown, req: Request, res: Response, next: NextFunction) => {
console.error(err);
res.status(500).send("Internal Server Error");
});
```
### 내일은 프로젝트에 기여하기 위해 무엇을 해야 하나요?
* [ ] Redis 블랙리스트 적용
* [ ] 클라이언트 구글 소셜 로그인 적용
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.