自己紹介

• YasunoriMATSUOKA
• 新潟拠点・フルスタックエンジニア
• キャリアの軸はフロントエンド
• バックエンド・インフラは コスパよくマネージドなサービスを使い倒してきた スタンス

今日のアジェンダ

1. キャリアで触れてきた技術スタックの変遷（時系列）
2. 各フェーズでの学びと、つらみ
3. フロントエンドFW / ホスティング / インフラ / バックエンドの変遷整理
4. 最近気になっている組み合わせ
5. まとめ — 最近思うこと

※ 個人の体験・主観です。各技術への dis ではなく、当時の自分から見えた風景としてお聞きください

① 個人開発時代 (1/3) — スタック概観

• ブロックチェーン関連の ウォレットアプリ を個人で作っていた
• Monaca + Cordova でクロスプラットフォーム化
• リリースには至らなかったが、ここで出会ったブロックチェーン系スタートアップに転職
• フロントエンドエンジニアとしてのキャリアがここからスタート

① 個人開発時代 (2/3) — 構成

① 個人開発時代 (3/3) — コード（送金 UI の素朴版）

// MetaMask / ウォレットプロバイダ経由の送金。Vue 側から呼び出してビューに bind
async function send(to: string, amountEth: string) {
  const provider = new ethers.providers.Web3Provider(window.ethereum)
  await provider.send('eth_requestAccounts', [])
  const signer = provider.getSigner()
  const tx = await signer.sendTransaction({
    to,
    value: ethers.utils.parseEther(amountEth),
  })
  return tx.wait()
}

② SES 1社目 — Nuxt.js (1/3)

• 多言語対応が必要な 大規模 SPA
• 1フォームに要素100個超、i18n キー無数、バリデーションロジックがカオス
• TypeScript ではなく JS なので型支援ゼロ
• あらゆるエッジケースで表示・ロジックのバグが出まくり、矛盾点と戦う日々

② SES 1社目 (2/3) — 構成

③ SES 2社目 — jQuery × Spring Boot (1/3)

• カオスな jQuery 実装に苦しみながらフロントエンド開発
• 一部はバックエンド（Kotlin / Spring Boot）のバグ修正にも踏み込む
• DOM を直接いじるアーキテクチャの限界 を実感
• 一方で、Spring Boot の堅牢さ と Kotlin の書き味は印象的だった

③ SES 2社目 (2/3) — 構成

③ SES 2社目 (3/3) — フロント側 vs バック側

// jQuery: DOM を直接書き換える。複雑な分岐が増えると依存が見えなくなる
$('#btn').on('click', function () {
  $('#total').text('計算中...')
  $.post('/api/calc', { x: $('#x').val(), y: $('#y').val() }, function (res) {
    $('#total').text(res.value)
    if (res.warning) $('#warn').show().text(res.warning)
  })
})

// Kotlin + Spring Boot: 入力 DTO 〜 Service までが型で繋がる気持ちよさ
@RestController
class CalcController(private val service: CalcService) {
  @PostMapping("/api/calc")
  fun calc(@RequestBody req: CalcReq): CalcRes = service.run(req)
}

④ SES 3社目 — E2E × 画像処理 (1/3)

• Web & アプリ向け E2E テスト基盤の PoC 開発
• 高精度スクリーンショット + 画像処理で 自動デグレード検出
• Selenium / Appium のクセ、待機制御、Flaky テストとの戦い

④ SES 3社目 (2/3) — パイプライン

④ SES 3社目 (3/3) — 差分検出（核となる発想）

# 同じ画面で 2 バージョンのスクショを比較し、変化量で回帰検知
import cv2
import numpy as np

def diff_ratio(a_path: str, b_path: str) -> float:
    a = cv2.imread(a_path, cv2.IMREAD_GRAYSCALE)
    b = cv2.imread(b_path, cv2.IMREAD_GRAYSCALE)
    if a.shape != b.shape:
        b = cv2.resize(b, (a.shape[1], a.shape[0]))
    diff = cv2.absdiff(a, b)
    return float(np.count_nonzero(diff > 10)) / diff.size

