バックエンド Web API に管理画面/管理機能を追加するアーキテクチャパターン - valid,invalid

プレゼンテーションレイヤ、いわゆるフロントエンドがクライアントサイドで実装・実行されるアーキテクチャ (注 1) において、管理画面/管理機能をあとから追加する際にどのような実装パターンがあるのかを整理してみます。 注 1: Presentation Domain Separation の実践の中でも、物理的にプレゼンテーションロジックとドメインロジックを分離しているアーキテクチャです。 用語の整理 プレゼンテーションレイヤ 三層アーキテクチャにおける、システムの利用者へユーザインターフェイスを提供する層です。本記事では"フロントエンド"とほぼ同義で使います。 OSI 参照モデルの第六層ではないです。 バックエンド Web API とは プレゼンテーションを持たない Web API (HTTP プロトコルを用いてネットワーク越しに呼び出すアプリケーション) とします。 プレゼンテーションレ

[jmatsu]

今自分も2を選んでるけど、管理画面からしか利用出来ないとかいうAPIの権限管理がtroublesomeなのでどうしようかなぁとか思ってる。

[laiso]

サブシステム(派生アプリ)もこの考え方と相性が良さそう。Next/Nuxtは2. で作って途中から3. にシフトするっていう戦略が取りやすいんじゃないかと思ってる

[masa_iwasaki]

とてもわかりやすい言語化。ビジネスの変化や内部ステークホルダーからの要求に合わせてかけられるコストの範囲で1か2、BI的なものは順次切り出しというのが多そう。

[shingo-sasaki-0529]

管理画面(管理機能) をいつどの程度作り込むかって確かに難しい問題だ。 これまではパターン1 が当たり前だったけど、SPA 開発コストが格段に下がってる現代ならパターン2 のほうが向いてるってのは納得感ある。

[nilab]

バックエンド Web API に管理画面/管理機能を追加するアーキテクチャパターン - valid,invalid

[asayamakk]

深く考えたことなかったので面白かった

[pascal256]

3かな。最悪同じコードベースでもSLAの違う顧客系と管理系はサーバ(厳密にはプロセス)を分けないと運用が面倒過ぎる。。。良く読んだらパターン2はプロセス分けろと補足があるね。だったらありかも。

[hirorinya]

学び

[maruware]

2しかやらないけど良い整理

[Keisuke69]

パターン2が理想だけど3も多そう。てか見かける

[naopr]

わかりやすい分類。メルカリではプロダクトリリース当初から3の方式でやっている

[helldeath]

このバックエンドWeb APIなら2やろな。あたしはSPAでない（バックエンドWeb APIがない）古きwebアプリ作るので管理アプリは3みたいに別に作るけど。

[ikkitang1211]

ちゃんと読んで理解したい

[Chisei]

あとで読みたい

[sharaku3eyes]

む

[ikedanoda]

パターン1を選択することが多かったのでvue element admin 試してみよう

[takezaki]

“バックエンド Web API”の定義が自分と違う