GitLab은 클라이언트 상태 관리 솔루션으로 Apollo와 Pinia 두 가지를 지원합니다. 둘 중 무엇을 주 상태 관리자로 선택할지 판단하기는 간단하지 않습니다. 이 페이지에서는 그 선택에 대한 일반적인 지침을 제공합니다.

GitLab 코드베이스에서 Vuex를 보게 될 수도 있습니다. Vuex는 GitLab에서 사용 중단되었으며 새 Vuex 스토어를 만들어서는 안 됩니다. 애플리케이션에 Vuex 스토어가 있다면 마이그레이션을 검토합니다.

상태(state)와 데이터(data)의 차이#

데이터는 사용자가 상호 작용하는 정보입니다. 대개 외부 요청(GraphQL 또는 REST)이나 페이지 자체에서 옵니다.

상태는 사용자 또는 시스템 상호 작용에 대한 정보를 저장합니다. 예를 들어 isLoading, isFormVisible 같은 플래그는 모두 상태에 해당합니다.

상태 관리는 상태와 데이터 양쪽을 다루는 데 사용할 수 있습니다.

상태 관리의 필요성 판단#

애플리케이션에서는 표준 Vue 데이터 흐름을 먼저 사용하는 편이 좋습니다. 컴포넌트가 로컬 상태를 정의하고 props로 내려보내며 이벤트로 변경하는 방식입니다.

그러나 상태를 정의한 컴포넌트의 직계 자손이 아닌 여러 컴포넌트가 상태를 공유하는 복잡한 경우에는 이 방식만으로는 충분하지 않을 수 있습니다. 해당 상태를 애플리케이션의 루트로 끌어올릴 수도 있지만, 그러면 루트 컴포넌트가 한꺼번에 너무 많은 일을 하게 되어 결국 비대해집니다.

이러한 복잡성을 다루려면 상태 관리 솔루션을 사용할 수 있습니다. 아래 섹션이 선택에 도움이 됩니다. 그래도 판단이 서지 않는다면 Pinia보다 Apollo를 먼저 고려합니다.

Apollo#

GraphQL API의 주 인터페이스인 Apollo는 클라이언트 측 상태 관리자로도 사용할 수 있습니다. GraphQL과 Apollo에 대해 자세히 알아봅니다.

강점#

• GraphQL 요청으로 받은 데이터를 다루기에 좋으며, 데이터 정규화를 기본으로 제공합니다.
• GraphQL을 사용할 수 없을 때 REST API 데이터를 캐시할 수 있습니다.
• 쿼리를 GraphQL 스키마에 대해 정적으로 검증합니다.

약점#

• 클라이언트 상태 관리 측면에서는 Pinia보다 복잡하고 손이 많이 갑니다.
• Apollo DevTools: 상당수 페이지에서 제대로 동작하지 않아 Apollo Client 오류를 추적하기 어렵습니다.

Apollo를 선택하는 경우#

• GraphQL API에 의존하는 경우
• 다음과 같은 Apollo 고유 기능이 필요한 경우
  • 파라미터화된 캐시, 캐시 무효화
  • 폴링
  • Stale While Revalidate
  • 실시간 업데이트
  • 기타

Pinia#

Pinia는 Vue가 권장하는 클라이언트 측 상태 관리 도구입니다. GitLab의 Pinia 사용에 대해 자세히 알아봅니다.

강점#

• 단순하면서도 견고합니다
• Pinia 사이트 기준 약 1.5kb로 가볍습니다
• 내부적으로 Vue 반응성을 사용하며 API가 Vuex와 비슷합니다
• 디버깅이 쉽습니다

약점#

• 고급 요청 처리(데이터 정규화, 폴링, 캐싱 등)를 기본으로 제공하지 않습니다
• 지침 없이 사용하면 Vuex와 같은 함정(비대해진 스토어)에 빠질 수 있습니다

다음 중 하나에 해당하면 Pinia를 선택#

• Vue 애플리케이션 상태 중 클라이언트 측 상태의 비중이 큰 경우
• Vuex 에서의 마이그레이션이 우선순위가 높은 경우
• 애플리케이션이 주로 GraphQL API에 의존하지 않고 가까운 시일 내에 GraphQL API로 마이그레이션할 계획도 없는 경우

Pinia와 Apollo 함께 사용하기#

애플리케이션에서는 Apollo 나 Pinia 중 하나만 상태 관리자로 선택하기를 권장합니다. 다음과 같은 이유로 둘을 함께 사용하는 방식은 권장하지 않습니다.

• Pinia와 Apollo는 모두 전역 스토어이므로, 책임이 나뉘고 진실 공급원이 둘이 됩니다.
• 사고 모델의 차이가 있습니다. Apollo는 구성 기반이지만 Pinia는 그렇지 않습니다. 두 사고 모델을 오가는 일은 번거롭고 오류가 생기기 쉽습니다.
• 두 방식의 단점을 모두 떠안게 됩니다.

다만 두 솔루션의 장점을 각각 얻기 위해 함께 사용해도 괜찮은 경우가 있습니다.

• 클라이언트 측 상태의 비중이 커서 Pinia로 관리하는 편이 가장 나은 경우입니다.
• 도메인 특성상 컴포넌트 안에서 응집도 높은 GraphQL 요청을 위해 Apollo가 필요한 경우입니다.

Apollo와 Pinia를 함께 사용해야 한다면 다음 규칙을 따릅니다.

• Pinia 스토어에서는 Apollo Client를 절대 사용하지 않습니다. Apollo Client는 Vue 컴포넌트나 컴포저블 안에서만 사용해야 합니다.
• Apollo와 Pinia 사이에서 데이터를 동기화하지 않습니다.
• 요청에 대한 진실 공급원은 하나만 두어야 합니다.

Pinia가 있는 기존 앱에 Apollo 추가하기#

다음 두 조건을 모두 만족하면 기존 Pinia 상태와 함께 컴포넌트에서 Apollo 데이터 관리를 사용할 수 있습니다.

• GraphQL에서 오는 데이터를 다루어야 하는 경우
• 마이그레이션 비용이 커서 Pinia에서 Apollo로 옮길 수 없는 경우

클라이언트 상태(GraphQL 또는 REST 데이터와는 다릅니다)를 Apollo와 Pinia로 동시에 관리하려 하지 않습니다. 이런 관리가 필요하다면 Pinia에서 Apollo로 마이그레이션하는 방안을 검토합니다. Pinia 스토어 안에서 Apollo를 사용하지 않습니다.

Apollo가 있는 기존 앱에 Pinia 추가하기#

먼저 클라이언트 측 상태 관리에 Apollo를 사용하는 방안을 충분히 검토합니다. 다만 다음이 모두 해당한다면 이 클라이언트 측 상태를 관리하는 데는 Apollo가 최선의 도구가 아닐 수 있습니다.

• 클라이언트 측 상태의 비중이 커서 Apollo의 복잡성 때문에 구현 비용이 높은 경우입니다.
• 클라이언트 측 상태를 Apollo가 관리하는 GraphQL API 데이터와 깔끔하게 분리할 수 있는 경우입니다.

Apollo와 함께 사용되는 Vuex#

Vuex는 GitLab에서 사용 중단되었으므로 위 지침에 따라 Apollo 또는 Pinia를 주 상태 관리자로 선택합니다. 해당하는 마이그레이션 가이드를 따릅니다: Apollo 또는 Pinia. 기존 Vuex 스토어 위에 새 Pinia 스토어를 추가하지 않고 먼저 마이그레이션합니다.