Tweet
Tweet

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アプリ開発ご依頼ください。 一緒にお仕事しませんか？各職種で採用中