What I did today:
어드민 페이지 작업
- status 값이 중첩돼서 고민하다가 그냥 시원하게 기존 방법을 가져가기로 했다.
크론잡 수정
- 오늘 8시 이전의 것들만 리마인더 가도록 수정했다.
What I need to do next:
payment 쪽 고치기
어드민 페이지 작업
- matchinghistory는 나중에 생각하고...
- 상담사 마감기한 산정을 어떻게 할지 고민이다.
- 상담사 매칭기록을 어떻게 남기면 좋을까? matchtime 이용하자
- 릴리프톡 상세확인부터 시작!
스테이징 환경 싱크
- 기억할 것:
- 스테이징 데이터베이스 아키텍쳐 싱크 맞춰놓기
- 스테이징 데이터베이스 데이터 싱크 맞춰놓기
- aws_utils 바꾸기
- setting_secrets
- 그리고 코드 베이스 적용!
production 환경 싱크
- 이제 슬슬 production 어떻게 싱크할지 생각해야 한다. 참조관계 바뀌는 건 제외하고 크게 문제 없을 것들만 추가 및 제거해보자. 예를 들어 voiceletter 테이블의 user_receive_date! (커밋 78709a5b866b907fc91436626a6842710387ab32)
- settings 파일 분리
- setting_secrets 싱크
- models.py 비교
What I learned:
프론트로 에러를 어떻게 보낼까?
status: 200, success: false, errorMessage: "해당 사용자의 데이터가 없습니다", result: nul- 뭐든 성공하면 200을 보내주고 크리티컬한 것만 500으로 처리하는 방식이 다수가 택하는 방식이라고 했다. 이유는:
브라우저가 400대면 에러페이지를 띄우자나 자동으로 해주니까 그냥 그거 쓰는데 보안상 별로안좋아서 200대로 만들어서 커스텀 에러 페이지 띄움. 403 뜨면 해당 폴더가 있다는 정보가 노출되는거라 그래서 보안 점검할때 403/404 같은 에러 잡거든.
400대 에러코드로 구분해서 프론트에서 메시지 만드는 건 좀 비효율적일 수도 있다는 의견
등등이 있었다...
