CMSとFrontned / cms-frontend

Slide 1

Slide 1 text

& Frontend CMS Frontend Conference Fukuoka 2018 @mottox2 /

Slide 2

Slide 2 text

TypeScript, React, Gatsby, Ruby on Rails エンジニアの登壇を応援する会 write-blog-every-week, JS Ninja Gatsby, ReactNative, Nuxt お仕事コミュニティ OSS

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

#fec_fukuoka 今⽇のターゲット • WordPressを選択して後々後悔したことのある⼈ • ウェブサイト開発でもモダンなフレームワークを使いたい⼈ • 継続的にメンテナンスできるウェブサイト開発を⽬指したい⼈

Slide 5

Slide 5 text

#fec_fukuoka Headless CMSを採⽤して幸せなフロントエンド開発を⽬指す今⽇のお話

Slide 6

Slide 6 text

#fec_fukuoka 今⽇話すこと • 従来のCMSでの開発の話。 • Headless CMSの話。 • Headless CMSを採⽤した開発の実例。 • 現実的な⼀歩⽬の話。

Slide 7

Slide 7 text

#fec_fukuoka CMSとは？ • コンテンツ管理システム。（Content Management System） • ユーザーからHTMLやCSSに関しての知識を必要とせずページが編集・公開できるようなシステム。 • 開発者から⾒たら⼊⼒画⾯がリッチなCRUDアプリケーション。 • ⼀般的に、管理画⾯と公開される画⾯がモノリシックになっているアプリケーション。

Slide 8

Slide 8 text

#fec_fukuoka CMSでの開発、⾟い

Slide 9

Slide 9 text

#fec_fukuoka CMSでの開発、なんで⾟いんだっけ？

Slide 10

Slide 10 text

#fec_fukuoka WordPress • 最も普及しているCMS。2003年にリリース。 • 世界のWebサイトのうち32.4%を占めるサイトがWordPress製。* • 簡単インストールに対応しているホスティングサービスが多い。 • ⼈⼝が多いため、テーマやプラグインが充実している。 • 今⽇のコンテキストでは「⼀般的なCMS」の代表例としてWordPressを取り上げます。 *Usage of content management systems for websites https://w3techs.com/technologies/overview/content_management/all

Slide 11

Slide 11 text

#fec_fukuoka WordPressのメリット • サーバーにインストールするだけでサイトが⽴ち上がる。 • プログラミング知識がなくても⽴ち上げが簡単。 • テーマや拡張機能が豊富に揃っている。 • ⽇本語でも情報にすぐたどり着ける。

Slide 12

Slide 12 text

#fec_fukuoka WordPressのデメリット • JavaScriptではないがフロントエンドエンジニアが担当するケースが散⾒される。 • カスタマイズしたいときはPHP/WordPress APIを使って編集する。 • セキュリティ的な不安がある。 • CMSや拡張機能の脆弱性を狙った攻撃が横⾏している。 1

Slide 13

Slide 13 text

#fec_fukuoka WordPressのデメリット • GitHubなどのフローに乗せるには⼀⼯夫必要。 • 開発環境も作るのにも苦労あり。 • 開発者がWebアプリケーションのテンションで作ろうとするとコストがバカ⾼くなりがち。 • 移⾏するのもそれなりに⼤変。 • ⼀⾔でいうと開発者としては⾟いということ。 2

Slide 14

Slide 14 text

#fec_fukuoka 内製CMS • 内製で作るブログ管理やコンテンツ管理ツールもCMS。 • ⾃由度は⾼い。 • 今⽇はモノリスかマイクロかは論じません。

Slide 15

Slide 15 text

#fec_fukuoka 内製CMSのメリット • 開発スタックを⾃分で決められる。仕様の⾃由度が⾼い。 • Webアプリケーション開発の知識があれば作れる。 • 開発フローもGitHubに乗せられる。インフラもコード管理も。

Slide 16

Slide 16 text

#fec_fukuoka 内製CMSのデメリット • エンジニアがある程度いることが前提にある。 • 実装⼯数が⼤きい。フロントとバックを分離したら更に⼯数が必要。 • コンテンツ⼊⼒画⾯が実装⼯数の⼤半をしめる。 • そもそも難しい。 • ⾃由であるがゆえの要望が多くなりがち。 • 「〜できる？」→「やります」の流れでどんどんでかくなる。 • 新規メンバーの導⼊コスト。脆弱性の対応も⾃分で。

Slide 17

Slide 17 text

#fec_fukuoka Ꟛ涪؝أز 麊欽劍꟦ 初期コストのギャップが⼤きい WordPress 内製 CMS 初期コストは低いが、運⽤期間が⻑くなると開発コストが⾼くなる初期コストは⾼いが、運⽤期間が⻑くなると WordPressと⽐べ相対的に開発コストが低め初期コストのギャップ最終的にはどちらも⾟い *グラフはイメージ図です

Slide 18

Slide 18 text

#fec_fukuoka どっちも⾟いので結果としてWordPressが選択されがち

