既存のSPAアプリケーションの管理UIを構築する最良の方法は何ですか？
クライアント側インターフェースとバックエンドサーバーが完全に別のアプリケーションであるアプリケーションに取り組んでいます。バックエンドはRubyで記述され、HTTP経由でのみJSONを提供します。クライアントはJSON APIと通信する完全に「静的な」単一ページのブラウザーアプリケーションです。次に、管理インターフェイスを構築する必要があります。これは、JSON APIによって提供されるコンテンツをキュレートするために使用されます。
私はおそらくこれを構築することができるいくつかの方法を見ます：
既存の単一ページアプリケーションを拡張します。 APIと通信するための既存のコードがすでにたくさんあるので、最初はこれが最も明白な方法のように思えました。ここで私が目にする欠点は、管理セクションが非常にタックされていると感じることです。管理者の懸念は、既存のSPAの機能とほぼ直交しており、コードの再利用の量が実際に2つのアプリケーションを組み合わせる必要があるとは確信していません。
別のシングルページアプリケーション。これはうまくいくかもしれません。既存のSPAからいくつかのコードを複製する必要がありますが、管理インターフェイスは別のアプリケーションのように感じるので、これはもう少し理にかなっていると思います。ただし、管理領域には見事なUIは必要ありません。従来のサーバーレンダリングされたWebアプリケーションは、管理インターフェイスの構築に必要な開発労力を減らす方法の1つかもしれません。
サーバーでレンダリングされたWebアプリケーション。これまでに作成したすべてのサーバーレンダリングされたWebアプリケーションは、データベースに直接接続されています。ただし、これはリクエストごとにJSONAPIと通信する必要があります。それは可能だと確信していますが、私にはあまり馴染みがなく、このアプローチについてはあまり議論されていません。
JSONAPIと同じプロセスでサーバーによってレンダリングされたWebアプリケーション。このように、管理インターフェースのコードレンダリングページはdb/modelレイヤーに直接アクセスでき、ページをレンダリングするために個別のHTTPリクエストを行う必要はありません。これについて私が気に入らないのは、APIコードとUIコードを組み合わせて、それらを完全に分離したいということです。
私はこれらの各ケースでのトレードオフを検討してきましたが、他の人の意見を聞きたいと思っています。同様のアーキテクチャを開発しましたか？どのアプローチを採用しましたか、またその理由は何ですか？
オプション2が最善の策だと思います。パブリックサイトと管理サイトは関連しており、同じDBを使用する可能性が最も高いですが、管理のユースケースとワークフローは通常、パブリックサイトのユースケースとワークフローとほとんど重複していません。そのため、管理サイトには独自のビジネスロジックセットが含まれる可能性があります。共有されているライブラリに共通のコードを確実に移動できるため、UIコードとドメインコードの両方を適切な場所で再利用できます。
個別の管理サイト/アプリは、それを個別にデプロイできることも意味し、場合によってはより適切にロックダウンできます。たとえば、イントラネットからのアクセスのみを許可する必要がある場合があります。
他のすべての条件が同じであれば、正当な理由がない限り（たとえば、ネイティブのハンドヘルドデバイスのサポート）、同じアプリケーションで2つの異なるアーキテクチャを使用することは好みません。
とはいえ、ソリューションは完全に要件に依存します。すべての管理UIがデータベースにいくつかの値を設定し、イントラネットの外部で実行されない場合は、不要なもの（JSON APIなど）があります。従来のサーバーでレンダリングされたUIを立ち上げる方が簡単かもしれません。
一方で、すでにたくさんのSPAが行われており、その一部は再利用できる可能性があります。一貫したルックアンドフィール（および操作）は常に素晴らしいです。私が言ったように、それはあなたの要件が何であるかに完全に依存します。
あなたの決定は基本的に、SPAアプリケーションを作成することを決定したときに最初に行ったのと同じ思考プロセスに従いますが、要件は異なり、結果も異なります。
APIコードがUIコードに組み込まれると言ったときの意味がわかりません。 JSON APIの重要なポイントは、ユーザーインターフェースの記述方法にとらわれないことです。 APIには、管理操作をサポートするために追加のメソッドまたはエンドポイントが追加されている場合がありますが、それは既存のUIにはまったく影響しません。