Slide 1
Slide 1 text
Nuxt 3でJamstackテンプレートを
作るときの考え方
2023/10/28 まぁし（知念）
Slide 2
Slide 2 text
このセッションをやろうと思った背景
● WebサイトとWebサービスにおける開発手法の二極化
● 各事業会社がサービス運用するための最適化された事例は多い（素晴らし
い）が、Webサイトで汎用的に使える事例が少ない、とくにNuxt 3
これらの課題に対して、Nuxt 3でWeb制作する知見を集めたい
また、知っていることは共有していきたい
参加者の視点のプラスになれば嬉しいし、詳しい人からの指摘があれば
僕自身もさらにブラッシュアップしたい
Slide 3
Slide 3 text
アンケートお願いします🙏
Slide 4
Slide 4 text
Jamstackで開発してますか？
受託や新規サービス構築時に、毎回、開発環境から新規制作してる？
何のフレームワークで、どのようなテンプレートを作ったらいい？
↓
どのプロジェクトでも使える共通化したテンプレートがあると良い！
↓
こんな悩みのある方と情報交換したいので、一緒に学びましょう
Slide 5
Slide 5 text
Nuxt 3のテンプレートが欲しい
Slide 6
Slide 6 text
株式会社TAM/TAMTO：フロントエンドエンジニア 兼 個人事業主
知念 昌史 / まぁし X(Twitter)@chocodogmagic
● 職歴：大学新卒 → 美容師 → エンジニア12年くらい
● 2019年に東京 → 沖縄へ帰省してフルリモート
● Vue.js/Nuxt/Jamstack/セマンティックなHTML/PWA/
アクセシビリティ/SEO/パフォーマンス改善/Movable Type
Slide 7
Slide 7 text
個人的な活動
● 平日9:00〜朝活：おはようエンジニア #ohayo_engineer
○ X（旧Twitter）SpacesでWeb関連の情報発信中、フォローしてね
○ 540回継続しているがいまだに早起きは苦手、一緒にがんばろ？
● コミュニティ運営
○ PWA Night（東京） / v-okinawa（沖縄） / CSS福笑い（東京）
● 好き
○ スプラトゥーン3（トライストリンガー XP1980）
○ ポケモンSV スカーレット
Slide 8
Slide 8 text
https://www.tam-tam.co.jp/
Slide 9
Slide 9 text
Vue.js / Nuxtの実績多数
クラウドワークス様 GLOBIS様 SACCSY様
メディカ出版様 藤子・F・不二雄ミュージアム様
Slide 10
Slide 10 text
これから話すこと
1. Jamstackのテンプレートとは
2. Webサイトによくある最低限必要な機能
3. 汎用的にするための工夫
4. Nuxt 3のJamstackテンプレートSample
Slide 11
Slide 11 text
今日のまとめ
● 最近のWeb制作には様々な手法があり、銀の弾丸は無い
○ が、条件を絞ることで近いことはできる（この前提が重要）
● 汎用的なテンプレートを作るポイントは公式ドキュメントや慣例を参考に
● 運用に耐えられることを重視しよう
● Web開発の流行や変化の背景を見よう
● オレオレ、ぼくのかんがえたさいきょうの〜は厳しい時代
Slide 12
Slide 12 text
1. Jamstackテンプレートとは
Slide 13
Slide 13 text
前提を揃えることが重要
その1
Slide 14
Slide 14 text
Jamstackとは
初出2015〜2019年頃までのJAMStack（表記も少し違う）
JavaScript
API
Markup
JavaScriptを使ってAPIでデータを取得し、HTMLに埋め込み、静的ファイルを生
成、CDNで配信する構成のこと
Headless CMSとの相性の良さ、React/Vueの普及とも重なる
Slide 15
Slide 15 text
Jamstackのメリット
Jamstack構成のメリットはフロントエンドとデータを分解できること
従来の開発手法による課題を解決できる
● サーバーサイドの言語を使う場合（PHP、Rubyなど）、見た目に関するコードとDBの
データを埋め込むためのコードがテンプレートに混在し、密結合となる（モノリス）
● または、SPAのようにクライアントサイドでAPIのデータを処理して表示する方法も
あったが（Ajaxなど）、パフォーマンスやcrawler非対応（当時）という課題があった
● PC/スマホ/タブレットなど端末の多様化や、コーポレート、メディア、
アプリなど複数チャネルが必要になり、共通のデータを扱いたい
Slide 16
Slide 16 text
2023年現在「Jamstack」という定義の変化
Next、Nuxtのようなフレームワークの登場、Vercel / NetlifyのようなSSRに対
応した環境がそろってきたことで静的generate以外の選択肢ができた
フロントエンドとバックエンドのコードを分離して、マイクロサービスを組み合
わせて構築していくことそのものをJamstackと呼ぶようになっている
（このタイミングで表記も現在のJamstackに）
さらに、Jamstackでの開発が当たり前になってきたのでそろそろ死語になるかも
この資料では認識合わせのためにあえてJamstackを使っています
Slide 17
Slide 17 text
前提を揃えることが重要
その2
Slide 18
Slide 18 text
Webサイト：いわゆるホームページ（コーポレートサイトなど）
● 静的ページがほとんど、もしくはCMSで足りる
● 状態（state）管理が必要となる場面が少ない
● バックエンドは問い合わせフォームくらい
Webサービス：事業会社のサービス（SmartHR、Amebaなど）、Webアプリ
● ログイン、投稿など、ユーザーからの入力・操作する画面が多い
● 状態管理が必須、動的なページ
● バックエンドとの連携が必須
WebサイトとWebサービスの違い
Slide 19
Slide 19 text
WebサイトとWebサービス（Webアプリ）で二極化
● HTML/CSS/jQuery → 運用はある
------------------------------
● Pug/EJS、Sass（Gulp）
● JavaScript（ES6〜）
● WordPress等の従来のCMS
------------------------------
● Next.js/Nuxt
● Jamstack
● React / Vue
● Next.js / Nuxt
● コンポーネント開発
● デザインシステム
→ 素のHTMLで作っていない
→ TypeScriptが基本
→ CSS設計の概念が不要
→ マイクロサービス化
Webサイト Webサービス/Webアプリ
制作パターンが
複雑化
制作パターンが
固定化
Slide 20
Slide 20 text
WebサイトとWebサービス（Webアプリ）で二極化
● HTML/CSS/jQuery → 運用はある
------------------------------
● Pug/EJS、Sass（Gulp）
● JavaScript（ES6〜）
● WordPress等のCoupled CMS
------------------------------
● Next.js/Nuxt
● Jamstack
● React / Vue
● Next.js / Nuxt
● コンポーネント開発
● デザインシステム
→ 素のHTMLで作っていない
→ TypeScriptが基本
→ CSS設計の概念が不要
→ マイクロサービス化
Webサイト Webサービス/Webアプリ
制作パターンが
複雑化
制作パターンが
固定化
← 今回はここに注目
Slide 21
Slide 21 text
今回は
WebサイトのJamstack開発を
前提として話します
Slide 22
Slide 22 text
ちなみに、gulpのWebテンプレートは公開済み（古
https://github.com/chinen-octtn/task-runner
Slide 23
Slide 23 text
1. Jamstackテンプレートとは（まとめ）
● Webサイト・コーポートサイトのような静的サイトをHeadless CMS等のAPI
経由で更新できる仕組みで構築するためのテンプレート
● コンポーネント開発の知見が増えている今の潮流に乗るために、Nuxtで開発
する
● Webサイトでは状態管理ライブラリをがっつり活用するケースは多くない
※Nextはすでに事例がたくさんあるがNuxtの事例は少ない
※App Router登場でカオスみがある（Server ActionsもStableに）
Slide 24
Slide 24 text
2. Webサイトによくある機能
Slide 25
Slide 25 text
どのプロジェクトでもだいたい使いそうなもの
● Googleアナリティクス等の解析タグ、タグマネージャー
● sitemap.xml
● CMSでの更新
● ページネーション
● テスト
● Storybookのようなスタイルガイド管理ツール
もっとあるかも、ご意見募集中
（ただし機能を盛りすぎると逆に扱いが難しくなるので注意、Nextさん）
Slide 26
Slide 26 text
注意するポイント
● Googleアナリティクス等の解析タグ、タグマネージャー
○ NuxtLinkを使用する場合はSPAのようにコンテンツが切り替わるため、画面の遷移を解析タ
グに伝える必要がある
● sitemap.xml
○ 大抵はプラグインがやってくれるが、不要なファイルまで載ってしまう
○ 特定のページを追加・除外したい状況が発生するので、設定できるようにしておく
● Headless CMSとの連携
○ どのサービスとも組み合わせやすいように、CMS特有の処理はフェッチの
ロジック内でまとめる
○ 下書きプレビューの実装
Slide 27
Slide 27 text
Jamstackでは考慮する範囲が増える
● 開発 → デプロイ環境
○ レンタルサーバー？オンプレミス？
○ クラウド？
■ AWS：S3、Netlify、Vercel、Cloudflareなどなど
○ GitHub？GitLab？
● Headless CMSとbuildコマンドの連携
○ 日時指定の公開、非公開
○ 下書きプレビューはリアルタイムで確認したい
Slide 28
Slide 28 text
2. Webサイトによくある機能（まとめ）
● ライブラリやモジュールも必要な機能は最小限にしておく
○ アップデート・セキュリティパッチ等の保守も大変になる（プラグイン盛り盛り
WordPressつらいよね？）
● プロジェクトによってCSSフレームワーク使いたい、Vuetify使いたいなどが
あるはず、そこは縛らずに追加したければ設定できる余地を残しておく
○ 例えば、Vuetifyに最適化すると別のものを使いたいときに外す手間が発生する
● StorybookやTestも重要なので入れておきたいが、もし使わないとしても
動作する環境であること
Slide 29
Slide 29 text
3. 汎用的にするための工夫
Slide 30
Slide 30 text
Webサイト自体が複雑に、規模も大きく
受託では、多種多様なサイトを制作する。他社が作ったものを引き継ぐこともあ
れば、自分等が作ったものの運用担当から外れることもある。
運用中のサイトからのリニューアルや、新規サービス立ち上げによるサイト制作
では作るページ数も多くなり、複数人のエンジニアで制作することも多い。
最適化すると便利になる反面、他のパターンでは使えなくなる
※とはいえ、Webアプリほどではない（前提の再確認）
Slide 31
Slide 31 text
幅広く対応できる設計で、引き継ぎやすく
ドキュメントは大事だが、オレオレルールを作ってドキュメントにするのは手間
が多い（他人に説明して理解してもらうのは大変だし、半年後の自分ですら他人
である）
できるだけ共通認識を持ちやすい設計にして、
最小限の情報で共有できるのが理想
Slide 32
Slide 32 text
公式ドキュメントを参照しよう
Slide 33
Slide 33 text
SFC：コードの書き方は慣例に合わせておく
Vue.js公式ドキュメントより参照 https://ja.vuejs.org/guide/scaling-up/sfc.html
Slide 34
Slide 34 text
コンポーネント名・ファイル名の決め方
● コンポーネントは大文字から始める
○ 🙆
○ 🙅
● layoutに関わるような一度しか使わないcomponentはTheをつけていたが公
式ドキュメントからなくなった？
○ 例）
● ディレクトリ構造がコンポーネントを呼び出すときの名前になる
○ components/Parts/Button.vue →
Nuxt公式ドキュメントより参照 https://nuxt.com/docs/guide/directory-structure/components
Slide 35
Slide 35 text
ディレクトリ構造
Nuxtにはディレクトリのルールが決められており、
そのルールに則ることで、Auto Imports等のメリットがある
● できる限り公式に合わせる方が良い
● Nuxt関連ファイルをsrc/ディレクトリに変更するくらい
は良さそう（ディレクトリ直下はライブラリの設定ファ
イルが多くなる傾向があるため）
Slide 36
Slide 36 text
ディレクトリ設計の考え方
主にレイアウト単位か機能単位かで設計が分かれる
レイアウト・・・Webサイトはレイアウト単位の方が都合が良い
components/Parts/Button
components/Parts/List
components/Layout/About
機能・・・Webサービスやアプリは機能単位の方が都合が良い
components/Features/Login
components/Features/Login/Input
components/Features/Login/Button
Slide 37
Slide 37 text
ディレクトリ設計の例
pages・・・このディレクトリに配置した通りにルーティング
pages/about/index.vue
→ /about/index.html
pages/company/message/index.vue
→/company/message/index.html
このpages配下に置くファイルは、ルーティングやmeta情報などページの構成に
必要なものだけを管理して、見た目に関するコードは書かないようにする
レイアウト用のコンポーネントを呼び出すのみ
Slide 38
Slide 38 text
ディレクトリ設計の例
components・・・コンポーネントのファイルを設置する
レイアウト用のコンポーネントと、最小単位のパーツとなるコンポーネントを分
けると良さそう
components/Parts/Button.vue・・・ボタンのコンポーネント
components/Parts/List.vue・・・リストのコンポーネント
components/Pages/About.vue・・・アバウトページ（ボタン等パーツを配置）
components/Pages/Company.vue・・・会社情報ページ（パーツを配置）
※Parts→Elements、Pages→Layoutsなどと置き換えても良い
Slide 39
Slide 39 text
import文を書かなくてもcomponentsやcomposablesのファイルを呼び出せる
useFetchのようなNuxtが提供する処理もどのコンポーネントでも利用可能
コード記述量の削減と、階層を意識せずに使えるメリットがあり、Auto Imports
を生かしたい
→ ディレクトリ・ファイル名のルールは統一しておくと良い
（composablesはuseXXX、パーツはParts配下に格納、レイアウト関連はpages
のルーティングと合わせる、など）
※Colocationの考え方では関連ファイルをまとめたいがAuto Importsしてくれるのか
Nuxt 3のAuto Importsが強力
Slide 40
Slide 40 text
参考文献を取り入れよう
Slide 41
Slide 41 text
参考：bulletproof-react
機能単位（Features）でディレクトリを分ける構築
components/features/auth/
components/features/users/
scaffoldingライブラリを使って、関連ファイルをまとめて生成している
components/Elements/Button/index.ts
components/Elements/Button/Button.tsx
components/Elements/Button/Button.stories.tsx
components/Elements/Button/Button.test.ts
参照 https://github.com/alan2207/bulletproof-react
Slide 42
Slide 42 text
参考：Container/Presentational Pattern
Presentational Component
見た目を責務としたコンポーネント、値はpropsで受け取る
Container Component
ロジック等の処理を持つコンポーネント、見た目には関与せず、
必要な情報をPresentational Componentに渡す
参照 https://www.patterns.dev/posts/presentational-container-pattern
Slide 43
Slide 43 text
参考：Colocation
関連ファイルを近い場所に配置するという考え方
Button/Button.tsx
Button/Button.css
Button/Button.test.ts
Button/Button.stories.tsx
VueでSFCで作るやり方はColocationの概念にも近い
規模が大きいほど関連ファイルが把握しやすくなる
参照 https://kentcdodds.com/blog/colocatio
Slide 44
Slide 44 text
Build方法・デプロイ
Slide 45
Slide 45 text
Nuxt 3で複数のBuildに対応
● Static Site Generate（SSG）
● Server Side Rendering（SSR）
● Client Side Rendering（CSR）
● Incremental Static Regeneration（ISR）
● Stale While Revalidate（SWR）
WebサイトではSSGで足りることも多いが、
ページ数が大量になると比例してGenerate時間
も膨大になるため、SSR等の検討も必要
nuxt.config.tsでディレクトリごとに設定可能
参照 https://nuxt.com/docs/guide/concepts/rendering
Slide 46
Slide 46 text
3. 汎用的にするための工夫（まとめ）
● 引き継ぎしやすいように複雑化を避ける、独自ルールを作らない
● 公式ドキュメントを参考にしよう
● ディレクトリ構造はNuxtのデフォルトをベースにしつつ、コンポーネント分
割は参考文献をあたろう
● WebサービスやWebアプリの設計も参考になる（ただし同じにするのは難し
いので良いところを取り入れる）
● 運用フェーズの更新頻度や体制に合わせてBuild方法を検討する
Slide 47
Slide 47 text
これらの利点を取り入れた構成を作る
Slide 48
Slide 48 text
4. Nuxt 3のJamstackテンプレート
Sampleコード
Slide 49
Slide 49 text
絶賛、制作中
本日公開したかったのですが・・・業務優先でまだpublicにできていません🙏
X（旧Twitter）にて報告しますので
フォローしてお待ちください！
contributeしたい方もぜひ連絡を！
Slide 50
Slide 50 text
今日のまとめ（Nuxt 3でJamstackテンプレートを作るときの考え方）
● 最近のWeb制作には様々な手法があり、銀の弾丸は無いが、【Webサイトを
Jamstack開発するためのテンプレート】という条件に絞ることはできる
● 公式ドキュメントや慣例を参考にして独自ルールを作らない、あえて最適化
しないこともある（運用していく中で最適化するのはアリ）
● Web開発の流行や変化の背景を見つつ、運用に耐えられることを重視しよう
開発するエンジニアも、サイトに訪問するエンドユーザーも、
運用するクライアント様もみんなが使いやすいものを作るために
ひたすら考えてます
Slide 51
Slide 51 text
ご清聴、ありがとうございました！
X（Twitter） まぁし@chocodogmagic
毎月第3水曜日はPWA Night
参加してね！
平日9:00〜SpacesでWeb情報発信中！
Web制作・Webアプリ開発ご依頼ください。
一緒にお仕事しませんか？各職種で採用中