⑤ ブロックチェーンSPの自社開発 (1/3) — スタック

• コスパよくスケールする SaaS をゼロから立ち上げ
• 検索 / 決済 / メールを マネージドで組む ノウハウ蓄積
• 今の自分の礎になった現場

⑤ ブロックチェーンSPの自社開発 (3/3) — Firestoreトリガーの勘所

// onCreate トリガーで集計を更新。重複起動でカウントが二重に進むのを防ぐ
import { onDocumentCreated } from 'firebase-functions/v2/firestore'
export const onPostCreate = onDocumentCreated('posts/{id}', async (event) => {
  const id = event.params.id
  await db.runTransaction(async (tx) => {
    const seenRef = db.doc(`stats/global/seen/${id}`)
    const seen = await tx.get(seenRef)
    if (seen.exists) return                                       // 冪等ガード
    tx.set(seenRef, { at: FieldValue.serverTimestamp() })
    tx.update(db.doc('stats/global'), { count: FieldValue.increment(1) })
  })
})

⑥ NPO法人の自社開発 — 初React (1/3)

• それまで Vue.js / Angular を中心に書いてきた身として
• React 特有のクセ に翻弄されまくる
  • 関数コンポーネントの再レンダリング、クロージャ、useEffect 依存配列…
  • 「Reactの気持ち」を考えないと書けない
• Vue / Angular の宣言的さに慣れた身には、衝撃の連続

⑥ NPO法人 (2/3) — 構成

⑥ NPO法人 (3/3) — useEffect の罠

function Counter({ id }: { id: string }) {
  const [count, setCount] = useState(0)

  //  id が変わっても fetch が再実行されない
  useEffect(() => {
    void fetchCount(id).then(setCount)
  }, [])

  //  依存配列に id を入れる。これを忘れ続けるとデータが古いまま固まる
  // useEffect(() => { void fetchCount(id).then(setCount) }, [id])

  return <div>{count}</div>
}

⑦ Svelte をちょっと触る (1/2)

• ブロックチェーン関連の案件で少しだけ Svelte に触れた
• 印象は Vue.js に近い、リアクティビティが言語レベルに溶けていて書きやすい
• ボイラープレートが少なく、楽しい書き味

⑦ Svelte (2/2) — リアクティブの感覚

<script>
  let count = 0
  // 自動で再評価される。React の useMemo 相当が文法に溶けている
  $: doubled = count * 2
</script>

<button on:click={() => count++}>+1</button>
<p>{count} × 2 = {doubled}</p>

⑧ フリーランス — Next.js × Vercel × Supabase (1/3)

• Next.js / Vercel / Supabase の組み合わせに本格的に入る
• Supabase は PostgreSQL ベース → Firestore からの移行で…
  • SQL クエリの柔軟さに感動
  • DB Schema マイグレーションの堅牢さに感動
• このあたりから AI に書かせる比重が増えてくる（Cursor 等）

⑧ Next + Vercel + Supabase (2/3) — 構成

⑧ Next + Vercel + Supabase (3/3) — Supabase + RLS で読む

// auth.uid() を前提にした RLS が設定済みなら、クライアントから直接 select で OK
import { createClient } from '@supabase/supabase-js'
const supabase = createClient(url, anonKey)

const { data, error } = await supabase
  .from('posts')
  .select('id, title, author:profiles(name)')
  .eq('is_published', true)
  .order('created_at', { ascending: false })
  .limit(20)

⑨ 友人 SaaS — Vercel × Supabase (1/3)

管理が楽な恩恵は大きい、でも…

⑨ 友人 SaaS (2/3) — 構成

⑨ 友人 SaaS (3/3) — RLS ポリシーの書き味

-- profiles テーブル: 自分の行だけ select / update できる
create policy "own row select"
  on public.profiles for select
  using (id = auth.uid());

create policy "own row update"
  on public.profiles for update
  using (id = auth.uid())
  with check (id = auth.uid());

-- これを join 先 / 集計 / 隣接テーブルに全部書き続ける運用がしんどい

⑩ 友人 SaaS — Cloudflare Workers × Supabase (1/3)

