仕組みから学ぶ Web

Web engineering fundamentals

書けるけれど、説明できない。を埋める

フレームワークの使い方は調べれば出てきます。調べても身につかないのは、その下で動いている仕組みと、先人が何を悩んで今の形にしたかという設計判断です。 このサイトは言語の文法を扱いません。動く図解で仕組みを見せ、設計判断を問う演習で「自分ならどうするか」を言葉にしてもらいます。

ロードマップを見る全 37 トピック

どの記事も、同じ順序で進みます

読む側が構造を覚えなくていいように、並びを固定しています。解説と、最初の演習までは無料です。

  1. 事故

    実際に起きる障害から入る。知識ではなく困りごとを先に見せる

  2. What

    動く図解。文章より先に、図を触って掴む

  3. Why

    設計意図と歴史的経緯。退けられた代替案まで踏み込む

  4. 演習

    解説を読む前に、まず自分で判断する

  5. 実務での判断ポイント

    いつ使い、いつ使わないか。しきい値とトレードオフ

  6. さらに演習

    設計判断を問う演習と、説明できるかの練習

無料月額 500 円（税込）。いつでも解約できます

学習状況

— / 37詳しく見る →
ネットワーク / Web—/6
ブラウザ—/6
認証 / セキュリティ—/4
データ / DB 設計—/7
設計 / アーキテクチャ—/4
API 設計—/5
運用 / 開発プロセス—/5

7 つの領域

各カテゴリは「読み終わったら答えられるようになる問い」で定義しています。

ネットワーク / Web

6 本

リクエストが届くまでに何が起きているか

ブラウザの URL 欄に文字を打ってから画面が出るまで、名前解決・接続確立・暗号化・キャッシュという4つの関門がある。障害調査で「どこまでは届いているのか」を切り分けられるかは、この層を絵で描けるかどうかで決まる。

  • ?DNS の TTL を短くすると何が起きるのか
  • ?HTTP/2 にしたのにページが速くならないのはなぜか
  • ?CDN のキャッシュが消えないとき、どこを疑うか

ブラウザ

6 本

画面が描かれる仕組みと、その上の制約

ブラウザは HTML を受け取ってから描画するまでに決まった工程を通る。どの CSS プロパティを触ると工程のどこからやり直しになるか、なぜ非同期処理が「詰まる」のか。そして、そこに被さる同一オリジンという安全装置。

  • ?top を書き換えると重く、transform だと軽いのはなぜか
  • ?重い処理中にクリックが効かなくなるのはなぜか
  • ?CORS エラーはサーバーとブラウザのどちらが出しているのか

認証 / セキュリティ

4 本

誰であるかを証明し、なりすましを防ぐ

認証は「セッションをサーバーが覚える」か「トークンに書いて持たせる」かの選択から始まる。この選択が、ログアウトの実装可能性・スケール特性・漏洩時の被害範囲をすべて決める。攻撃手法は、その選択の穴を突いてくる。

  • ?JWT を使うとなぜ即時ログアウトが難しくなるのか
  • ?SameSite=Lax だけで CSRF は防げるのか
  • ?アクセストークンを localStorage に置くと何が起きるのか

データ / DB 設計

7 本

正しく保ち、速く引く

テーブル設計は「同じ事実を2か所に書かない」ことから始まり、インデックスは「読む行を減らす」ためにある。そしてトランザクションの分離レベルは、同時に動く処理がお互いをどこまで見てよいかの取り決め。遅いクエリの原因は、たいていこの3つのどれか。

  • ?複合インデックスの列の順番はなぜ重要なのか
  • ?READ COMMITTED で起きて REPEATABLE READ で起きない異常は何か
  • ?件数が増えたら急に遅くなったクエリの、最初に見る場所はどこか

設計 / アーキテクチャ

4 本

変更しやすさを構造で買う

設計の良し悪しは「動くかどうか」では測れない。測れるのは、仕様変更が来たときに何ファイル触るか。凝集度・結合度・依存の向きは、その「触る範囲」を制御するための語彙であり、SOLID もレイヤードもその適用例にすぎない。

  • ?依存性逆転は具体的に何を逆転させているのか
  • ?レイヤードアーキテクチャで DB のカラム名が画面まで漏れるのはなぜ問題なのか
  • ?「共通化」がかえって変更を重くするのはどういうときか

API 設計

5 本

他人が使う契約をつくる

API は一度公開すると簡単には変えられない契約になる。リソースの切り方、同じリクエストが2回届いたときの振る舞い、失敗の伝え方。これらは実装の都合ではなく、呼ぶ側が安全なコードを書けるかどうかで決まる。

  • ?決済 API に同じリクエストが2回届いたらどうなるべきか
  • ?エラーレスポンスに何を入れると呼び出し側が自動復旧できるのか
  • ?GraphQL にすると何が楽になり、何が難しくなるのか

運用 / 開発プロセス

5 本

壊さずに届け、壊れたら気づく

リリースは「デプロイして終わり」ではない。同じ成果物がどの環境でも同じように動く保証、壊れたときに戻せる仕組み、壊れていることに人間より先に気づく仕組み。テストはその一番外側の防波堤。

  • ?手元では動くのに本番で動かない、を構造的に潰すには何が要るか
  • ?アラートが多すぎて誰も見なくなる状態をどう避けるか
  • ?E2E テストを増やすほど開発が遅くなるのはなぜか