KANNA 알림 기판을 지탱하는Firestore라면

KANNA 제가 개발해 드릴게요oubakiou.
알다크의 기술 창고에 대해
https://zenn.dev/aldagram/articles/a44f041eedf5ef
그러나 건드린 대로 KANNA의 백엔드 GraphiQL 서버에서 이동Ruby on Rails의 API 모드과GraphQL Ruby의 조합을 사용하고 있다.
이 GraphiQL 서버는 주로 MySQL을 처리하지만 높은 Write 부하의 일부 기능을 발생시킨다. 구체적으로 말하면 채팅 기능과 알림 기초(Push 알림, 메일 알림, 데스크톱 알림, 응용 내 알림을 통일적으로 처리하는 API)Firestore와 Cloud Functions이다.

Rails는 GraphiQL의 Mutation을 통해 추가 보고 등 KANNA에서 알림이 발생하는 다양한 동작을 처리하고, 알림push 알림 등은 Rails로부터 Cloud Function(TS)상의 알림 API를 요청한다.그리고 의뢰를 받은 functions는Firestore의 알림 대기열에 표를 추가합니다.

(Built with Firebase)
알림 대기열에 표가 추가되면 촉발 표를 바탕으로 실제 발송 처리(Push 알림, 메일 알림)를 하는 일련의 절차다.
또한 알림 디스크가 제공하는 기능 중 프로그램 내의 알림 표시와 데스크톱 알림에 대해 브라우저와 프로그램은 Rails와functions 등 백엔드를 통해Firestore를 직접 읽지 않습니다.이는 RDB상 데이터를 기반으로 한 복잡한 권한 검사에 관련된 표 제작과 달리 파이어스토어다.rule만 권한을 검사할 수 있는 기능이기 때문에 실현되었습니다.
이처럼 안정적인 KANNA(그리고 가격이 저렴)가 지지하는 최고의 Firestore는 약점이 없는 것이 아니다.
1. GraphiQL 또는 gRPC와 같은 유형의 지원은 표준으로 제공되지 않음
표준에 KANNA 전단에서 사용하는 React(Next.js)와 ReactNative 등 TypeScript 고객은 Firestore의 유형 지원을 쉽게 처리할 수 없습니다.파이어스토어가 워낙 패턴이 없는 DB라는 것은 자연스러운 일이지만, 개인도 패턴을 설정할 수 있는 옵션 기능과 Hasura 같은 간단한 솔루션을 원하고 있다.
기준이 없다면 스스로 해결할 필요가 있다

// Firestoreドキュメントから取得したオブジェクトを元にインスタンスを生成して返す
export const fromData = (
  data: unknown
): Notification | undefined => {
  if (!dataIsNotificationData(data)) throw new Error('unknown NotificationData')

  const createdAt = fromUnknownTimestamp(data.createdAt)
  if (!createdAt) {
    throw new Error('unknown NotificationData.createdAt')
  }

  return new Notification({
		firebaseUid: data.firebaseuid
    createdAt: createdAt
  })
}

// type guard
export const dataIsNotificationData = (
  data: unknown
): data is NotificationData => {
  const d = data as NotificationData
  if (typeof d?.firebaseUid !== 'string') return false
  return true
}
export type NotificationData = ReturnType<Notification['toHash']>

// entity
export class Notification {
  readonly firebaseUid: string
  readonly createdAt: KNDate // Firestoreの生タイムスタンプとjsのdateを扱う独自の日付クラス

  // 各種メソッド中略
  getUnreadCount = (): number => this.getUnreadMessages().listLength

	// Firestoreに保存する形式でオブジェクトを生成して返す
  toData = <OT>(dateToOuterTimestamp: (date: Date) => OT) => ({
    firebaseUid: this.firebaseUid,
	  createdAt: dateToOuterTimestamp(this.createdAt.date),
  })
}

이런 코드(간략화된 인상)가 쓰여져 있고, npm로 포장된 웹판 KANNA, 응용판 KANNA, 터치 알림 디스크 Firestore의 3개 창고 간에 공유되는 것이 현황이다.
앞으로 Firestore 이외의 어디로 옮길 수 있는지를 감안하면 npm 포장에는 포장하다와서류 가방에 의존하지 않는다고 쓰여 있어 여분의 여분의 부분이 있지만 뼈가 부러질 수 있다.
(말은 그렇지만 2022 현재라면 주변의 인터페이스를 생성/보존withConverter과 일치시키는 것이 좋다)
2. firestore.rule의 기술은 직관적이지 않아 이해하기 어렵다
클라이언트로부터Firestore에 직접 접근할 때의 권한과 검증에 관해서는 JavaScript 바람 DSL로 Firestore를 진행합니다.rule 파일에 써야 하는데 이건 읽기 어렵고 쓰기 어려울 것 같아요.
특히 Dcoment 내 Arrray(Doctoment의 Collection이 아닌)의 발리 날을 묘사할 때 이런 글씨는 상당히 번거롭다.
게다가 파이어스토어가 워낙 패턴을 갖추지 못한 DB여서 자연스러운 일이지만, 1에서 패턴을 기술한 바탕에 명확한 발리일 규칙이라도 스스로 기술해야 하는 불모지였다.
3. 전체 텍스트 검색 기능을 제공하지 않음
Firestore 자체는 전체 텍스트 검색 기능을 제공하지 않습니다.N-Gram 색인을 직접 만들어 그걸 이용하는 기법이 없는 것도 아니지만, 문서 외부 서비스를 이용하는 것을 추천한다.
현대의 MySQL(이전과 달리)은 표준 전문 검색을 할 수 있어 사용이 매우 가볍고 비교하면Firestore도 원할 것이다.
또 KANNA에서는 채팅의 검색 기능Elastic Cloud을 사용했다(ElasticSearch).
4. 데이터 설계는 RDB와 다른 기술 노하우가 필요하다
1·2·3과 비교하면 어쩔 수 없는 부분이지만, RDB와 각 부분에서 확연히 다르기 때문에 독특한 기술 노하우가 필요하다.예를 들어, 데이터 설계에 영향을 미치는 가장 유명한 제한 사항은 "한 문서에 대해 1초에 한 번만 업데이트할 수 있습니다"입니다.
또 기본적으로 희소식인 파이어스토어는 읽기 수와 Write 수 등에 따른 명랑회계로, RDB에 비해 설계 단계에서 상당히 세밀한 운영 비용을 산출할 수 있다.
그리고 운행 원가를 낮추려면 RDB가 말하는 비정규화된 수법도 선택항목에 들어갈 수 있지만 이렇게 하면 데이터 통합성을 위한 추가 비용이 코드에서 발생하는 등 장래의 확장성에 영향을 미칠 수 있다.
그 결과 "이 기능의 운영 원가를 10분의 1로 낮추기 위해 확장성을 희생했는데 장래에 총계 지불할 수 있겠는가"라며 "'조기 최적화'가 아닌가.이렇게 뜻을 결정하는 장면은 자주 만난다.
불확실성을 담은 매우 어려운 문제다.(유쾌한 질문도 있다)
에서는 KANNA를 지원하는 Firestore에 대해 설명합니다.
이번에 단점을 열거했을 뿐이지만 불만이라기보다는 향후 업데이트를 기대하는 것이어서 용도가 맞으면 대체할 수 있는 것이 없을 정도로 훌륭한 서비스라고 생각한다.
직원 모집
알다크는 건축 업계를 함께 바꾸고 싶은 엔지니어를 적극적으로 채용하고 있다!
https://herp.careers/v1/aldagram0508