これらはすべて、MBaaS を検討し始めたときに役立つ質問です。私は私の経験に従って答えようとします：
1) MBaaS は、データベースよりも高いレベルの抽象化を提供します。持続性だけでなく、より高いレベルのサービスを提供します。単なるデータ管理に加えて、ユーザー管理、分析、プッシュなどのサービスを考えてください。MBaaS はほとんどの場合、データ管理サービスを提供しますが、MongoDB などのデータベース上で実行されるため、より高レベルです (MBaaS サービスはスケーラビリティを必要とするため、NoSQL データベースに依存することがよくありますが、db API を直接公開することはありません)。長所: よりシンプルでわかりやすいデータ管理 API を扱うことができます。短所: データベースで見られるように、データ操作をきめ細かく制御することはできません。
2) MBaaS を他のデータベースに結び付けるには、MBaaS インポート/エクスポート サービスに依存する必要があります (最初の質問を読んだ後、これは理解できると思います)。長所: データが MBaaS にどのように格納されるかについて心配する必要はありません (スケーリング、整合性など)。短所: データへの低レベルのアクセス権はありません (MBaaS API を介して行います)。しかし、MBaaS によってデータの処理が大幅に改善されていると言わざるを得ません (これは改善されつつあります)。
3) MBaaS のオフライン機能について何か読んだことがあるかもしれません。それらの一部は、操作や変更されたオブジェクトをキャッシュに保持し、オンライン時にバックエンドと同期します。これらの形式は MBaaS ごとに異なりますが、JSON はバックエンドと通信するときによく使用されます (JSON はデータ/操作の転送に便利ですが、必ずしも MBaaS クライアント キャッシュの内部表現であるとは限りません)。
4) Cookie を使用してセッションを行うという従来の Web の意味ではありません。MBaaS は通常、認証サービスに依存するユーザー セッションのレベルで機能します (この分野では特に強力です)。一部の MBaaS は、アプリのユーザーが明示的な認証なしでセッションを実行できる匿名ユーザー機能を提供します (ただし、これは Web 上で匿名セッションを実行している同じユーザーと関連付けることはできません)。一般に、Web アクティビティを MBaaS アクティビティと共有するには、ユーザー認証を使用する必要があります。
5) MBaaS の第 1 世代では、これは不可能でした。すべてが独立したアプリで考えて設計されました。しかし、「異なるアプリ間でユーザーを共有したい場合はどうすればよいか」などの問題が発生し始めました。そのため、MBaaS プロバイダーは、この種の問題に対処するサービスを追加しています (複数のアプリへのシングル サインオンなど)。
6) 従うかどうかはわかりませんが、MBaaS を使用するアプリケーションを使用している場合は、おそらく MBaaS 認証サービスを使用してユーザーをログインさせるので、1 つのデバイス/1 つのキャッシュを使用しているという事実は問題ではありません。アプリが複数のユーザーを認証できるようにするための問題。これがあなたが尋ねたものと正確に一致しない場合は、今すぐ聞かせてください（質問を編集できます）
これがより良いイメージを得るのに役立つことを願っています。
一番！