강준규 튜터님 SA 평가 및 보충
•
오늘 멘토링 받은것
1.
엘라스틱서치
→ 구체적인 기능과 예시를 들고왔으면 쓰라고 했을텐데 그렇지 않으면 애매하다, 억지로 쓰는 이유를 정말 구체적으로 만드는게 좋을 거 같다
Q.앨라스틱서치를 쓸만큼의 데이터를 어떻게 구하지 그걸 어떻게 만들지
2.
검색이나 인덱스 걸기
→ 엘라스틱서치 무조건 좋다
3.
잘쓰고 못쓰고보다 쓰고 안쓰고가 더 중요할 때가 있다
→ 면접관한테 이력서를 보여주려면 억지로라도 쓰는게 좋다고 생각한다(뭐라도 눈에 띄자)
4.
구체적으로 뭘 할지를 정하고 가라
→ 결제할 페이지가 넘어갈때 데이터가 뭐가 넘어가야할지 구체적으로 생각해봐라 나중에 그게 구현이 불가능하다고 밝혀지면? 힘들다
•
AWS배포는 무조건
•
Thymeleaf & Vue & React
◦
처음 배우기 시작 할 때는 ajax/thymeleaf 가 배우기에 빠르긴 하다.
◦
Vue 문법이 Thymeleaf 스럽다 ⇒ 참조 할 탬플릿이 많아 작업에 용이 할 수 있음.
▪
⇒장기적 관점에서의 시간 절약
◦
Thymeleaf로 진행을 할 거면 restApi에 최대한 무게를 싣는다.
◦
최대한 시간을 절약 할 수 있는 방안으로 택해라.
◦
소켓을 열면 Client 라이브러리는 Vue 나 React에 붙이기가 더 쉬울 것
•
기술들 간의 특징
◦
MongoDb, Redis → 키를 알고 할 때 검색 빠름, value값이 클 때도 좋음
◦
어떠한 기능을 구현하려는데 필요한 특별한 기능이 있지 않는 한 MySQL을 사용
•
기술별 사용에 대한 구체적인 이유
◦
사용해야만 한다면 좋은 살을 가져다 붙이자.
◦
ex) Q. 왜 JAVA 21 버전이 있는데 17버전을 사용했는지?
▪
A. 공부할 입장이고 17버전이 나온지 한참 돼서 레퍼런스가 많아서 좋았다
•
채팅에 Redis 조합
◦
채팅 DB를 Redis로 두었을 때 → 로그아웃이나 컴퓨터를 끄면 날아간다는 소리가 있는데
▪
서비스를 내렸을 때 데이터들이 날아간다
▪
채팅 서비스는 영속적이어야 한다.
•
⇒ 현 구상대로 짧은 유지기간 후 데이터를 날려버리는 건 아쉽다.
구상 -
▪
꺼낸 데이터는 Redis에 넣고 조회 요청이 오면 Redis에서 먼저 찾고 아니면 몽고디비
▪
Redis데이터는 만료시간 2시간 이런식으로 구현
▪
채팅이 오가는 동안의 데이터는 Redis에 갱신, 수정성능도 괜찮다.
문제 : 채팅은 구현시 사람들이 채팅방에 입장했을때 내용이 빠르게 조회되길 원하기에 사용하려는 것 ⇒ 영속 저장소로는 절대 쓸 수 없음
▪
MongoDB가 괜찮은 방안이 될 수 있다.
•
튜터님의 TMI “레디스를 쓰면 멍청한 짓을 많이 하게됨”
a. 입사 후 이벤트 작업에 Redis를 이용
b. 레디스에서 조회를 먼저 하고 db에 반영하고 레디스에 카운트를 올림
c. 참여여부 선착순이내인지 여부
문제 : Redis 조회를 하고 DB를 한번 갔다오는 순간 Redis의 장점이었던 속도는 무용지물
⇒ 레디스 먼저 조회하고 카운트 올리고 DB에 넣었어야 한다
⇒ 시행착오를 할 수 있는 기회를 벌어준다.
•
시나리오에 대한 보충
◦
“채팅 끝났을시 어떤 api로 채팅 내역을 영속화 할 것이다”, “주문기록 테이블 링크를 건다” 등등 상세하게
◦
엣지케이스를 시나리오 단계마다 따져보기
◦
핵심기능들은 api명세랑 erd도 포함된 시나리오 작성
◦
리뷰 선택지 정확히 정하기
•
역할 분담에 있어 두서없이 다 달려들지 말고 구분을 명확하게, 또 진득하게
◦
⇒ 추후에 의견을 나눌 때 서로에게 피드백을 받는다.
•
숙제: 멘토링 결과 다음 주까지 해올 일
◦
팀 전체 (리더와 부리더님께서 필두로 정리해 주세요.)
▪
react/vue/ajax+thymeleaf 리서치하기 (제일 쉽고 시간 짧게 걸릴 것 으로)
▪
구체화된 시나리오 작성
▪
한 명이 조사 한 후 사용 할 구체적으로 기획해 가져온다.
•
추후에 회의를 통해 의견을 나누거나 피드백을 받는다.
▪
당연하지만 중요한 건 정리를 잘 해놓는다
