2024年現在、新たにwebサービスを立ち上げようとした際には多岐にわたる技術セットが考えられます。
サーバ構成、利用するサービスのアーキテクチャ、言語等、、考え出すと何日も悩んだりします。特に今の時代リッチなライブラリも増えているので本当にキリがない。
自分が今後参考にするためにも様々な観点からまとめてみました。随時更新予定です。
※具体的なフレームワークを組み合わせるというよりは、考慮するべき用語集です。
用語まとめ
| 用語 | 意味 |
| SPA | シングルページアプリケーション。htmlを初回読み込み後、APIにて差分のみ更新していく。 |
| MPA | マルチページアプリケーション。PHPやRuby等、サーバサイド言語で1ページずつhtmlを生成するスタイル。従来の基本的な作り方。 |
| SSR | サーバサイドレンダリング。ほとんどの場合node.jsで動くvue.js等、JavaScriptがサーバ側でhtmlを生成することを言うモダンな技術の事を指す場合が多いが、PHP等サーバ側言語がレンダリングすることも広義では同じ。 |
| SSG | サーバサイドジェネレーション。先にサーバ内にhtmlファイルを生成しておき、リクエストの度にそれを返す。SSRとはhtmlが生成されているタイミングの違いで区別。 |
| ステートレス | 認証周りにてJWTを使う等して、サーバサイド側で情報を持たずにクライアント側に認証情報を持たせる。REST APIでサービスを作る際には基本的な考え方。 |
| ステートフル | 認証情報をサーバサイド側言語の機能にて管理する。従来の一般的な考え方であり、今でもよく使われる。 |
| 外部認証 | Googleでログイン的なやつ。ログインに成功したかどうかと基本的な情報が返ってくる。 |
| OAuth | 外部サービスと連携する時の認可状態を管理する仕組み。 |
| 認証 | IDとPASSを使ってログインする、といったような機能。 |
| 認可 | 機能や情報へのアクセスを許可すると言うような意味合い。権限付与。 |
フロントエンドとサーバサイドに分ける？
まずはここから考えるでしょう。
分けなかった場合にはWordPressのように、サーバサイド言語で見た目に関わる部分も構築します。
一方、分けた場合はSPA+APIやSSR+APIの様に今時な仕組みで構成を組み立てることが可能です。
シンプルな会員機能があれば良いだけの場合はわざわざ分けずにサーバサイド言語だけで作成することも考えられますし、逆にある程度の規模の案件であれば役割の分離という観点から分けてしまう方が開発しやすかったりします。
(フロントとサーバを分ける場合)ドメインも分ける？
フロントとサーバを分ける場合、ドメインをどう分けるかも関わってきます。このあたりは認証ともトレードオフになるので、開発初期から方向性を決めておきましょう。
認証はステートレス？ステートフル？
大雑把に説明すると、従来のPHP等サーバ側でCookieセッションを管理する方法はステートフルと呼びます。一方でJWTトークンを使いサーバ側に認証情報を一切持たない方式をステートフルと呼びます。どちらも状況によってメリットデメリットあるので、よく考えて採用してください。
