•
2분 : 기획 (나아가고자 하는 방향성의 아키텍처 그림)
•
1분 : MVP 주요 작업물
•
2분 30초 : 기술적 의사 결정 1,2개
•
1분 30초 : 추후 개발 및 기술적인 도전 계획
•
3분 : 튜터님 질문 10문제 중 2가지 선정하여 답변 진행
1.
기획 : 탑스터에 대한 설명, 우리가 탑스터를 어떻게 진화(?) 시켰는지!
2.
mvp : 우리 탑스터 등록 하는 것을 보여주면 될까요??
3.
기술적 의사 결정 : 캐싱 기능(캐싱 전/후), OpenAPI 서비스 추상화 했던 것
4.
추후 개발 및 기술적인 도전 계획 : 팔로우 기능 & 알림 기능
(여기서 기술적 의사 결정을 하고 있다 (SSE or kafka) 배포할 때 도커의 메모리 이슈)
5.
튜터님 질문 2가지!
Q.스포티 파이 Open API라고 되어있는데, 스포티 파이 Open API는 어떤 API를 어떻게 사용하는 것인지 궁금합니다.
A. Spotify library를 사용해서 Accesstoken을 받아왔습니다.
앨범 검색을 위해 Spotify의 Search API를 사용했습니다. 이때는 Spotify의 library를 사용하지 않고, RestTemplate으로 구현했습니다. RestTemplate요청을 보내고, 우리 프로덕션에 맞게 JSON데이터를 DTO로 매핑 시켜 사용했습니다.
Q. 노션에 트러블 슈팅 페이지가 있던데, 기억에 남는 트러블 슈팅은 무엇이었나요?
A. 종속된 Entity의 의 Service는 상위의 Serivce를 field로 사용하면 안된다. → Service 개편
매니아 DB를 사용하는데 속도가 너무 느리고 자주터지고 데이터가 많지 않아 스포티파이 API를 사용하려 했고
기존 AlbumService에서는 갈아 끼워도 영향을 받고 싶지 않아서 추상화를 활용해서 작업을 했다.
maniadb서버가 자주 터졌잖아요 만약에 이런식으로 spotify가 지금은 primary인데, primary가 터지면 바로 두번재 maniadb를 쓸 수 있다.
A반B반 |
1, 스포티 파이 Open API라고 되어있는데, 스포티 파이 Open API는 어떤 API를 어떻게 사용하는 것인지 궁금합니다.
2. ERD에서 유저와 댓글 테이블이 1:1로 되어 있는데 유저는 댓글을 하나만 작성할 수 있다는 의미로 설계하신 건지 궁금합니다.
3. MailController의 MailRegister, MailRegister의 JavaMailSender만 필드 주입으로 의존성을 주입하셨는데 확인부탁드립니다.
4. 회원수정 url이 [PATCH]'api/v1/users/update'로 하셨는데, http method에 수정의 의미가 있으므로 [PATCH]'api/v1/users' 좋아보입니다.
5. 앨범 테이블의 앨범표지 컬럼(image)는 앨범표지 이미지 파일 경로인가요? 컬럼며이 더 구체적이었으면 좋겠습니다.
A반B반 |
1. 노션에 트러블 슈팅 페이지가 있던데, 기억에 남는 트러블 슈팅은 무엇이었나요?
2. 추가하고 싶은 기술에 quertdsl이 있던데, 소스에는 적용되지 않은 것 같습니다. 어떤 논의가 있었나요?
3. 클래스명이 소문자로 시작합니다. 실수 같은데 수정부탁드립니다. ex) getUserRes
4. 패키지명이 스네이크 케이스로 되어 있는데 카멜케이스로 하는 것이 관례입니다. ex) open_api, topster_album
5. 스포티파이 API를 사용하면서 어려웠떤 점이 있다면 무엇인가요?