Slide 19

Slide 19 text

#fec_fukuoka 現代のソリューション Headless CMS

Slide 20

Slide 20 text

#fec_fukuoka Headless CMSとは？ • コンテンツの表⽰部分を持たず、管理画⾯とコンテンツの配信⽤APIを持つCMS。 • フロントエンドは何でもよい。WebアプリケーションでもスマホアプリでもIoTデバイスでも。

Slide 21

Slide 21 text

#fec_fukuoka Headless CMSの分類 1 2 API駆動系 Gitベース系 Gitでコンテンツを管理する⽅式。 Git上のコンテンツをいじる管理画⾯を提供する。フロントエンドも同じリポジトリ内で管理されることが多い。 CMSとフロントエンドが分離される⽅式。 API経由でデータを受け渡す。今⽇はこちら headlesscms.org https://headlesscms.org/about/

Slide 22

Slide 22 text

#fec_fukuoka CMSとは独⽴した開発が⾏える Headless CMS WordPress 盖椚歗꬗ ؐؑـل٦آ 盖椚歗꬗ 8FC"1* ؐ ؑ ـ ل ٦ آ ٌ غ ؎ ٕ ، ف ٔ *P5ر غ ؎ أ

Slide 23

Slide 23 text

#fec_fukuoka Headless CMS WordPress 盖椚歗꬗ ؐؑـل٦آ 盖椚歗꬗ 8FC"1* ؐ ؑ ـ ل ٦ آ ٌ غ ؎ ٕ ، ف ٔ *P5ر غ ؎ أ CMSとは独⽴した開発が⾏える開発する場所

Slide 24

Slide 24 text

#fec_fukuoka CMSもフロントエンドも⾃由に選べる Headless CMS Web Frontend React (Gatsby) Vue (Nuxt) React (Next) Vue (Gridsome) etc Headless CMS or or or or

Slide 25

Slide 25 text

#fec_fukuoka 初期コストを抑えつつ、継続的に開発できる WordPress 内製 CMS 初期コストは低いが、運⽤期間が⻑くなると開発コストが⾼くなる初期コストは⾼いが、運⽤期間が⻑くなると WordPressと⽐べ相対的に開発コストが低め Headless CMS フロントエンドのみの開発でいいので初期コストが⽐較的低く運⽤期間が⻑くなってもそんなに開発コストが変わらない *グラフはイメージ図です Ꟛ涪؝أز 麊欽劍꟦

Slide 26

Slide 26 text

#fec_fukuoka 例) Contentful ManagedなHeadless CMS

Slide 27

Slide 27 text

#fec_fukuoka 例) strapi OSSのHeadless CMS

Slide 28

Slide 28 text

#fec_fukuoka 例) WP REST API WordPressでも Headless CMS的な使い⽅できます WordPress 4.7からコアに採⽤

Slide 29

Slide 29 text

#fec_fukuoka 例) Shopify API ShopifyでもAPIを使って Headless CMS的な使い⽅できます

Slide 30

Slide 30 text

#fec_fukuoka Headless CMS登場の時代背景 • 表⽰端末の多様化。 • Web周辺ツールの改善。（検索・分析・フォーム最適化・課⾦等） • アプリケーション分割の⾵潮。 • SPA開発の⼀般化・開発資産の蓄積。

Slide 31

Slide 31 text

#fec_fukuoka エンジニアから⾒たメリット • 他のサービス開発で使っているスタックで開発できる。 • プロダクトとスタックを揃えるとサイトの運⽤が⽚⼿間になりにくい。 • フロントエンド界隈で成熟した便利な概念を使える。 • Scoped CSS, ComponentベースでのUI構築。 • バックエンドと分離しておけば、後々部分的に差し替えられる。 • 開発環境も簡単に⽴ち開発速度を維持できる。GitHubにも載せられる。 • 普通のWebアプリケーション開発。 Headless CMSを使うとどうなるか？

Slide 32

Slide 32 text

#fec_fukuoka ビジネスサイドから⾒たメリット • 実装・計測などの⾃由度が⾼く、戦略的にサイトを成⻑させられる。 • 管理画⾯のバグや障害で消耗しない。 • 速度の最適化をやりやすい。 • 謎プラグイン導⼊がしにくく遅くしにくい。あとは実装次第。 ServiceWorker対応など • 速度を上げるとサイトの数字がよくなるなどの話もある。 • 採⽤で強い⼈が集まる可能性がある。 Headless CMSを使うとどうなるか？

Slide 33

Slide 33 text

#fec_fukuoka エンジニアから⾒たデメリット • JS⼒が問われる。 • SPA特有の苦しさがある。 • GoogleTagManager、計測、A/Bテストなど。 • イベントトラッキングは⾮常に仕込みやすい。 • WordPressにあったような便利なプラグインはないので、基本⾃前で作るかnpmパッケージにお世話になる。 Headless CMSを使うとどうなるか？

Slide 34

Slide 34 text

