-
보안
- 장점: Firebase API를 사용하려면 Firebase 애플리케이션과 관련된 인증 키가 필요합니다. SSR 방식으로 진행할 때 서버가 이 키를 이용하여 데이터에 대한 CRUD를 수행하므로, 클라이언트는 결과값만 받아 인증 키가 노출되지 않습니다.
-
데이터를 사전에 불러오기
- 장점: SSR 방식을 사용하면 필요한 데이터를 사전에 가져오기 때문에 첫 페이지 로드 시 모든 정보를 사용자에게 보여줄 수 있습니다.
-
서버의 리소스 사용 증가
- 단점: SSR은 신규 요청이 발생할 때마다 새롭게 렌더링을 진행해야 하고, 해당 페이지에서 Firebase API를 사용할 경우 매번 새로운 요청을 보내고 렌더링을 해야하는 경우가 있어 서버 리소스 사용량이 증가할 수 있습니다.
-
개발 복잡성
- 단점: 서버 측에서 렌더링을 진행할 때 클라이언트 측에서 렌더링할 때보다 조금 더 개발하기 어려울 수 있습니다.
-
서버의 리소스 사용 감소
- 장점: 클라이언트에서 렌더링되고 Firebase API와의 통신도 개별 클라이언트에서 이루어지기 때문에 SSR 방식 대비 서버 리소스 사용량이 감소됩니다.
-
동적 컨텐츠
- 장점: 사용자의 요청에 따라 필요한 데이터를 가져와 동적으로 컨텐츠를 변경하기가 상대적으로 쉽습니다.
-
초기 로딩 시간
- 단점: 모든 스크립트를 불러온 다음 실행한 후 화면이 렌더링되기 때문에 초기에 사용자가 느끼는 로딩 시간이 길어질 수 있습니다.
-
보안
- 단점: 클라이언트 측에서 직접 Firebase API를 호출하면 API 키가 노출되어 보안 취약점이 발생할 수 있는 위험이 존재합니다.
참고: 선택된 방식은 프로젝트의 특성과 요구 사항에 따라 달라질 수 있습니다. 보안과 초기 로딩 시간 등의 중요한 측면을 고려하여 결정하는 것이 중요합니다.