• Cloudflare Workers の コスパに驚愕
• 一方で、Supabase の コスト感の重さ が相対的に目立つように
• 「フロント＋エッジ＋DB」のバランスを再考するきっかけに

⑩ CF Workers × Supabase (2/3) — 構成

⑩ CF Workers × Supabase (3/3) — Hono on Workers

import { Hono } from 'hono'
import { createClient } from '@supabase/supabase-js'

type Env = { Bindings: { SUPABASE_URL: string; SUPABASE_ANON: string } }
const app = new Hono<Env>()

app.get('/posts', async (c) => {
  const supabase = createClient(c.env.SUPABASE_URL, c.env.SUPABASE_ANON)
  const { data } = await supabase.from('posts').select('*').limit(20)
  return c.json(data)
})

export default app

⑪ 友人 SaaS の移行 — PHP / Laravel / React (1/3)

• 友人の SaaS の移行作業を手伝う
• Laravel の成熟したバックエンドフレームワークとしての便利さに感動
  • 認証・ORM・マイグレーション・キュー・ジョブ…全部揃ってる
  • 規約による設計の収束力

⑪ Laravel × React (2/3) — 構成

⑪ Laravel × React (3/3) — Controller + Inertia

// Inertia::render で props を返すだけで、React 側に型付きでデータが届く
class PostController extends Controller {
  public function index() {
    return Inertia::render('Posts/Index', [
      'posts' => Post::query()
        ->where('is_published', true)
        ->latest()
        ->take(20)
        ->get(),
    ]);
  }
}

⑫ レガシー RN を Expo 化 / モダナイズ (1/3)

• 久々のアプリ開発、特に iOS の本格デバッグはほぼ初体験
• EAS Build / Update の世界観は思ったより快適
• コーディング自体は楽しかった

⑫ RN × Expo (2/3) — 構成

⑫ RN × Expo (3/3) — チャネル設定

// eas.json: channel と環境を結びつけて OTA 配信を制御
{
  "build": {
    "production": { "channel": "production" },
    "staging":    { "channel": "staging" },
    "preview":    { "distribution": "internal", "channel": "preview" }
  },
  "submit":   { "production": { "ios": { "appleId": "..." } } }
}

⑬ 今ココ — Cloudflare ネイティブ (1/3)

D1 R2

• シンプルに Cloudflare に乗せる構成を基本線に
• 「システムコストを極限まで削る」前提のアーキテクチャ選定

⑬ 今ココ (3/3) — Hono + D1 + Better Auth

import { Hono } from 'hono'
import { betterAuth } from 'better-auth'

type Env = { Bindings: { DB: D1Database; AUTH_SECRET: string } }
const app = new Hono<Env>()

const auth = betterAuth({ /* D1 アダプタ + 自前のセッション戦略 */ })
app.on(['GET', 'POST'], '/api/auth/*', (c) => auth.handler(c.req.raw))

app.get('/api/posts', async (c) => {
  const { results } = await c.env.DB
    .prepare('select id, title from posts where published = 1 order by id desc limit 20')
    .all()
  return c.json(results)
})

export default app

GitHub Actions: Lint

# .github/workflows/lint.yml
name: Lint
on: { pull_request: { branches: [main] } }
concurrency:
  group: lint-${{ github.ref }}
  cancel-in-progress: true
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22, cache: 'npm' }
      - run: npm ci --ignore-scripts
      - run: npm run lint

• ツール: ESLint / Biome / oxlint から選ぶ（最近は Biome / oxlint の高速さが魅力）
• npm ci --ignore-scripts で CI でも postinstall を抑止

GitHub Actions: Format

# .github/workflows/format.yml
name: Format
on: { pull_request: { branches: [main] } }
jobs:
  format:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22, cache: 'npm' }
      - run: npm ci --ignore-scripts
      - run: npm run format:check     # prettier --check . or biome format .

• ツール: Prettier / Biome
• ローカルでも lint-staged / lefthook の pre-commit hook で整形を強制すると CI 失敗が激減

GitHub Actions: TypeCheck

