•
코드 컨벤션
토글
•
깃플로우 전략
토글
•
배포 계획
◦
Github action으로 Ci & CD 구현하여 배포
•
이번 주 한 일
토글
•
팀원 개인
팀원
팀원
팀원
팀원
•
이외에도 기술적인 방향을 잡기 위한 질문을 정리해두시면 가장 좋습니다!
1. 외부 api(날씨)를 사용
A :
자주 조회될 가능성 높음 → 캐시 이용 실시간 조회
api로 조회가 안될경우 저장된 데이터를 활용해야됨 → 스케줄러 → 시간 소요 큼 (안하는 것 추천)
현업에서도 저장하지 않는 경우가 많음 (저장한다는 것 자체가 비용 소모 발생)
2. 도시명 필드를 어떻게 가져가는게 좋은지
A:
분리를 시키는게 적합함 (분리를 시키지 않는 경우 문자열 처리까지 해야하는 일이 발생)
3. 팔로우 테이블을 하나로? 두개로?
A: 하나로 합쳐도 되지만 두 개로 나누는게 자연스러움
테이블이 많아지면 결국 비용 발생 (rdb의 경우 scale - up 만 가능하기 때문)
db 성능 테스트 → nGrinder, K6 (10000건 이상 테스트해야 유의미함, 쓰기/읽기)
4. 파일이 여러개 들어가면 테이블이 따로 필요한 것인지
→ 게시판 마다 각각의 첨부파일 테이블을 만들어야하는지?
A:
해당 목록에 대한 테이블이 각각 필요함
하나의 테이블로 관리하면 조회하기 힘들다.
테이블 수가 늘어나는것에 대해 너무 경계할 필요 없음.
5. 채팅 도메인 api 설계
◦
erd 보여드리면서 서비스 의도 설명
◦
항상 열려있는 채팅방, 누구나 참여 가능한 채팅방
A:
여러 방식이 존재하지만 websocket 방식이 가장 빠름.
채팅방 - RDB
채팅내용 - NoSQL
▪
채팅 데이터 redis, mongDB, elasticSearch 어디에?
•
redis나 mongoDB 사용 시 mysql redis,mongodb
A:
저장기간은 정하기 나름.
Q: 스코프
A:
오래걸릴 것 같은 기능 - 채팅 (저장소 정하기, NoSQL통합,), 페이징(queryDSL - 미리 공부, 조건에 따른 동적 쿼리), CI/CD, 프론트..
•
팔로우 db 성능 테스트는 나중에 nGrinder나 k6 이용해서 만건 이상해보기
•
숙제: 멘토링 결과 다음 주까지 해올 일
◦
팀 전체 (리더와 부리더님께서 필두로 정리해 주세요.)
▪
기본적인 기능 (쉬운것들) 완성
◦
팀원 개인별로 작성해 주세요.
▪
채팅 - 기능 구현 (저장관련은 나중에 고민해도 됨)
▪
프론트 - 타임리프 → html 태그 , css 부트스트랩 사용 스타일링, 공통된 레이아웃(템플릿) 사용
▪
조회 - 동적쿼리 구성해보기 , queryDSL 공부
