• 코드 컨벤션

  • 토글

• 깃플로우 전략

  • 토글

• 배포 계획

  • 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:

    SSE로 알림 기능 구현하기 with Spring

    여러 방식이 존재하지만 websocket 방식이 가장 빠름.

    채팅방 - RDB

    채팅내용 - NoSQL

    • 채팅 데이터 redis, mongDB, elasticSearch 어디에?
      • redis나 mongoDB 사용 시 mysql redis,mongodb

    A:

    저장기간은 정하기 나름.

Q: 스코프

A:

오래걸릴 것 같은 기능 - 채팅 (저장소 정하기, NoSQL통합,), 페이징(queryDSL - 미리 공부, 조건에 따른 동적 쿼리), CI/CD, 프론트..