백엔드 개발 포트폴리오 | 노래 공유 사이트
내일배움캠프 4기 웹 개발 과정 Spring 트랙 수료생 최종 프로젝트 ‘오들’을 소개합니다.
Aug 17, 2023
오늘 뭐 들었니?
오늘 하루의 시작과 끝에 느꼈던 감정과 생각을 노래와 함께 공유 해보세요.
🔎 주요 기능
- 멜론 사이트의 노래 정보 크롤링 및 DB 저장 (음원X)
- 게시글 작성 시 DB에 저장된 노래를 검색하여 첨부
- 게시글 작성 시 태그를 첨부하여 해당 태그를 키워드로 게시물 검색
- 원하는 유저를 팔로우 및 팔로우/팔로잉 리스트 확인
- 좋아하는 게시물 및 댓글에 좋아요 및 좋아요 취소
- 유저의 프로필 페이지에서 프로필 및 유저의 게시글 목록 확인
- 지난 24시간 동안 작성된 게시물 기준으로, 많이 작성된 노래 순위 확인
🛠️ 아키텍처
🔧기술적 의사 결정
멜론 크롤링
- 음악 정보를 가져오고 싶어서 크롤링과 오픈 api를 고민해보았다
- 크롤링: 장점과 단점
- 장점: 원하는 정보만 가져올 수 있다 직접 데이터 관리를 할 수 있다
- 단점: 리소스가 많이 들어간다 개발시간이 길어진다
- 오픈 API: 장점과 단점
- 장점: 사이트에서 제공하는 데이터를 쉽게 가져와 쓸 수 있다 비용과 시간을 줄일 수 있다
- 단점:
- 제공하는 데이터만을 사용할 수 있다
- 크롤링
- 대량의 데이터를 다루는 경험을 통해 많은 것을 배워가고 싶어서 크롤링을 선택했습니다.
데이터 처리방식 동기(Synchronous) & 비동기(Asynchronous)
- 프론트 구현하던 도중 데이터 처리방식을 결정
- 동기 처리방식과 비동기 처리방식
- 동기 / 비동기 장단점
- 동기 처리방식 : 요청이 들어왔을 때 응답이 완료된 후에야 다음 응답을 시작 할 수 있다.
- 구현이 비동기보다 간단하고 직관적이지만 응답 속도가 느리다.
- 비동기 처리방식 : 요청이 들어왔을 때 응답 상태와 상관없이 다음 동작을 수행 할 수 있다.
- 구현이 동기보다 복잡하지만 응답 속도가 빠르다.
- 비동기 처리방식 선택
- 참고하기 위한 대부분의 강의자료 모두 ajax를 사용하는 비동기 처리방식을 사용하였고, 구현을 해두기만하면 보다 응답 속도가 빠른 비동기 처리방식이 효율적이라고 판단되었다.
좋아요/좋아요 취소
- 하나의 버튼을 누를 때 좋아요와 좋아요 취소 기능을 어떻게 구현할지
- api를 하나로 할지 두개로 나눌지에 대한 선택
- 각각의 장단점
- api 하나 : 코드의 간결성과 API 사용의 편의성 좋음. 하나의 API로 모든 작업을 처리 할 수 있으므로 클라이언트는 하나의 API만 호출하면 되므로 API 사용의 편의성이 높아지며 하나로 코드를 작성시 코드 중복을 피하고 유지 보수성을 높일 수 있다. 단점으로 클라이언트는 매번 좋아요 상태를 확인하고, 현재 상태의 따라 요청을 다르게 보내야 하므로 비효율적이다. 또한 클라이언트가 API를 호출할 때 좋아요 상태를 알아야 하기 떄문에 추가적인 API 호출이 필요 할 수 있다.
- api 두개 : 좋아요와 좋아요 취소 API 각각에 대한 별도의 URL이 있으므로 클라이언트 현재 상태를 확인하지 않아도 되어서 비교적 효율적, 클라이언트가 필요한 경우 해당 API만 호출하기 때문에 추가적인 API 호출 방지 단점으로 코드의 중복 발생, 추후 유지 보수성이 저하 될 가능성이 있다. 좋아요와 좋아요 취소 API에 대한 별도의 URL이 있기 떄문에 API사용의 편의성이 떨어질 수 있다.
- api 두개를 선택했는데 그 이유는 : RESTful API 설계 규칙에 따라 자원에 대한 동작은 HTTP 메소드에 의해 결정되어야 하는데 좋아요와 좋아요 취소를 동일한 URL 경로와 HTTP 메소드를 사용하여 구현하는 것은 RESTful 하지 않다고 생각해서
태그(tagService → postService)
- TagService에서 태그 CRUD에 대한 로직을 작성했었는데 게시글에 연결시킬 때 어디서 연결을 하면 좋을지 고민을 함
- PostController나 PostService에서 해도 되고, Tag가 CRUD 기능만 있는 거면 PostService 안에서 게시글 CRUD 할 때 같이 작성하는 방법도 있음
- 각 장단점
- PostService 안에 TagService 넣으면 작성한 로직을 붙여 넣으면 돼서 간단함 하지만 Service를 과도하게 나눈 경향이 있음
- TagService 지우고 PostService 안에서 작업하면 파일이 줄고 연결에 대한 고민을 줄여줄 수 있지만, 기존에 작성했던 파일들을 조금씩 수정을 해야 한다는 단점이 있음
- 하나의 파일 안에서 끝낼 수 있어서 PostService 안에서 작성하는 것으로 선택
유저 활성화/비활성화
요구사항회원 탈퇴 기능 구현
선택지1) 회원탈퇴 시 DB 즉시 삭제
2) 계정 비활성화(Enum으로 관리) → 최종 선택🚩
각 선택지 장단점- DB 즉시 삭제의 경우
- DB에서 완전히 삭제하여, 저장 공간을 절약할 수 있음. 고객 요청 시 즉시 삭제하므로, 개인 정보 보호 관련 법에 저촉될 위험이 적음. 탈퇴 이후 계정 관리에 대한 추가적인 업무가 줄어 서비스 구현 및 유지가 간편함.
- 여러 사유로 계정을 복구 혹은 데이터 확인이 필요할 경우 어려움이 있음.
→ 장점
→ 단점
- 회원 비활성화
- DB 즉시 삭제의 장단점과 상반됨
- 축적한 데이터를 추후 데이터 분석 등에 활용 가능함
선택 사유🚩- 추후 실제 서비스를 한다고 가정하였을 때, 게시물 혹은 노래 추천 알고리즘 등 데이터를 활용하여 추가적인 서비스 보완 및 개발을 할 수 있을 것으로 사료됨.
- 유저의 실수 등 잘못된 탈퇴 요청의 가능성도 있어 민감한 이슈가 될 수 있으며, DB 즉시 삭제는 데이터 복구 및 추적에 어려움이 있어 악용되거나 유저 컴플레인이 발생할 수 있을 것으로 사료됨.
- 이후 단순 비활성화 기능이 아닌 휴면계정/블랙리스트 등 기능의 확장을 염두에 두고 있음.
📌 트러블슈팅
Redis
문제 상황자주 호출하는 API의 경우 기다리는 시간에 따라 유저 경험이 저해될 수 있음
개선점- RefreshToken을 Redis로 관리하여, AccessToken 재발급시 RefreshToken을 확인하는 절차 개선.
- 추후 Redis의 빠른 처리 속도와 캐싱 기능을 이용하여 게시물 목록 조회 등 다양한 기능에도 추가 적용하여 속도를 개선할 수 있음.
Crawling
문제 상황크롤링을 사용해서 대량의 외부 데이터를 가져온 뒤 업데이트 되는 신곡의 정보들을 수동으로 매번 가져오는 것은 효율적이지 못함
개선점- 스프링부트 @Scheduled 어노테이션을 사용
- 시간 간격과 데이터 처리량을 정하면 자동으로 원하는 데이터를 효율적으로 가져올 수 있음
Share article
Subscribe to our newsletter