【技術組み合せ / Tech Stack】Webアプリ構成の考え方【開発】

＜前置き、挨拶＞

みなさんどうも、こんばんみ～。ぎょうざです。

Webアプリケーションに限定し、システム構成を考える際に

ぎょうざにとって必要な材料を整理してみます。本記事は適宜、更新予定です。

(更新履歴：最終更新 2024/10/19)

2024/10/19

データベースの追記：MongoDBとMySQLの比較

2024/10/01

要素機能の追記

2024/08/02

初版

【目次】

＜第一章、必要な要素機能から考えてみる＞＜第二章、フロントエンド、API(Application Programming Interface)、バックエンド＞＜第三章、デプロイ先（クラウド）＞〆の一言【番外コラム】：APIにおけるエンドポイントとは？

＜第一章、必要な要素機能から考えてみる＞

認証（選定基準：セキュリティ担保、管理のしやすさ）
- ユーザー系：Clerk、Auth.js(旧NextAuth.js)
バリデーション（選定基準：有効でない入力内容パターンを設定できるオプションが多いか）
- Zod
データベース（選定基準：エッジコンピューティングに対応して、挿入データが将来的に更新される可能性があるか）
- 種類（階層型、NoSQL、リレーショナル型(★一番メジャー)、ネットワーク型）
  - 参考：https://www.acrovision.jp/career/?p=1912
- DBサービス：Supabase、Cloudflare D1、Noen、PlanetScale、Amazon Web Service （代表例：RDS） Google Cloud(旧GCP)（代表例：Cloud SQL）
  - DBプロバイダー、エンジン：PostgreSQL、MongoDB、MySQL、SQlite
- ORM（Drizzle、Prisma）
▶選び方

人事管理や生産管理など＞リレーショナル型

ドキュメント管理＞キー・バリュー型と呼ばれるNoSQL型

以下、例としてMongoDBとMySQLの比較

※画像の引用元：https://kinsta.com/jp/blog/mongodb-vs-mysql

支払い（選定基準：）
- Stripe
- lemmon squeezy））
デプロイ、ホスティング（選定基準：）
- Vercel
- Cloudflare Pages
ファイル配信（選定基準：）
- 画像や動画配信：AWS Lambda、Cloudflare
CDN（選定基準：）
- Cloudflare
Webhooks（選定基準：APIが開発者の意図通りに動いているか分かりやすいか）
- QStash（upstach）
- 問い合わせフォーム（React-Hook-Formをよく利用）
- Cloudflare Workers
Webアプリのテスト（選定基準：セキュリティなどアプリ品質と要改善な箇所が確認しやすく、改善方法が具体的に開発者へフィードバックできるか）
- jestとcypressの併用
アイコン（選定基準：種類、サイズ、色、開発フレームワークとの相性の良さ）
- Lucide

＜第二章、フロントエンド、API(Application Programming Interface)、バックエンド＞

フロントエンド

Astro（開発フレームワーク）
Next.js（開発フレームワーク）
shadcn/ui（UIコンポーネント群）
Tailwind CSS（ライブラリ）
React-Hook-Form（ライブラリ）
Zod（ライブラリ）
Django（開発フレームワーク）

API

Hono
FastAPI（Webフレームワーク）

バックエンド

Node.js
Django（開発フレームワーク）

＜第三章、デプロイ先（クラウド）＞

Cloudflare（★個人的に好き）
Netlify
GCP (Google Cloud Platform)
AWS (Amazon Web Services)
Vercel
Sentory
Fly.io
Render

など

〆の一言

作りたいシステムに何が『要求』され、それを満たす『要件』の定義を事前に
きちんと整理しておくのが大切ですが、最も難しいところの一つです。

ここまで読んでいただき、ありがとうございました。

以上、ぎょうざでした。

【番外コラム】：APIにおけるエンドポイントとは？

💡

APIにおけるエンドポイントを「ガンダム」の世界観で例えてみると、
宇宙世紀における「基地」や「コロニー」と、それを「訪問」するモビルスーツや艦船が相当している印象です。
以下で、具体的に見ていきましょう。

