同期の境界を設計する

小さなチームの集中力は有限です。ネットワーク上のやり取りを調整する時間は、取り込み失敗の説明や読みやすい表示の改善に使えなくなります。JMAPはクライアントのローカルモデルとメールボックスを保管するサービスの間に、一貫した境界を用意します。魅力は設計の明確さであり、メール開発が無条件で簡単になるという約束ではありません。

基礎は2019年公開の RFC 8620です。同じく2019年の RFC 8621は、メッセージ、メールボックス、スレッド、クライアントからの送信を含むJMAP for Mailを定義します。独自APIを推測して使うのではなく、データモデルが定義された公開標準です。

リクエストの手順より必要な仕事を記述する

JMAPはHTTPSでJSONを交換します。一つのリクエストに複数のメソッド呼び出しを含め、後の呼び出しから前の結果を参照できます。受信トレイなら、検索と、その結果の識別子に対応するデータ取得をまとめて記述できます。ただしサーバーが示す上限に従います。依存する通信往復が減れば高遅延の回線で役立つ可能性がありますが、実際の結果は処理内容と実装次第です。

開発上の利点は依存関係を明示できることです。画面に必要なプロパティと次の操作に渡す結果を表現できます。それでもページ分割、エラー処理、処理量の制限は必要です。一括処理はリクエストを整理する手段であり、ウィンドウを開くたびに全アカウントを取得する理由にはなりません。

状態を永続的なチェックポイントとして扱う

状態トークンにより、既知の時点から何が変わったかを尋ねられます。/changesは作成、更新、削除された識別子を返し、クライアントは必要なデータを取得して保存内容を更新します。プッシュ通知は状態の変更を知らせ、同期のきっかけを与えます。照合そのものを置き換えるわけではありません。

チェックポイントは実際に永続保存されたデータと一致する必要があります。応答の受信から保存までの間にクラッシュする場合も設計に含めます。要求した変更履歴をサーバーが計算できない場合はcannotCalculateChangesが返り、より広い再同期が必要です。長期間接続しなかった後の復旧も通常の機能です。

残る責任を明確にする

JMAPはサーバー間配送のSMTPを置き換えません。JMAPによるクライアントからの送信と、メール網での配送は別の仕事です。スパムの自動解決、エンドツーエンドのプライバシー、オフライン動作も自動的には得られません。オフライン対応にはローカル保存、保留操作の規則、競合処理が必要です。

対応は普遍的ではありません。機能を検出し、対応サービスを決め、必要な互換経路を残します。性能はサーバー、クライアント、処理内容によって変わります。現代のIMAPにも同期機能があり、単純な新旧比較では不十分です。

スタジオとしての教訓は、復旧を理解しやすくする契約を選ぶことです。 メールアプリの開発が難しい理由：50年の互換性をスタジオの視点で考える では受け継がれた制約を、 JMAPによるメールの現代化 では利用者の視点を説明しています。明確なサーバー通信はよりよいアプリの余地を作りますが、実際に作る責任はチームに残ります。