#fec_fukuoka ビジネスサイドから⾒たデメリット • プラグイン導⼊で済んだものに対して、いちいちエンジニアに変更を求めないといけない。（WordPressと⽐較した場合のデメリット） • 管理画⾯のカスタマイズにHeadless CMSの縛りがある。 • WordPressでは簡単なことができないことがある。 • ホスティング型のHeadless CMSは⾼い。 Headless CMSを使うとどうなるか？

Slide 35

Slide 35 text

#fec_fukuoka 本当にできるの？

Slide 36

Slide 36 text

#fec_fukuoka 開発事例

Slide 37

Slide 37 text

#fec_fukuoka WordPressのフロントエンドをReactにリプレース事例1 https://kobit.in

Slide 38

Slide 38 text

#fec_fukuoka WordPressのフロントエンドをReactにリプレース事例1 Headless CMS Frontend React (Gatsby) WP REST API Webhook WordPress

Slide 39

Slide 39 text

#fec_fukuoka WordPressのフロントエンドをReactにリプレース • 開発からリリースまで120h。 • ほとんどの時間をリダイレクトや仕様の維持に。 • 約900記事のページをGatsbyJSでビルド。 • 全ページ数えると1600枚ぐらいのHTMLが出⼒されている。 • デプロイが20分*から6~8分まで短縮された。 • ビジネス側には速度・セキュリティ⾯のメリットが刺さった。事例1 *WordPressをECS上で運⽤していたためデプロイが⾮常に⻑かった。概要

Slide 40

Slide 40 text

#fec_fukuoka WordPressのフロントエンドをReactにリプレース • 早くしてほしいというビジネスからの要望。 • 開発環境⽴てるのも、デプロイも⾯倒という不満。 • プロダクトでReactを使っていること。 • このサイトとは別にWordPressがあってそちらで検証。事例1 導⼊の経緯

Slide 41

Slide 41 text

#fec_fukuoka WordPressのフロントエンドをReactにリプレース • 開発環境が `yarn develop` だけで⽴つようになった。 • 記事データは常に本番のWP REST APIから取得する。 • ビジネスの⼈がプルリクエスト投げてくれる出来事があった。 • 普通のReactアプリケーションとして開発できるので体験がよい。 • Netlifyでデプロイが完結するようになり、構成がシンプルになった。 • Lighthouseのパフォーマンススコアが50点台から90点台に。事例1 いい点

Slide 42

Slide 42 text

#fec_fukuoka WordPressのフロントエンドをReactにリプレース • 最初はデザインリニューアルも同時にやろうかと思ったが断念。 • スコープでかすぎて終わる未来が⾒えなかった。 • JSXに書き換えるのがしんどい。 • 治安の悪いCSSをコンポーネントに収める作業。 • デプロイが6~8分。もう少し短くなると嬉しい。 • フレームワークのコアの改善を待つ。事例1 つらい点

Slide 43

Slide 43 text

#fec_fukuoka Headless CMSを利⽤したブログの新規構築事例2 https://mottox2.com

Slide 44

Slide 44 text

#fec_fukuoka Headless CMSを利⽤したブログの新規構築事例2 Headless CMS Frontend React (Gatsby) Web API Webhook esa.io

Slide 45

Slide 45 text

#fec_fukuoka Headless CMSを利⽤したブログの新規構築 • 開発からリリースまで4h。 • esa.io（情報共有ツール）をHeadless CMSとして使⽤。 • APIの利⽤制限があるSaaSでも静的サイトとしてビルドすれば回避可能。 • Gatsbyのキャッチアップ、バージョンアップテストに使⽤。 • GitHub: https://github.com/mottox2/website 事例2

Slide 46

Slide 46 text

#fec_fukuoka 銀の弾丸ではありません

Slide 47

Slide 47 text

#fec_fukuoka 銀の弾丸ではない • デメリットもあるので銀の弾丸ではないがBetterな選択肢。 • 開発者が関わりだした時点でフロント/バックの分離を検討する。 • 内製に差し替えるコストも低いので後から移⾏可能。 • フロントエンドの⼈としてはいい選択肢。 • いつでも変えられるという安⼼感が重要。捨てやすく。

Slide 48

Slide 48 text

#fec_fukuoka 現実的な⼀歩⽬ • WordPressでもWP REST APIを採⽤することでHeadless CMSとして使えるのでいい選択肢になりうる。 • 開発者として関わるのであれば、Monolithicで作り始めないこと。 • 最初はHeadlessCMSで作って、ビジネスの数字がよくなったら独⾃CMS のバックエンドに差し替えるなどの⼿法を検討。 • Webアプリケーション開発における当たり前の⽅法で作りたい。

Slide 49

Slide 49 text

#fec_fukuoka Webは着実に進化しています。 Headless + 現代のフロントエンド技術で幸せな開発を！

Slide 50

Slide 50 text

#fec_fukuoka @mottox2 @mottox2 / Frontend Conference Fukuoka 2018 Thank you!