[디깅 뮤직 13편] 개발 진행 상황

원래 국내 음악 DB를 쓰려고 했으나..

응답에 너무 시간이 오래 걸리고 검색 최적화 문제로 다른 API를 알아보기로 했다.

스트리밍 서비스에서 제공하는 API는 spotify 정도가 있었다.

일단 region을 한국으로 설정할 수 있고 가장 많은 메타데이터를 보유하고 있었고,

유명한 사이트인 만큼 퀄이 좋았다.

 

그리고 원래 상업적 사용이 안되는 줄 알고 있었는데 

non-streaming 은 괜찮다고 한다.

 

Spotify API는 client credentials flow라고 access token을 발급받아서 call하는 구조다.

왜?

어차피 토큰도 백에서 받고 데이터도 백에서 받으면 이게 무슨 소용이람.?

한 시간마다 계속 발급 받아야 되는데..

하여튼 중요한 점은 API 호출할 때 백엔드에서 해야된다는 걸 새로 알게 되었다는 점이다

 

버블은 그냥 페이지에서 call하면 프론트에서 call하는 거라고 함

 

 

근데 spotify에서는 가사를 제공을 안 한다.

해외의 스트리밍 서비스들은 가사를 보통 가사 제공 업체로부터 받아서 사용하는 것 같다.

우리나라 서비스들은 주로 음반사나 유통사한테 직접 받는 걸로 보인다.

 

그래서 어떻게 해결을 할까

고민을 하다가 일단 가사제공업체 API를 쓰기로 결정했다.

musixmatch API를 쓸 생각인데

여기는 catalog feed라고 DB를 주기적으로 통채로 보내주는 방식도 있었다. 이런 모델도 있다니

 

저건 부담스럽고 그냥 API를 쓸려고 알아봤더니 직접 상의를 해서 계약해야 되는 모양이다.

 

rapid API라고 api 편하게 테스트해보고 쓸 수 있게 만들어놓은 마켓플레이스가 있어서 써봤다.

통일된 id로 get하는 게 없어서 matcher.lyrics.get을 써야 하는데

생각보다 정확하게 검색해야 한다.

fuzzy search나 대소문자 정도는 보정해줄 줄 알았는데 아님.