Kinetoのバックエンド

Last updated Unknown Edit Source

#pKineto

• バックエンドは比較的知識が少ないので不安

• 通信

• https://qiita.com/suin/items/00dee8bac706a6d66862

  • フロントエンドとバックエンドのリアルタイム通信の選択肢を教えて下さい

• https://cloud.google.com/solutions/mobile/mobile-app-backend-services?hl=ja#firebase-appengine-flexible

  • これの三つ目が良さげ

• 処理してFirebaseをいじくったりする元は、KubernetesかCloud Functionsかな

• https://medium.com/statuscode/cloud-functions-vs-container-engine-5c773e364ced#:~:text=With%20Kubernetes%20Engine%20you%20have,to%20the%20other%20compute%20services.

  • Cloud Functions vs Kubernetes Engine

• 今のペン同期システムが頭悪いので、もっと良い形を見つけたい

  • Kinetoのホワイトボード

    Kinetoのホワイトボード

    #pKineto #ホワイトボード ふせん 位置の変化はいつまで許す? 変化のconflictはあるかもしれん、でも上でoverrideすればいいか ...

    1/3/2023

    もできるように
  • とりあえず、一番悪いのは定期更新
  • pullじゃなくてpushであるべき

• 改良版の仕様としては、

  • 監視範囲秒数内に変化があったらpush通知を受け取る
  • 表示範囲秒数より広めに監視して、定期更新テンポより時間方向の解像度をあげる

• あと、プロトコルを決めておかないとバージョンアップ時とかが大変になる

• Firebase Realtime Database

  Firebase Realtime Database

  https://qiita.com/1amageek/items/b350ee5ef0c9b2406583 Firebase Realtime Databaseは一貫性を犠牲にすることで、可用性と分断耐性に優れたクラウドシステムである。 一貫性を犠牲にすると言っても、トランザクションの機能は提供されている。 Firebaseは緩やかな一貫性の上に成り立っている https://qiita.com/1amageek/items/64bf85ec2cf1613cf507 冗長になってしまうのは割り切る ...

  1/3/2023

  の構造を以下に書く（ここのをマスターとする）

• - devices: - - : true - items: - - type: {"sticky", "stroke", "vote"...} - frames: - : true - timeline: - - : true - frames - - itemUUID: - deviceUDID: - playingPoint: - createdDate: - content (sticky): - text: - xCoord: - yCoord: - content (stroke): - stroke: - content (counter): - diff: (差分)

• Note

  • 各フレームは、あくまでも差分しか持たない
  • ある地点までの総和とかは、クライアントで自力でとる
    • （じゃないと、過去改変が起きた時に未来のデーターも変えないといけない）
  • ただまあふせんに関しては例外かな

• 疑似同期: 0.1秒単位

• 同期: 1秒単位