Firebaseを使用している場合、ビジネスロジックをどこに配置しますか？
マルチユーザードキュメントシステムを非常に簡略化した単一ページのWebアプリケーションの開発を開始します。フロントエンドはおそらくAngular2を使用します。
プロジェクトには期限が短いため、「ショートカット」を探していました。つまり、すべてをゼロから実装するのではなく、さまざまな既製のサービスを使用しています。
アプリケーションデータを格納するために、なんらかのバックエンドが必要になります。私は周りを見回して、Firebaseを見つけました。Firebaseは、フロントエンドと通信するための個別のバックエンドとAPIを作成する作業の一部を取り除いているようです。
しかしそれは、ビジネスロジックをフロントエンドのAngular2 Webアプリに配置する必要があることを意味しますよね？
将来、モバイルアプリのフロントエンドを作成したい場合、ビジネスロジックコードを複製する必要がありますか？
ビジネスロジックを含み、データストレージにFirebaseを使用するバックエンドを作成するのが代替策だと思いますが、それは少し奇妙に思えます（バックエンドでORMまたは何かを直接使用して同じ結果を達成するために、もっと多くの仕事？）
たとえばFirebaseを利用したい場合、人々は通常どのようにこれらの種類のアプリを構築しますか？
Q：しかし、これはビジネスロジックをフロントエンドのAngular2 Webアプリに配置する必要があることも意味します？
はい。それがサーバーに支えられていない場合、ビジネスはどこかに実装されるべきです。
Googleの買収後、Firebaseは進化して、独自のバックエンドをデプロイする余裕がない（または必要がない）モバイルアプリの開発者向けのプラットフォームになりました。ストレージ、ログイン、分析、メッセージサービスなど、ほとんどのサービスはかなり横断的ですが、ビジネス固有の実行に使用できる Cloud Functions （一種のラムダ）も提供することは事実ですルール。ただし、エンタープライズアプリケーションまたは複雑なドメインとビジネスロジックを備えた大規模なアプリケーションの場合、この種のサポートは不十分です。
そのため、ご想像のとおり、Firebaseはホスト専用のバックエンドを用意してビジネス固有のオペレーションを実行することを免除しません。
Q：将来的にモバイルアプリをフロントエンドにしたい場合、ビジネスロジックコードを複製する必要がありますか？
必ずしも。 WebアプリがAngularに基づいて構築されている場合、 NativeScript のようなクロスプラットフォームを使用すると、Webコンポーネント、ライブラリ、ユーティリティ、モデルなどを再利用できる場合があります。完全な互換性を保証します。キーは TypeScript の上にあり、AngularとNativeScriptの両方がTSでコーディングする必要があります。
問題はその配布とバージョン管理のためにJavaScriptをホストする場所です。単語 [〜＃〜] cdn [〜＃〜] 。
Q：代替案は、ビジネスロジックを含み、データストレージにFirebaseを使用するバックエンドを作成することですが、少し奇妙に見えます（できませんでした） tバックエンドでORMまたは何かを直接使用して、多くの作業をせずに同じ結果を達成しますか？）
いくつかの考慮事項。
一方では、データベースのホスティング、ロールアウト、管理、および保守は簡単なことではありません。セキュリティ、スケーラビリティ、可用性などの処理は言うまでもありません。そのため、DBプロバイダーがこれらのことを管理するのは興味深いことです。最近、データベースをクラウド上のどこかに配置することは、おかしな考えではありません。もちろん、銀行のミドルウェアとバックエンドを実装している場合は、これをお勧めしません。ただし、クライアントのセッション、ユーザーのプロファイル、設定、および通常クライアント側に存在するこの種のデータや、気にしないデータには意味があります。
一方、バックエンドを持つことは、単純な理由で便利ですdecoupling。
私たちが管理および制御していないあらゆる種類のサービスにクライアントを結びつける代わりに、サービス側のシャットダウンや中断などの問題についてクライアントが心配する必要がないように、これらの事柄を監視する場所からサーバー側アプリケーションを展開します変更。さらに、バックエンドはファサードのように機能するため、シンプルさが増します。
Q：たとえば、Firebaseを利用したい場合、人々は通常どのようにこの種のアプリを構築しますか？
プロジェクトごとに大きく異なります。たとえば、Firebase +バックエンドを使用します。
Firebase DBdevices-accounts-sessions間でデータを共有します。また、変更ログとして、バックエンドが一時的に利用できない場合、クライアントは書き込み操作をログに送信し、後で同期されます。
Firebase Cloud Messagesは、上流/下流のプッシュ通知とトピックを提供します。このサービスはpub/subメッセージ交換に使用します。
Firebase analytics主にメトリックス。
ビジネスに厳密に関連するすべてのバックエンド
短い答え：ビジネスロジックを使用しないでください。
長い答え：個別のビジネスロジックを持たないほど小さく見えるアプリケーションについて説明します。そもそもそのようなビジネスロジックが本当にあるかどうかを評価します。多くのビジネスロジックはデータ設計によって削減でき、プレゼンテーションレイヤーによって少し削減できます。多くの小規模システムはほとんどCRUDであり、実際のビジネスロジックはありません。二度と三度のクラスのクラスが、パススルーオブジェクトであり、決して到達しない未来のためにスペースを残しているのを見てきました。
FirebaseからすぐにAPIを開始し、サービスが安定した署名を維持するのに十分なほど契約を設計する限り、実際にAPIが実際に必要であるとわかったときに、後でビジネスロジック用の追加レイヤーを導入できます。背後の実装は変更される可能性があります。
参照 https://stackoverflow.com/questions/54994228/how-to-minimise-firebase-function-latency
Cloud Firestoreは、フロントエンドとバックエンド間の主要かつ唯一の接続です。もちろん、一部のロジックはフロントエンド内に含めることができますが、通常はユーザーの利益のためにのみオフラインにすることができるセキュリティのためです。 Cloud Firestoreコレクション自体にセキュリティを実装し、役割など必要なものを保護する必要があります。
次に、Cloud Firestoreトリガーから呼び出されるCloud Functionsを使用します。
フロントエンドアプリケーションからCloud Functionを呼び出さないでください。