
이번에 진행 중인 프로젝트에서 백엔드 분과 노션 연동에 대해 논의를 하게 되었다.
둘 다 노션 연동은 처음이었고, 노션 api를 이용한 작업이라 데이터를 어떻게 주고 받아야 할 지에 대해 논의를 하던 중 💡프론트에서 외부 api를 호출해 사용하는 것이 올바른 방법인가💡에 대한 의문이 들었다.
이전 프로젝트에서 백엔드 분들이 대략적으로 서버리스로 구현하는 상황이 아니라면, 외부 api가 필요할 때, 되도록이면 프로젝트의 서버를 거쳐서 프론트는 해당 서버와만 통신하도록 해야 한다고 말씀하셨던 것이 기억이 났지만 정확한 이유에 대해서는 몰랐기에 이번 기회에 관련된 부분을 조사했다.
일반적으로 프론트엔드와 백엔드 협업에서 외부 Open API를 사용할 때, 백엔드에서 외부 API를 호출하고 프론트엔드는 백엔드 API를 호출하는 방식이 선호된다. 이러한 접근 방식이 더 좋은 이유는 다음과 같다.
보안성 강화
프론트엔드가 외부 API를 직접 호출하면 API 키, 사용자 인증 정보 등의 민감한 정보를 클라이언트에 노출시킬 위험이 있다. 백엔드에서 외부 API를 호출하면 이러한 민감한 정보는 서버 측에만 저장되므로 보안성이 높아진다는 장점이 있다. API 키가 노출되면 오남용으로 인한 비용이 발생하거나 서비스가 차단될 수 있으므로 백엔드에서 보호하는 것이 안전하다.
통신 및 에러 관리의 중앙화
외부 API는 종종 속도 지연이나 불안정한 응답을 보일 수 있다. 백엔드에서 외부 API 호출을 관리하면 백엔드에서 직접 오류 처리 및 재시도 로직을 구현할 수 있어 프론트엔드의 복잡성을 줄일 수 있다. 이 방식으로 프론트엔드는 항상 백엔드 API로부터 동일한 형식의 응답을 받아 안정적인 개발이 가능해진다는 장점이 있다.
데이터 변환 및 로직 처리의 유연성
백엔드가 외부 API에서 데이터를 가져온 뒤 필요한 형식으로 가공하여 프론트엔드로 전달할 수 있기 때문에, 외부 API의 데이터 구조가 변경되거나 불필요한 데이터가 포함된 경우 백엔드에서 필요한 데이터만 정제하여 제공함으로써 프론트엔드의 부담을 덜고 네트워크 성능을 최적화할 수 있다.
외부 API 호출 횟수 제한 관리
많은 Open API는 호출 횟수에 제한이 있다. 백엔드에서 중앙 집중적으로 호출을 관리하면 호출 횟수를 최적화할 수 있고, 캐싱을 통해 불필요한 요청을 줄일 수도 있다. 캐싱을 통해 특정 시간 내에 동일한 요청이 있을 때 외부 API를 재호출하지 않고 기존 응답을 반환할 수 있어 효율성을 높일 수 있다는 장점이 있다.
유지보수 용이성
외부 API의 엔드포인트가 변경되거나 API 키를 교체해야 할 때 프론트엔드와 백엔드를 분리하면 유지보수가 간편해진다. 백엔드만 수정하면 되므로 프론트엔드를 재배포할 필요 없이 빠르게 대응할 수 있다는 장점이 있다.
이러한 이유들로 프론트엔드는 백엔드 API를 통해 필요한 자원을 요청하고, 백엔드는 외부 API를 호출하여 데이터를 제공하는 방식이 보다 안전하고 효율적인 협업 모델로 여겨진다.
하지만 왠지 다른 의견이라던지, 발전된 방식이 있을 수도 있을 것 같다는 생각이...!
지금까지 프로그래밍을 공부해본 결과, 모든 방식에는 장단점이 있었다.
혹시 지나가다 이 글을 보시는 모든 개발자분들의 오류정정/다른방식/기타의견 댓글을 환영합니다👩💻