10개 이상의 요소를 가진 Firestore -in-subscription

반응형

Firestore 및 어레이 포함 작업은 문서에 설명된 대로 최대 10개의 요소를 지원합니다. 이 제한은 이해할 수 있지만, 요청 시 1k 아이디를 받는 것을 달가워하지 않을 것 같습니다. 하지만 여러분이 멋진 Firestore 애플리케이션을 만들게 될 때, 이 제한은 여러분에게 상당한 골칫거리를 남길 수 있습니다. 특히 당신의 멋진 앱이 구독을 사용하고 있을 때요.

스포츠 앱 Teamy의 달력을 최적화하던 중 이 문제에 부딪혔을 때 간략한 맥락을 알려드리겠습니다.

• 사용자는 여러 팀의 구성원이 될 수 있으며 10개 이상일 수 있습니다.
• 달력 보기에서 날짜별로 정렬된 모든 팀의 프로그램을 볼 수 있어야 합니다.
• 프로그램에 team_id 필드가 있습니다.

MySQL과 같은 기존 관계형 데이터베이스는 관계형 user_team을 사용하고 user_id 하나만 제공하여 모든 프로그램을 검색할 수 있습니다.

 

Firestore에서 이를 달성하는 유일한 방법*은 인 오퍼레이터를 사용하여 사용자가 속한 모든 팀 ID를 제공하는 것입니다. 그런데 팀 아이디가 10개 이상이면 어떡하지?

완벽한 해결책을 모색하던 중, 몇 가지 좋은 제안들을 우연히 발견했습니다. 그러나 그들 중 누구도 파이어스토어의 가장 멋진 특징인 구독을 고려하지 않았다. 하지만 영감을 받아 해결책을 만들었습니다.

이 코드베이스에서는 Angular를 사용하므로 TypeScript로 작성되었습니다. 아래는 작동 중인 코멘트가 포함된 파일 3개입니다.

• 프로그램을 렌더링하려는 달력 페이지
• 프로그램 쿼리 로직을 위한 프로그램 서비스
• 청크 구독 논리에 대한 Firestore 서비스

CalendarPage

 

유일한 책임은 기준에 따라 프로그램을 구독하고 이 옵션을 설정하는 것입니다. 업데이트에 대한 프로그램 및 페이징이 취소되었을 때 구독을 취소하는 것입니다.

프로그램서비스

가입 프로그램에서는 Firestore 서비스의 단일 가입을 반환합니다. 구독에는 다음 속성이 필요합니다.

• chunkItems: 이 경우 teamIds
• query: teamId의 현재 청크를 수락하고 관찰 가능(여기서 Firestore 쿼리)을 반환하는 함수
• limit: 선택 사항, 결과를 제한하려면
• sort: 옵션, 비교 함수. 각 청크의 결과가 병합되므로 사용 시 병합된 결과뿐만 아니라 쿼리에서 정렬을 수행해야 합니다.

 

화덕서비스

마법이 일어나는 곳. ID는 최대 10개 항목의 청크로 분할되며 각 청크에 대해 쿼리가 적용되고 구독됩니다. 모든 청크가 결과를 반환하면 모든 결과가 병합, 정렬 및 제한된 후 다시 전달됩니다.

그것은 또한 구독자 수를 추적한다. 0이면 모든 청크의 쿼리를 등록 취소한 것입니다.