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を使用するバックエンドを作成することもできると思いますが、少し奇妙に見えます（同じことを行うために、ORMまたは何かを直接使用してバックエンドで行うことはできません）多くの作業なしで結果？）

いくつかの考慮事項。

一方では、データベースのホスティング、ロールアウト、管理、および保守は簡単なことではありません。セキュリティ、スケーラビリティ、可用性などの処理については言うまでもありません。したがって、DBプロバイダーがこれらのことを管理するのは興味深いことです。最近、データベースをクラウド上のどこかに配置することは、おかしな考えではありません。もちろん、銀行のミドルウェアとバックエンドを実装している場合は、これをお勧めしません。しかし、クライアントのセッション、ユーザーのプロファイル、設定、および通常クライアント側に存在するこの種のデータや、私たちが気にしないデータには意味があります。

一方、バックエンドを持つことは、単純な理由で分離するのに役立ちます。

私たちが管理および制御しないあらゆる種類のサービスにクライアントを結びつける代わりに、サービス側の停止や破壊などの問題をクライアントが心配する必要がないように、私たちはこれらのことを管理する場所からサーバー側アプリケーションを展開します変更。さらに、バックエンドがファサードのように機能するため、シンプルさが増します。

Q：たとえばFirebaseを利用したい場合、通常、この種のアプリはどのように構成されますか？

プロジェクトごとに大きく異なります。たとえば、Firebase +バックエンドを使用します。

• デバイス、アカウント、セッション間でデータを共有するためのFirebase DB。また、変更ログとして、バックエンドが一時的に利用できない場合、クライアントは書き込み操作をログに送信し、後で同期されます。

• Firebase Cloud Messagesは、上流/下流のプッシュ通知とトピックを提供します。このサービスはpub / subメッセージ交換に使用します。

• Firebase Analytics主にメトリックス。

• ビジネスに厳密に関連するすべてのバックエンド

短い答え：ビジネスロジックを使用しないでください。

長い答え：あなたは、別個のビジネスロジックを持たないほど小さく見えるアプリケーションについて説明します。そもそもそのようなビジネスロジックが本当にあるかどうかを評価します。多くのビジネスロジックはデータ設計によって削減でき、プレゼンテーションレイヤーによって少し削減できます。多くの小規模なシステムのほとんどはCRUDであり、実際のビジネスロジックはありません。到着しない未来のためにスペースを残しただけのパススルーオブジェクトであるクラスの2層または3層を何度も目にしました。

FirebaseからすぐにAPIを開始し、サービスが安定した署名を維持するのに十分なほど契約を設計する限り、実際にAPIが実際に必要であるとわかったときに、後でビジネスロジック用の追加レイヤーを導入できます。背後の実装は変更される可能性があります。

/programming/54994228/how-to-minimise-firebase-function-latencyを参照してください

Cloud Firestoreは、フロントエンドとバックエンド間の主要かつ唯一の接続です。もちろん、一部のロジックはフロントエンド内に含めることができますが、通常はオフラインでのみユーザーの利益になるセキュリティのためです。Cloud Firestoreコレクション自体にセキュリティを実装し、役割など必要なものを保護する必要があります。

次に、Cloud Firestoreトリガーから呼び出されるCloud Functionsを使用します。

フロントエンドアプリケーションからCloud Functionを呼び出さないでください。