[3주차] 멘토님과 회의(2021.11.10) - boostcampwm-2021/WEB25-JustUs GitHub Wiki

  • oauth 로그인 관련 질문(콜백 URL 오류)

    • 프론트 단에서 call을 할 때 처리를 어떻게 하느냐?

    • nginx로 url 파싱이 잘못되서 naverAuth로 못들어 가는 것.

    • nginx 설정을 바꿔주면 될 것 같아 보임.

    • 앞에 도메인을 붙여줘야 할듯. → 붙여 주니까 콜백 url이 제대로 잡히긴 함.

    • docker-compose로 연결되어 있으면 도커 자체에 포트 명시 안해줘도 됨.

    • MySQL 싱크 문제였음 ( 0 → 1)

  • 순서 정보에 관한 질문

    • MYSQL에 JSON 컬럼이 있어 key,value를 지원한다.
    • 바뀔때마다 프론트가 그룹 A라는 전체의 JSON을 주면 그 상태로 덮어써버리면 될 것 같다.
      • 업데이트가 잦으면, DB에 전체를 업데이트 해야함. 오버엔지니어링적인 측면에서 고민한다 해도, 미래를 본다면 NoSQL을 써도 될 것 같아 보임.
      • 근데 이정도 규모에서 NoSQL을 썼다 하면 굳이?라는 생각이 들긴 할 듯.
      • 서비스가 엄청 커져 단일 사용자가 많아지면, 몇백만명의 사용자가 몇초마다 업데이트 쿼리를 RDB가 받기에는 빡세보임.
      • NoSQL을 써보는 게 좋다고 생각한다.
      • 다른거에 쓸 일이 없으면 RDB에는 안넣어도 될 것 같음.
    • 그룹 ↔ 앨범 ↔ 게시글 ↔ 관계가 다 맺어있는데 어떻게?
      • RDB가 있어야 나머지 물릴 수 있음.
      • 각 정보들은 RDB에 저장하고, 순서 정보만 NoSQL에 넣으면 될 듯.
    • 프론트가 그룹 A를 누르면, 앨범 리스트를 다랄고 요청 보냄. 백엔드는 NoSQL 바라보고 리스트 순서를 가져옴. RDB를 바라볼 수 있는 메타 정보(id라던가)로 요청해야 RDB에서 정보를 가져온다.
      • NoSQL → RDB 순서로 진행.
      • NoSQL은 순서 바뀌는 것만 처리하면 됨. 나머지 정보들이 필요할 때만 RDB에 요청.
    • 프론트에서 삭제 요청을 보내면, 전체를 업데이트하는게 백엔드에서 편하겠다고 생각함. (그룹 전체를 덮어씌우면 좋을듯)
    • 위의 내용을 편법이라고 생각하면 안됨. 사용자에게 자유도를 줬으니 구조가 이렇게 되는게 당연함.

  • Elastic Search?

    • 검색으로 쓰거나 DB로 쓴다. 검색을 좀 더 쉽게할 수 있는 DBMS의 한 종류라고 보면 된다.
    • 이걸 사용할거면, 검색에 관련된 데이터들을 Elastic Search에 다 넣어 두고, 검색할 때 사용한다.
    • 로그를 넣고, 키바나?를 모니터링한다. 카프카에서 처리해 검색하긴 한다.
    • db가 MySQL, NoSQL에다가 추가로 Elastic Search를 추가하긴 너무 큼. 우리 플젝에서 쓸 이유는 로그 모니터링 빼고는 없어 보인다. 이 프로젝트는 MySQL로만 해도 버티긴 할듯.
    • 검색에 그룹, 앨범, 게시글 모든 것을 검색하는 게 아니라 해시태그만 검색하기 때문에 안써도 괜찮을 듯.

  • 해시태그 질문

    • 첫 번째 : 포스트를 수정할 때마다 해시태그를 다 지우고 덮어씌우기로 했다.

      • 게시글 수정에서 해시태그를 지웠을 때, 해당 해시태그를 찾는 작업이 오래걸리고 어려울 것 같아 레코드를 새로 생성.

      • #A, #B, #C를 달았을 때, 게시글 수정에서 #A를 #D로 바꿈. → #A, #B, #C를 다 날리고, #D, #B, #C를 모두 추가.

      • 내용을 쓰면서 해시태그를 수정하니까, 어쩔 수 없겠다.

      • 해시태그 테이블이 엄청나게 늘어날 듯? 수정할 때마다 그만큼 추가된다. 이 구조가 좋을지는 고민해봐야 할듯.

    • 두 번째 의견 : 기존 해시태그 내용이 같으면 재활용할 수 있도록, hastag와 post 사이의 관계 테이블을 하나 더 만들어둔다.
      • 해시태그 테이블 자체는 가볍게 가져갈 수 있다.
      • 앞단에 메타테이블을 둔다는 의미. 이 방법이 좋아 보임.
    • 멘토님 의견 :

      • 메타테이블 사용하는 대신에 아래와 같은 컬럼을 둬서, 얘만 가져오면 현재 원래 뭐있었는지 알 수 있음. 여기에 업데이트 치고, hastag 테이블에 갱신도 하면 될듯. 사라진거 flag 처리하고, 추가된 거만 레코드로 삽입해라. ➡ 1. 중복도 줄이고, 2. 바뀐거만 업데이트 쳐주는 함수가 있으니, 아래 컬럼 값을 가져와 적용해라.

      • 아래 사진처럼 바뀐 dto의 e를 원래 기존 model의 d만 e로 바꿔주는 함수가 있을거다.

  • 다음주 19일 금요일 20시에 멘토링 진행.