TIL - Next.js&supabase에서 createClient Vs. createServerComponentClient

오늘은 Supabase와 Next.js를 함께 사용할 때의 다양한 접근 방식에대한 학습 내용을 정리해보려고 합니다. 각각의 방법에 대한 장단점과 적합한 사용 상황을 공유하겠습니다.

기본 Supabase 클라이언트 사용 (createClient)

장점:

• 간단하고 직관적인 설정: 설정이 매우 간단하고 직관적이어서 빠르게 프로젝트를 시작할 수 있습니다.
• 클라이언트 사이드에서 완전한 Supabase 기능 사용 가능: 클라이언트 사이드에서 Supabase의 모든 기능을 사용할 수 있습니다.
• onAuthStateChange를 통한 세밀한 인증 상태 관리: 인증 상태 변화를 실시간으로 관리할 수 있어 편리합니다.

단점:

• 서버 사이드 렌더링(SSR)에 최적화되어 있지 않음: 서버 사이드 렌더링에는 적합하지 않습니다.
• 클라이언트 사이드에서만 동작하므로 초기 로드 시 인증 상태 확인에 지연 발생 가능: 페이지 로드 시 인증 상태 확인이 지연될 수 있습니다.

사용 시기:

• 클라이언트 사이드 중심의 애플리케이션: 주로 클라이언트 사이드에서 작동하는 애플리케이션에 적합합니다.
• 실시간 인증 상태 변경이 중요한 경우: 실시간으로 인증 상태가 변경되는 상황에서 유용합니다.
• Next.js의 서버 컴포넌트를 사용하지 않는 프로젝트: 서버 컴포넌트를 사용하지 않는 프로젝트에 적합합니다.

createServerComponentClient 사용

장점:

• Next.js 서버 컴포넌트에 최적화: 서버 컴포넌트와 잘 맞아서 사용하기 좋습니다.
• 서버 사이드에서 안전하게 인증 상태 확인 가능: 인증 상태를 서버 사이드에서 안전하게 확인할 수 있습니다.
• 쿠키 기반 인증으로 SSR과 정적 생성(SSG)에 적합: 쿠키를 기반으로 한 인증이 SSR과 SSG에 적합합니다.

단점:

• 클라이언트 사이드 이벤트 처리가 제한적: 클라이언트 사이드 이벤트 처리가 제한적입니다.
• onAuthStateChange와 같은 세밀한 인증 이벤트 처리가 어려움: 인증 상태 변화를 세밀하게 관리하기 어렵습니다.

사용 시기:

• Server-Side Rendering(SSR)이 중요한 프로젝트: 서버 사이드 렌더링이 중요한 프로젝트에 적합합니다.
• Next.js의 서버 컴포넌트를 적극 활용하는 경우: 서버 컴포넌트를 적극적으로 사용하는 경우에 유용합니다.
• 초기 페이지 로드 성능이 중요한 애플리케이션: 페이지 로드 성능이 중요한 경우에 적합합니다.

하이브리드 접근 방식 (서버 컴포넌트 + 클라이언트 사이드 Auth Provider)

장점:

• 서버 컴포넌트의 장점과 클라이언트 사이드 인증 관리의 유연성 모두 활용: 두 가지 접근 방식의 장점을 모두 사용할 수 있습니다.
• 초기 로드 시 빠른 인증 상태 확인: 초기 로드 시 인증 상태를 빠르게 확인할 수 있습니다.
• 실시간 인증 상태 변경 처리 가능: 실시간으로 인증 상태를 관리할 수 있습니다.

단점:

• 구현이 다소 복잡: 구현이 복잡할 수 있습니다.
• 서버와 클라이언트 간 상태 동기화에 주의 필요: 서버와 클라이언트 간의 상태 동기화에 신경 써야 합니다.

사용 시기:

• SSR과 클라이언트 사이드 렌더링을 모두 활용하는 복잡한 애플리케이션: 복잡한 애플리케이션에 적합합니다.
• 초기 로드 성능과 실시간 인증 상태 관리가 모두 중요한 경우: 초기 로드 성능과 실시간 인증 상태 관리가 모두 중요한 경우에 유용합니다.
• 서버 컴포넌트와 클라이언트 컴포넌트를 혼합하여 사용하는 프로젝트: 두 가지 컴포넌트를 혼합해서 사용하는 프로젝트에 적합합니다.

결론

각 접근 방식은 고유한 장단점을 가지고 있습니다. 프로젝트의 요구사항, 개발 팀의 경험, 그리고 애플리케이션의 특성을 고려하여 가장 적합한 방법을 선택해야 합니다. 대부분의 경우, 하이브리드 접근 방식이 가장 유연하고 확장 가능한 선택이 될 수 있지만, 프로젝트의 복잡성과 필요성에 따라 더 간단한 접근 방식을 선택할 수도 있습니다.