なぜサーバーモデルの前にクライアントモデルを更新するのですか？
私が見たチュートリアルでは、クライアントでデータが変更されると（TODOがTODOリストに追加される可能性があります）、クライアント側モデル（および多くの場合UI）が最初に更新され、次にサーバーが呼び出されてその変更が保持されます。エラーや失敗の可能性があるため、これは私を困惑させます（その場合、クライアントに通知し、データモデル/ UIの変更を元に戻す必要があります）。
最初にサーバーを更新してから、クライアントデータモデル/ UIを更新するのが最善ですか、またはその逆ですか？
一般に、最初にサーバーを更新してから、サーバーが正常に応答したときにUIを更新するのが最も簡単です。
これにより、UIを更新したが、サーバーの更新が失敗した場合の処理を回避できます。
ただし、UIに結果が表示される前に、ユーザーはサーバー要求が完了するのを待つ必要があります。
どちらの方法が最適かは、優先順位とアプリケーションによって異なります。一部のアプリケーションでは、UIを再度更新することで、サーバーの更新が失敗した場合の処理も簡単です（もう少し作業が必要です）。一部のアプリケーションでは、これは非常に複雑になり、ユーザーが誤った決定を下し、イライラしたり、危険な結果を招いたりする可能性があります。
たとえば、サーバーが確認する前に薬が注文されたことをiPadで医師に示します。短時間のネットワーク停止やその他の問題のために薬が実際に注文されなかった場合は、患者に危害を加えた可能性があります。医者はiPadを置き、仕事が終わったと思って立ち去ることがあります。
この場合、UIでは遅延または保留中のステータスのいずれかが順番に表示されます。保留中のステータスの方が良いように聞こえますが、場合によっては安全上の理由から、遅延と正式な確認の方が適しています。それはユーザーエクスペリエンスデザインの問題です。
私の経験から別の分野である証券取引は、そうでないときに何かが行われていることをユーザーに伝えてはならない分野です。トレーダーは、ステータスインジケーターを使用して複雑なUIを監視することに慣れており、ほとんどの場合、遅延を嫌います。ただし、この場合、必要なステータスインジケーターと動的UIにより、サーバーが確認するのを待つだけでなく、より多くのスコープを追加できます。
全体として、答えは技術的なものではありません。この場合、開発のための予算とともに、実際に推進するのはユーザーエクスペリエンスです。