管理アプリケーションはAPIを使用する必要がありますか、それともDBに直接アクセスする必要がありますか？
主にクライアントとして機能するモバイルアプリを開発しています。これらのモバイルクライアントが対話するAPIがクラウド上にあり、管理目的のWebアプリケーションもあります。
APIと管理アプリケーションに2つの別々のアプリケーションを使用する必要があるかどうか考えています。私の考えは：
- APIと管理アプリケーションを1つにしておけば、管理アプリケーションはデータベースから直接アクセスできるため、パフォーマンスが向上します。しかし、これはカップリングを導入します。
- それらを分離する場合、カップリングを削除しますが、これによりパフォーマンスが低下する可能性があります。
付記として、私はRuby on Rails for the API and admin application）を、それらを分離するかどうかに関係なく使用します。
これらのアプリケーションは私たちのために開発されたもので、モバイルアプリケーションと管理アプリケーションをサービスとしてお客様に提供します。お客様はAPIを直接使用しませんが、クライアントアプリケーションは使用します。
ここで同様の質問をいくつか見ましたが、主にWeb APIとコンシューマーWebアプリについて話しているのに対して、管理アプリとAPIの組み合わせについてのみ話しているのです。
アプリクライアントが使用するAPIをすでに作成しているので、ビジネスモデルとロジックのライブラリがすでにあります。管理システムがAPIを介してデータにアクセスすることで、そのロジックを複製する必要がなくなります。つまり、クライアントアプリとデータとのやり取りと管理システムとの間に矛盾が生じる可能性が低くなります。
ただし、考慮すべきセキュリティがあります。その性質上、管理システムには、おそらくユーザーアカウントの詳細を含むデータを一覧表示し、そのデータを変更するという、クライアントアプリが実行できることをはるかに超える強力な能力があります。
ロジックのレプリケーションを回避するには、クライアントAPIを作成してから、管理APIでそれを拡張します。そうすれば、コアロジックが変更されても、変更は1回だけにする必要があります。
APIの作成と管理パネルの作成は、2つのまったく別のものです。 APIは可能な限り軽量で高速であることを意図しており、管理パネルはユーザーフレンドリーであることになっています。
プロジェクトの責任は完全に異なるため、それらに取り組むチームメンバーも異なります。
他の多くのものに加えて...
管理パネルの場合：
- uXを理解し、
- グラフィカルUIの設計、
- コードグラフィカルUI、
[〜＃〜] api [〜＃〜]の場合、一方で、次のような人が必要です。
- aPI標準を理解し、
- アプリケーションのプロファイル方法を知っている
- スケーラブルでパフォーマンスの高いシステムを構築する方法を知っている。
各プロジェクトのフォローしている人々の非常に基本的な要約を見ると、管理パネルのコードをAPIプロジェクトに直接配置することはほとんど意味がないことがわかります。バックエンド開発者として、私はあなたのフロントエンドについてそれほど気にすることはできませんでした。
ボタンの色を変更したが、変更が150ミリ秒ではなく800ミリ秒で返される応答の問題に対処しているgitリポジトリを台無しにすることを神が禁止している場合（およびその逆の場合、フロントエンドは疑わしい）開発者はキャッシュ、キューなどに興味があります。
パフォーマンスについてのあなたの心配は心配する必要はありません。管理パネルには、そのシステムの管理者のみがアクセスできます。管理ページが信じられないほど高速にロードされる必要があることはめったになく、「遅い」（違いは実際にはほんの数ミリ秒です）ロード時間は問題ではありません。
デカップリングはさておき、プロジェクトを分離することのもう1つの利点は、セキュリティの向上です。 2つのプロジェクト（またはそれらの適切なビルドスクリプト）には機密の認証情報がありませんが、APIプロジェクトの1つだけです。フロントエンドの新しいプログラマーを雇うことにした場合、場合によっては、NDAに署名しなくても、管理パネルで危険にさらされることはないため、それらを稼働させることができます。データベースに直接アクセスできない。
API開発者を雇うことは、署名されたNDAが彼らにコードへのアクセスを与えるための要件である場合）より長いプロセスになる可能性があります。
管理アプリケーションをAPIから分離します。 パフォーマンスはおそらく良好です。「ハンチ」に基づいてオプションを制限しないでください。
説明は、明らかなパフォーマンスのボトルネックを示していません。パフォーマンスを監視することは良い考えですが、時期尚早な最適化の非常に一般的な理由でもあります。
realパフォーマンスの問題を測定する場合にのみ再検討してください。
モジュールレベルの最初のSOLID原則（単一の責任の原則））を考慮して、APIアプリを管理アプリから分離します。これは常にソフトウェアの保守性と柔軟性のケースです。最終的なバグを簡単に見つけることができます。