# .github/workflows/typecheck.yml
name: TypeCheck
on: { pull_request: { branches: [main] } }
jobs:
  typecheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22, cache: 'npm' }
      - run: npm ci --ignore-scripts
      - run: npx tsc --noEmit         # or `npm run typecheck`

• tsc --noEmit で 型エラーゼロを merge 条件 に
• Monorepo は tsc -b でプロジェクト参照を一括チェック
• Next.js なら next build 内でも型検査されるが、別ジョブで先に弾く方が速い

フロントエンドFW比較 — Angular / Svelte / Nuxt / Next

FW	印象
Angular	好き。ng update で 2バージョンまで1コマンド対応。半年に1回のメジャーアップデート、地に足のついた改善
Svelte	書き味が楽。Vue.js に近い印象。良かった
Nuxt (Vue.js)	昔触って以来。また触りたい
Next.js (React)	文法は少ないが「Reactの気持ち」を考え続ける必要あり…（個人の感想）

Angular について（推し）

• ng update というメジャーバージョンアップ用コマンドが公式で提供されている
• 2バージョンアップまで1コマンドで対応可能
• 半年に1回の定例的なメジャーアップデートが安定したメンテナンス計画を可能にする
• 入る修正が 開発者にとってありがたい、地に足のついた内容
• 継続的にアプリを維持していくのがめちゃくちゃ楽

昔 Angular で挫折した方も、ぜひもう一度触ってみてほしいです！

React について（個人の感想）

• 文法的に覚えることは少ない（JS/TS + α）
• でも 「Reactの気持ち」をすごく考えて書かないといけない
  • …ある種のメンヘラフレームワーク（個人の感想です）
• ただし、現代の AI 支援開発では事実上のデファクトスタンダード
  → きっちり対応できるようにならねば、と思いながら…

フロントエンドホスティングの変遷

Firebase Hosting / GitHub Pages
            ↓
       Vercel / Netlify
            ↓
       Cloudflare Workers

• 初期: 静的ホスティングで十分
• 中期: Vercel / Netlify で DX が劇的に向上
• 現在: Cloudflare Workers でエッジ＋コスト最適

→ 「PaaS の固定費の重さ」を回避したい現場では、Cloudflareの存在感が大きいが、現時点では特定リージョン限定のデータ保管がアメリカ以外では不可能

インフラ / DB / ストレージの変遷

Firebase (GCP)
   ↓
Supabase (+ 必要に応じて Terraform × GCP / AWS)
   ↓
Cloudflare ( Workers / D1 or Turso (Cloudflare外) / R2 / KV )

• Firebase 期: NoSQL × トリガーで楽だが、規律が崩れるとカオス
• Supabase 期: PostgreSQL の安心感、でもコストとRLSが悩み
• Cloudflare 期: エッジ + 低コスト、ストレージ・DB・KV まで一貫

バックエンドフレームワークの変遷

Express
   ↓
NestJS （など）
   ↓
Hono

• Express: 軽量だが構造化は自分次第
• NestJS: Angular ライクな構造化、エンタープライズ感
• Hono: エッジファースト、Cloudflare Workers と最高に相性が良い

最近面白いと思った組み合わせ — Hono × Inertia

これを Hono と組み合わせる と…

• サーバーサイド ⇄ クライアントサイドで 型をシンプルに引き回せる
• クライアントから データフェッチの複雑さが消える
• ルーティング・データ受け渡しの設計コストがガクッと下がる

まとめ — これまでとこれから

• 「楽に・安く・ほどほどに」 をずっと大事にしてフロント〜バック〜DB/ストレージを選んできた
• 流行り廃りが大きい世界で、結果的にいろいろ触れたのは面白かった
• ただし、器用貧乏感 は否めない
• そして、TS 系エコシステムの限界 も感じる今日この頃

最近思うこと

• PHP / Laravel や Ruby on Rails のような
  成熟したエコシステムの魅力を改めて感じる
• npm 系エコシステムの 治安の悪化（サプライチェーン問題、脆弱性…）
• 継続的にアプリ開発・維持する仕事は、ますます厳しくなっている
• それでも、AI 支援で何とかやっていけるのか…
  なかなか考えさせられる日々です