1. エンドポイントとは？

そもそもエンドポイントとは、APIでやり取りするための「入り口」や「住所」です。
Web APIに対してクライアント（モビルスーツ）がリクエスト（指示）を送る場所です。

▶ 例：エンドポイント = コロニー

ガンダムの世界では、各コロニー（例：サイド7、サイド6）や地球連邦の基地（例：ジャブロー）は、特定の位置や機能を持っています。これと同じように、APIのエンドポイントも特定の「目的地」であり、その目的地に応じてデータを取得したり操作したりします。

2. エンドポイントとHTTPメソッド

エンドポイントに対して行う操作の種類は、APIの「HTTPメソッド」で表されます。これをガンダムの作戦やモビルスーツの任務で例えます。

GET: 情報を取得する
- 例え: 「偵察ミッション」モビルスーツが敵地や宇宙のコロニーの偵察を行うように、GETメソッドはデータベースから情報を取得するために使います。
  - エンドポイント: /gundams（全モビルスーツのリストを取得）
  - 例: 連邦軍が「ガンダムの現在の状況」を確認したいとき、GETリクエストをサイド7（エンドポイント）に送信し、最新のデータを受け取る。
POST: 新しいデータを送信して作成する
- 例え: 「新兵の配属」連邦が新しいモビルスーツやパイロットを基地に送り込むように、POSTは新しいデータをサーバーに送信して、データを作成します。
  - エンドポイント: /gundams（新しいモビルスーツをデータベースに追加）
  - 例: アムロが新型ガンダムをロールアウトするために、POSTリクエストを送り、サーバー（基地）に新しいガンダムを登録。
PUT: 既存データを更新する
- 例え: 「機体のアップグレード」ガンダムの武装や装甲を強化するように、PUTメソッドは既存のデータをアップデートするために使います。
  - エンドポイント: /gundams/78（ガンダム78号機を更新）
  - 例: ガンダム78号機を改修するために、PUTリクエストを送り、新しい武器や装甲を追加。
DELETE: データを削除する
- 例え: 「機体の廃棄」モビルスーツや艦船が任務を終えて廃棄されるように、DELETEメソッドはデータを削除するために使います。
  - エンドポイント: /gundams/78（ガンダム78号機をデータベースから削除）
  - 例: 連邦軍が旧型のモビルスーツを廃棄するため、DELETEリクエストを送ってデータベースからその機体を削除。

3. エンドポイントのパス（URL）

エンドポイントのURLは、どのコロニーや基地にアクセスするかを表しています。URLの最後の部分（パス）は特定の場所や対象を指すことが多いです。

▶ 例：エンドポイントのURL = コロニーの住所

/gundams: すべてのモビルスーツを指すエンドポイント。これは連邦軍の「全モビルスーツリスト」を指す場所です。
/gundams/78: 特定のモビルスーツ、例えばガンダム78号機を指すエンドポイント。アムロのガンダムにアクセスするイメージです。

4. リクエストとレスポンス

APIに対するリクエストは、作戦指令書のようなものです。リクエストを送ることで、サーバー（基地）がそれに応じたレスポンス（結果）を返してくれます。

▶ 例：リクエスト = 作戦命令、レスポンス = 任務結果

リクエスト: 「サイド7の偵察を行い、敵のモビルスーツの情報を取得せよ」といった偵察ミッションの指令。
レスポンス: 偵察が成功すれば、「敵モビルスーツの位置やスペック情報」といった具体的なデータが返されます。これがAPIにおけるレスポンスです。

5. パラメータとクエリ

エンドポイントに対して特定の「条件」をつけてリクエストを行うことができます。これを「パラメータ」や「クエリ」と言います。

▶ 例：パラメータ = 作戦条件

例: /gundams?model=RX-78&pilot=Amuroこれは、「RX-78ガンダムでパイロットがアムロの機体情報」を取得するためのリクエスト。まさに、特定の機体とパイロットに対するミッションが与えられているような感じです。

いかがだったでしょうか？これで今日からあなたもニュータイプです。

World Hacker（ぎょうざブログ）