청소 플랫폼 만들기 (21)
트러블 슈팅공부하며 느낀 점
참조한 페이지
청소 플랫폼 만들기 (21)
로그인 여부 판단하기
어제 지적을 받은 이후에 app.js에서 클라가 보낸 jwt를 받은 후, permission을 분리한 뒤, 넌적스 문법을 사용하여 로그인 유무를 결정하는(?) 로직을 만들었다.
하지만 넌적스 문법의 특성상 {{변수명}}을 body에 삽입해야하는 문제가 있었다.
위는 그 예시이다. 내 코드가 다 그렇지만 특히나 모범적이지는 않아서 코드블록으로 공유하지는 않는다.
이렇게한 뒤 .js에서 읽어서 css를 조절하는 함수에서 사용할 수 도 있었지만, 문제는 개발자 도구등으로 쉽게 값을 볼 수 있다는 문제가 있다.
또 다른 문제가 있는데, 그것은 넌적스를 사용하지 않는 경우에는 적용이 불가능하다는 것이다.
.html에 값을 넘기지 않고 바로 .js 파일로 바로 값을 넘기는 방법이 필요했다.
app.use(isLogin);
app.get('/', (req, res) => {
res.render('user.html', {});
});
app.get('/data', (req, res) => {
res.json({ look: res.locals.look });
});없는 짱구를 굴려서 나온 방법이 바로 별도의 미들웨어를 사용한 뒤, 특정 경로로 값을 보내는 것이다. jwt를 검증하고 permission 값을 가져오는 일은 isLogin 이라는 별도의 미들웨어에서 처리하고, 그 값을 /data라는 경로로 보내는 것이다.
그 후 js 파일에서는 아래와 같은 방식으로 가져왔다.
function isLogin() {
fetch('/data')
.then((response) => response.json())
.then((data) => {
var lookValue = data.look;
})
}이후 이 값을 바탕으로 로그인 된 계정에 따라서 보여줄 버튼을 css로 가려냈다.
리프레시토큰
이제 로그인 기능은 대충 완성 되었으니 리프레시 토큰을 추가할 차례다. 일부러 토큰 유효기간을 짧게 해보자.
토큰이 만료 된 경우 위와 같은 페이지가 뜬다.
리프레시 토큰이 있다면 엑세스 토큰이 만료되어도 새로운 엑세스 토큰을 발급 받았을 것이다.
리프레시 토큰에는 페이로드가 없으므로, 엑세스 토큰에서 페이로드만 제거해서 만들어보자.
// 엑세스 토큰생성
let acessToken = jwt.sign(
{
email: isExistUser.email,
userId: isExistUser.userId,
permission: isExistUser.permission,
},
process.env.COOKIE_SECRET,
{
expiresIn: process.env.JWT_EXPIRE_TIME,
}
);
// 아래와 같이 페이로드를 싹다 날려버리면 안된다.
// 리프래시 토큰생성
let RefreshToken = jwt.sign(process.env.COOKIE_SECRET, {
algorithm: 'HS256',
expiresIn: process.env.JWT_EXPIRE_TIME2,
});페이로드가 들어갈 칸{},은 남겨놔야하는데 그 칸 마저 날려서 오류가 발생했다.
// 리프래시 토큰생성
let RefreshToken = jwt.sign({}, process.env.COOKIE_SECRET, {
algorithm: 'HS256',
expiresIn: process.env.JWT_EXPIRE_TIME2,
});함수를 사용할때는 항상 형식에 유의하자
이제 리프레시 토큰을 만들었으니 쿠키에 넣을 차례다.
res.cookie('Authorization', token.acessToken, { httpOnly: true });
res.cookie('refresh', token.RefreshToken, { httpOnly: true });
잘 들어간다.
이제 로그아웃 할 때 지워보자.
res.clearCookie('Authorization', 'SignIn', 'refresh');안된다...
res.clearCookie('Authorization');
res.clearCookie('SignIn');
res.clearCookie('refresh');나름 간결하게 만든다고 하나에 다 때려박았는데 분명 두개까지는 잘됐는데 왜 세개부터는...
근데 좀더 검색해보니 두개도 제대로 안되는게 맞는것같다.
아무튼 이런 알고보면 별거 아닌 뻘짓으로 시간을 다 날려먹었다.
트러블 슈팅
버그를 고치는 경우
- 버그는 고칠 때 마다 시간이 단축된다.
- 백엔드 버그는 프론트와 다르게 전역적이다.
CS 지식은 트러블 슈팅에서 가장 중요한 기본기이다.
- 자료구조, 알고리즘 : 문제 해결 능력에 직결된다.
- 컴퓨터 네트워크 : 코드 밖에서 일어나는 일의 트러블 슈팅을 할 수 있어야한다.
- 백엔드의 경우 DB 구조도 알아야한다.
- 운영체제
- 컴퓨터 구조
오류의 인지
- 오류를 인지했다면 바로 프로젝트의 구성원들도 알 수 있어야한다.
- 프로젝트 리더나 테크 담당자는 해당 문제가 발생한 곳의 담당자를 찾는다.(나일 수 도 있다.)
- 담당자는 진행 상황을 보고한다.
문제 발생의 파악
- 에러 메시지 캡쳐
- 로그 파일 분석을 위해 로거를 사용한다.
보통 아래의 7단계중 중간의 5단계를 사용한다고 한다.
ALL < DEBUG < INFO < WARN < ERROR < FATAL < OFF
문제를 재현해보기
버그를 재현할 수 있다면 해결한것과 다름 없다.
- 문제 발생 조건을 test suite에 추가하기
- 부하테스트를 해본다.(아주 확실하게)
문제의 영역을 명확하게 한정해보기
- 왠만해서는 내가 짠 코드에 문제가 있다.
- 본인의 문제가 아니라면 패키지나 라이브러리의 문제다.
└ 깃 허브의 이슈를 찾아보자.
작성자, 기여자, 또는 지나가던 사람이 해결해 놨을 수도 있다.
문제가 잘 정의 됐다면 그것을 바탕으로 작업을 하자.
정보를 찾아보기
- 구글링, 스택 오버플로우, 깃 허브, gpt 등으로 빠르게 가이드라인을 만든다.
- 가이드라인을 기반으로 액션 아이템을 정리한 후 빠르게 수행하며 결과를 확인해보낟.
- 되는 것과 안되는 것을 확인하며 범위를 좁혀간다.
머릿속에 잘 그려지지 안흔다면, 코드의 흐름을 종이에 적어서 흐름을 파악하자. 변수의 상태를 춪거하며 버그의 원인을 발견하는 것이다.
문제 해결/실패
- 해결 : TIL 등에 적어놔서 나중에 같은 실수를 하지 않도록하자.
- 실패 : 새로운 방법을 찾아야한다.
다른 관점으로 보기, 추가 정보 수집, 도움 요청, 큰 문제를 작게 쪼개기, 다른 방법으로 우회하기, blocking session 등...
해결에 성공했든 실패했든간에 최대한 정리해서 팀원들과의 회의에서 이야기하자.
개선을 해야하는경우
개선 역시 버그 수정과 마찬가지로 어떻게 처리했는지에 대한 과정을 남겨야한다.
시스템 아키텍쳐에 대해 고민을 해야한다.
- 성능이 느려지는 부분의 시퀀스 전체를 파악해야한다.
- 상황에 따라서는 서비스 제공자에게도 연락을 해보자
└ 저희가 이런 부분에서 성능저하를 확인했는데, 대책이 있을까요?
동시성 처리 알고리즘
성능이 느린 쿼리는 관계 및 인덱스 확인
자주 불리는 API는 response 캐싱
신고시스템
오류나 이상 징후가 있을 시 시스템으로 알림을 받을 수 있어야한다.
Logger & Alram(by metric)
항상 커밋하기
언제나 실수를 할 수 있기 때문에, 로컬 환경에서 고치더라도 항상 코드 커밋을 하고 트러블 슈팅이나 핫픽스를 하자.
기타
DB 성능 이슈시 N+1 에러가 있는지 확인하자
챗 GPT는 항상 최신이 아니다.
모르는걸 모른다고 안하고 개소리로 포장하니 잘 거르자
GPT의 장점은 양산이다
구글링을 할 때는 아티클 위주로 보자
이미 유튜브 같은데 올라왔다면 씹뜯맛이 끝난건다
공학영어에 대해 잘알아야한다.
처음부터 번역기를 쓰지말자
공부하며 느낀 점
- 자꾸 간단한데서 실수를 한다. 제대로 알지 못해서 인듯하다.
- 그래도 점점 원하는 것을 그럴듯하게 구현해나가고 있다.
참조한 페이지
