管理者サイトのエンドポイントについて

Question

前提

現在LaravelをAPIサーバーとして、認証にLaravel Sanctumを使ってNextjsでフロントエンドの構築を行なっています。

• バックエンド → api.ドメイン (EC2 auto scale) ...リポジトリA
• フロントエンド(要ログイン) → app.ドメイン (Vercel isg + csr + ssr) ...リポジトリB
• ランディングページ(非ログイン) → ドメイン (Vercel ssg + isg) ...リポジトリC

ここまで全く問題なく所謂よくある設計です。≒ ベストプラクティス

さらにマルチログインに関してもguardを使うことでユーザー用と管理者用でログインセッションを分けることができます

---

ここからが質問内容であり
管理者サイトを作るための選択肢がいくつか存在します。

1. Laravel製のリポジトリAで管理しbladeファイルを返す

api.ドメイン/admin以降にアクセスした場合、bladeファイルを返します

Route::middleware([])->group(function () {
    Route::prefix('admin')->group(function(){
        Route::get('/', function(){
            return blade file
        });
    });
});

メリット

• 他2つに比べてリポジトリが増えないので管理が楽。
• ユーザーが操作するようなリッチな機能や操作性も必要なく、サービスクラスやリポジトリクラスを使い回すことができる。
• サーバーが増えない。

デメリット

• api.ドメイン/adminというapi感があるURLなのにbladeが帰ってくる。
• URLを知ってるとユーザーがアクセスできてしまう。ログインページが表示されるだけでそもそもダサい。

追加されるエンドポイント

• api.ドメイン/admin ~

2. nextjs製のリポジトリDを新たに作り管理する

admin.ドメインにNextjsを置き、
api.ドメイン/adminに対しリクエストを行いjsonファイルをNextjsで処理

Route::middleware([])->group(function () {
    Route::prefix('admin')->group(function(){
        Route::get('/', function(){
            return json
        });
    });
});

メリット

• バックエンドとフロントエンドの書き方が変わらない。 ( 現状と同じようにバックエンドの人はjson返せばいい、フロントエンドはjson受け取ってjsxに流し込むだけでいい )
• なんかかっこいい

デメリット

• 他2つに比べてコード量が多い。
• わざわざvercelで管理するほどのものなのか？
• リポジトリが増える。
• URLを知ってるとユーザーがアクセスできてしまう。ログインページが表示されるだけでそもそもダサい。
• admin用のAPIエンドポイントが存在することがバレる

追加されるエンドポイント

• api.ドメイン/admin ~
• admin.ドメイン ~

3. Laravel製のリポジトリDを新たに作り管理する

admin.ドメインにLaravelを置き、
リポジトリAと同じDBを共有する(.envのDB_HOST)

Route::middleware([])->group(function () {
    Route::get('/', function(){
        return blade file
    });
});

メリット

• 管理？保守？は辛いが副作用が少ない？
• 完全にユーザーと分かれてるので分岐処理が減り可読性が高まる。
• ユーザーが操作するようなリッチな機能や操作性も必要ないのでbladeで十分。
• 一番やっすいEC2を用意して使うときだけ起動すれば、安いしセキュリティ○。

デメリット

• サービスクラスやリポジトリクラスなどの再実装が必要。 ( 管理者が追加するデータはユーザーは参照しかしないので100％コピペ再実装というわけでもない ) →正直ここ次第な気がする
• リポジトリが増える。
• 若干、他2つよりかはセキュリティが劣る。 ( 攻撃対象が増える ) でもワンチャン高まる

追加されるエンドポイント

• admin.ドメイン ~

---

おそらくこの3パターンになるかと思われますが、どれが一般的な実装なのでしょうか？
もしくは好みでも、理想論でも大丈夫です。

僕が取りこぼしたメリットとデメリットもあったら教えて欲しいです。

記載されていないパターン4、リポジトリBで管理する app.ドメイン/admin は多分sanctum周りでしんどいのとランディングページが分かれてるので管理者も分けるのが適切だと結論づけ排除しました。

作業者/管理者は僕一人ですが、サービスのスマホアプリ化などに伴って作業者/管理者の追加も発生する可能性があります。( 作業者...エンジニア、管理者...操作する人 )

またlaravelとnextjsは別にruby on railsとnuxtjsとかで置き換えてもらって構いません。

laravel9とnext14 app routerで実装してますが、バージョンとかもどうでも良いです。
実装経験年数は両者3-5年以上はあり実装自体の不安はありません。

Comments

[hentaiman]

判断するのに必要な情報がほぼ無いですね。
仕事でやっている事か趣味でやっている事か、質問者自身はどれをやりたいのか、ぐらい追記してみてください

[tomoto]

半分趣味ですがストライプ決済を入れてるので仕事に移行するかもしれません。
「3. Laravel製のリポジトリDを新たに作り管理するが」、めんどくさそうだけど良さそう感があります。

メリットとデメリットが特に知りたいです

Answer 1

１の同じリポジトリで開発して公開用のドメイン配下では管理用のエンドポイントを殺し、また管理用ドメイン配下ではその逆をするのがシステムの規模と今の質問者の技術力にとってお手頃なんじゃないかと思います。

