이번 프로젝트를 진행하면서 백엔드와 초반에 발생했던 작은 시행착오에 대해서 이야기 해보겠습니다.
저희가 만든 서비스 RoomE에는 음악이나 도서를 내 방에 추가할 수 있는 기능이 있습니다.
음악이나 도서의 모든 정보를 DB에 전부 저장해둘 수 없기에 알라딘, 스포티파이 같은 외부 API를 호출해서 데이터를 가져와야만 합니다.
미리보기
외부 API를 프론트에서 호출하나 백엔드에서 호출하나...?
여기서 생겼던 고민은 외부 API를 프론트에서 호출하냐 백엔드에서 호출하냐였습니다.
이런 생각을 하게된 이유는 프론트에서 외부 API를 직접 호출할경우, 원하는 데이터를 얻기위해 API를 체이닝을 해야하고 이는 여러번의 호출로 인해 성능이 저하될 수 있다고 생각했기 때문입니다.
또한 프론트에서 API를 직접 호출할 경우 발생할 수 있는 보안적인 문제, API 호출 제한등의 문제 또한 발생할 수 있을 것이라고 생각했습니다.
따라서 백엔드에서 외부 API 호출 후, 클라이언트에 전달하는 방식이 나을것이라고 판단했습니다.
프론트 → 백엔드 요청 → 백엔드가 외부 API 호출 → 데이터 가공 후 프론트로 전달하는 방식
그래서 결국?
그러나 백엔드 팀은 프론트가 직접 호출하면 되는 것을 백엔드에서 굳이 한번의 과정을 더 거쳐서 데이터를 전달해주는 방식이 맞지 않는 것 같다고 말씀하였고, 이에 동의한 저희는 고민을 하다 결국 프론트에서 직접 호출해주는 방식을 따르기로 결정하였습니다.
이러한 방식을 체택한 이유
외부 API로 검색된 결과를 전부 DB에 저장할 것도 아닌데 굳이 백엔드에서 호출해서 데이터를 정제한 후 결과를 다시 프론트에게 전달해주는 것은 번거로운 방식이라는 생각에 동의하였습니다.
즉, 단순히 데이터를 저장하지않고 정제해서 다시 프론트에게 전달해줄거라면 프론트에서 API 호출 한번에 끝내는것이 효율적이기에 프론트에서 직접 처리하기로 결정하였습니다.
속도의 문제?
보통 프론트에서 외부 API를 호출하는게 일반적이지만 이번 프로젝트의 경우 여러 API를 체이닝해서 가져와야했기 때문에 서버에서 호출 후 정제된 데이터를 보내주는것이 속도적인 측면에서 빠를 것입니다.
보안적인 문제?
.env 파일에 사용하는 외부 API키들을 저장해놓는 방식으로 해결 할 수 없습니다. 그러나 서버에서 호출하는 것보다는 보안적인 부분에서 취약한 것은 사실입니다.
API호출 제한?
API 키를 다양하게 만들어 할당량이 다되었을 경우 다음 API키를 사용하는 방식으로 처리할 수 있을 것이라고 판단하였습니다.
ex) 스포티파이의 검색 API를 호출해 연관된 검색결과가 보여지는모습