첫미팅
공통
account id url 을 어떻게 관리해야 할까요?
- jwt의 페이로드나 api uri, api response에 유저 id를 공개하면 안되는지 궁금합니다.
- ( 프론트쪽에서도 질문이 들어왔씁니다.)
- 그러면 pk id는 숨기고 공개용 uuid를 두어서 사용하는 방향?? 같은 것이 있는지 궁금합니다.
- uuid를 pk를 사용하는 방향은 성능적 이슈가 있을 것 같은 생각도 있습니다.
케빈
- ssl(https)를 프로젝트에 적용해야 할까요??
- self sign
- 게시글에 필요한 이미지 업로드 기능 구현시 이미지 리사이징이나 썸네일 정책 관련
- lambda를 쓰는 이유?? 비동기??
티거
CI/CD 검토
- 구축 난이도와 가능성에 대해 피드백을 받고 싶습니다.
파이프라인


Security
- Oauth 테이블을 따로 가져가야 할까요?
- 주로 따로 가져간다
이미지
- 이미지 테이블 관리포인트
- 한 테이블에서 모든 이미지를 관리한다.
- 유저는 유저, 게시물은 게시물대로 테이블을 만들어 관리한다.
범키
- 오픈 API 시크릿 키 관리를 어떻게 해야 할까요?
- 저희 서버? aws?
- 좋은 서비스 있는지도 궁금합니다!
추가하면 좋을 내용들
- 위치기반 지역 설정
2차 & 3차 미팅
CI/CD
- 1안정도가 적당할 것 같다.
- 도커까지 같이하면 시간투자가 많이 될 것 같다. → Should Have
account id url
- uuid 는 쓸데없는 짓
- 보안 측면은 걱정하지 않아도 된다.
ssl
- 채팅을 하지 않으면 필요가 없을 수 있다.
- self sign?
- 적용하자!
- 구현할 수 있는게 많아진다!
이미지
- s3는 거의 비동기를 사용한다.
- 그래서 람다를 사용하게 한다.
- resizing, thumnail 후 등록
- 이미지 업로드와 게시물 등록은 별개의 transaction이다.
- 에러 후 기본이미지는 디비에 저장할 필요가 없고 프론트에서 불러오면 된다.
이미지 테이블
- 따로 분리해서 하는게 맞다.
security
- user정보랑 security정보는 분리해야 한다.
- refresh 토큰은 클라이언트에서 보관하면 위험하다. 그래서 디비에 저장하다.
- 만료되면 타임스탬프 비교해서 디비를 갔다 온다.
- Oauth와 로컬 정보가 같다면 같은 테이블에 보관해도 좋다.
시크릿 키
- aws management
- github
추가 기능
- map을 사용해 반경 ~km를 보여주는 기능?!
- 지역을 redis를 사용해 렌더링?
- 컨트롤러 더미 객체 - faker~?
- 리프레쉬 토큰만 쿠키로 주고받으면 된다.
- axios - interceptor로 만료되면 알아서 요청, 응답한다.
- refresh token은 테이블을 따로 둔다.
- jwt token을 받기 위한 유효시간이 긴 토큰이다.(열쇠)