半分趣味ですがストライプ決済を入れてるので仕事に移行するかもしれません。
「3. Laravel製のリポジトリDを新たに作り管理するが」、めんどくさそうだけど良さそう感があります。

まだまだ情報が少なくて何とも言えませんが、３にした場合の懸念点はマイグレーションに関する部分ですね。想像し辛ければ少し開発してみたら分かると思います。

Laravel単位でリポジトリを分けるメリットは別のリポジトリのものを使えない事です。しかしあなたはこれをデメリットとして挙げられています。なぜメリットになるのかについては一朝一夕では身に付くはずもなく、ましてこのような文面では絶対に理解が出来ない事です。だったらそんな難しいメリットの為にリポジトリを分けるのか？という考え方も出来ます。
とはいえメリットデメリットを理解している人なら１を採用したところでリポジトリを分けない事によって起きるリスクを回避して開発できるので、やはり判断が難しいところです。

２は管理機能そのものを売りたい時には良いかもしれないですね。

Comments

[tomoto]

一旦用語を視覚的にわかりやすくするためにリポジトリはgithub、リポジトリークラスはリポジトリと呼ばせてもらいます。
------------------

>まだまだ情報が少なくて何とも言えませんが、３にした場合の懸念点はマイグレーションに関する部分ですね。想像し辛ければ少し開発してみたら分かると思います。

管理者githubもしくはapiのgithubはmigration、seeder、factoryファイルを持たずに操作します。

>Laravel単位でリポジトリを分けるメリットは別のリポジトリのものを使えない事です。しかしあなたはこれをデメリットとして挙げられています。

laravel単位でgithubを分けると例えばニュース一覧を取得するリポジトリがあった場合、もう片方のgithubにも記述しないといけなくなるのでデメリットとしました。片方を修正するともう片方を修正しないといけなくなるからです。

しかし、不要なリポジトリがないので作成、更新メソッドにおいて誤作動の心配がないのでメリットと捉えることはできます。

>なぜメリットになるのかについては一朝一夕では身に付くはずもなく、ましてこのような文面では絶対に理解が出来ない事です。だったらそんな難しいメリットの為にリポジトリを分けるのか？という考え方も出来ます。
とはいえメリットデメリットを理解している人なら１を採用したところでリポジトリを分けない事によって起きるリスクを回避して開発できるので、やはり判断が難しいところです。

結局デメリットを許容できるか次第であるということなんですね

>２は管理機能そのものを売りたい時には良いかもしれないですね。
パッケージとして売るならそうなのかもしれないですが、
今回は例えばお知らせの更新とかユーザーのBANなどを行うので当てはまらないかもしれないです

[hentaiman]

> laravel単位でgithubを分けると例えばニュース一覧を取得するリポジトリがあった場合、もう片方のgithubにも記述しないといけなくなるのでデメリットとしました。片方を修正するともう片方を修正しないといけなくなるからです。

メリットデメリットの大きな分岐点はここがまずひとつですね。
決済があるから更新メソッドの対象が購入履歴的なものだと仮定しそのリポジトリを例にしますが、決済をする側にとってのリポジトリーは自身の決済履歴です。一方管理者にとってのリポジトリーは全ての利用者の決済履歴です。
なので、片方を修正したらもう片方を修正しなくてはならないという考え方がそもそも違うのです。
githubを分ける事によって誤ったリポジトリーを使わなくなる事は分かりますよね？ただそれだけの事なのにセキュリティ的にも堅牢になる事が分かりますよね？こういった事がメリットです。
このような思想の下に設計をした場合にメリットが大きい訳ですが、この内容に対する理解が追いつかない場合はただ開発の手間が増えると感じるだけでデメリットに感じる事だと思います。
メリットデメリットは技術レベルによって変わる訳です。（設計方針も技術力によって変わるので）

何の為にやっているか分からないけどこの設計が良いって言われたからこうしてるー的な事をするとただ開発の苦労が増えてストレスが溜まるだけなので、今の質問者にとっては１が良いだろうという結論です。
それか開発を急がないのであれば一旦保留にし、じっくり勉強してからなぜ３が良いのか？を考えてみれば良いんです。その上で３が良いと思えば３にすれば良いし、やっぱりよく分からなければ１にすれば良いんです。

[hentaiman]

> 若干、他2つよりかはセキュリティが劣る。 ( 攻撃対象が増える ) でもワンチャン高まる

これも違いますよ。
レバレジーズが案件仲介サイト（？知らんけど。）と、このゴミみたいなteratailを１サーバー１ソースでやってる方がセキュリティ劣ってると思いますよ。だって個人情報を扱うという理由から恐らくそれなりの品質の案件仲介サイトのシステムに乗っかって全てがボロクソなゴミみたいなteratailのソースが混ざってるって事ですからね。
たとえ仲介サイト側をスーパープログラマーが作ったとしても、teratail開発してる超低級プログラマー達がゴミみたいなロジックを共有リポジトリに埋め込んだらアウト。

[tomoto]

ありがとうございます。
3番目のパターンで実装します。