CMSとFrontned / cms-frontend

2018/12/08にFRONTEND CONFERENCE FUKUOKA 2018 （#fec_fukuoka）の登壇で使用した資料です。

Transcript

1. & Frontend CMS Frontend Conference Fukuoka 2018 @mottox2 /
2. TypeScript, React, Gatsby, Ruby on Rails エンジニアの登壇を応援する会 write-blog-every-week, JS Ninja Gatsby, ReactNative, Nuxt お仕事 コミュニティ OSS
4. #fec_fukuoka 今⽇のターゲット • WordPressを選択して後々後悔したことのある⼈ • ウェブサイト開発でもモダンなフレームワークを使いたい⼈ • 継続的にメンテナンスできるウェブサイト開発を⽬指したい⼈
5. #fec_fukuoka Headless CMSを採⽤して 幸せなフロントエンド開発を⽬指す 今⽇のお話
6. #fec_fukuoka 今⽇話すこと • 従来のCMSでの開発の話。 • Headless CMSの話。 • Headless CMSを採⽤した開発の実例。 • 現実的な⼀歩⽬の話。
7. #fec_fukuoka CMSとは？ • コンテンツ管理システム。（Content Management System） • ユーザーからHTMLやCSSに関しての知識を必要とせずページが編集・公 開できるようなシステム。 • 開発者から⾒たら⼊⼒画⾯がリッチなCRUDアプリケーション。 • ⼀般的に、管理画⾯と公開される画⾯がモノリシックになっているアプリ ケーション。
8. #fec_fukuoka CMSでの開発、⾟い
9. #fec_fukuoka CMSでの開発、なんで⾟いんだっけ？
10. #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
11. #fec_fukuoka WordPressのメリット • サーバーにインストールするだけでサイトが⽴ち上がる。 • プログラミング知識がなくても⽴ち上げが簡単。 • テーマや拡張機能が豊富に揃っている。 • ⽇本語でも情報にすぐたどり着ける。
12. #fec_fukuoka WordPressのデメリット • JavaScriptではないがフロントエンドエンジニアが担当するケースが散⾒ される。 • カスタマイズしたいときはPHP/WordPress APIを使って編集する。 • セキュリティ的な不安がある。 • CMSや拡張機能の脆弱性を狙った攻撃が横⾏している。 1
13. #fec_fukuoka WordPressのデメリット • GitHubなどのフローに乗せるには⼀⼯夫必要。 • 開発環境も作るのにも苦労あり。 • 開発者がWebアプリケーションのテンションで作ろうとするとコストがバ カ⾼くなりがち。 • 移⾏するのもそれなりに⼤変。 • ⼀⾔でいうと開発者としては⾟いということ。 2
14. #fec_fukuoka 内製CMS • 内製で作るブログ管理やコンテンツ管理ツールもCMS。 • ⾃由度は⾼い。 • 今⽇はモノリスかマイクロかは論じません。
15. #fec_fukuoka 内製CMSのメリット • 開発スタックを⾃分で決められる。仕様の⾃由度が⾼い。 • Webアプリケーション開発の知識があれば作れる。 • 開発フローもGitHubに乗せられる。インフラもコード管理も。
16. #fec_fukuoka 内製CMSのデメリット • エンジニアがある程度いることが前提にある。 • 実装⼯数が⼤きい。フロントとバックを分離したら更に⼯数が必要。 • コンテンツ⼊⼒画⾯が実装⼯数の⼤半をしめる。 • そもそも難しい。 • ⾃由であるがゆえの要望が多くなりがち。 • 「〜できる？」→「やります」の流れでどんどんでかくなる。 • 新規メンバーの導⼊コスト。脆弱性の対応も⾃分で。
17. #fec_fukuoka Ꟛ涪؝أز 麊欽劍꟦ 初期コストのギャップが⼤きい WordPress 内製 CMS 初期コストは低いが、運⽤期間が⻑くなると 開発コストが⾼くなる 初期コストは⾼いが、運⽤期間が⻑くなると WordPressと⽐べ相対的に開発コストが低め 初期コストのギャップ 最終的にはどちらも⾟い *グラフはイメージ図です
18. #fec_fukuoka どっちも⾟いので 結果としてWordPressが選択されがち
19. #fec_fukuoka 現代のソリューション Headless CMS
20. #fec_fukuoka Headless CMSとは？ • コンテンツの表⽰部分を持たず、管理画⾯とコンテンツの配信⽤APIを持 つCMS。 • フロントエンドは何でもよい。Webアプリケーションでもスマホアプリで もIoTデバイスでも。
21. #fec_fukuoka Headless CMSの分類 1 2 API駆動系 Gitベース系 Gitでコンテンツを管理する⽅式。 Git上のコンテンツをいじる管理画⾯ を提供する。 フロントエンドも同じリポジトリ内 で管理されることが多い。 CMSとフロントエンドが分離され る⽅式。 API経由でデータを受け渡す。 今⽇はこちら headlesscms.org https://headlesscms.org/about/
22. #fec_fukuoka CMSとは独⽴した開発が⾏える Headless CMS WordPress 盖椚歗꬗ ؐؑـل٦آ 盖椚歗꬗ 8FC
    "1* ؐ ؑ ـ ل ٦ آ ٌ غ ؎ ٕ ، ف ٔ *P5ر غ ؎ أ
23. #fec_fukuoka Headless CMS WordPress 盖椚歗꬗ ؐؑـل٦آ 盖椚歗꬗ 8FC
    "1* ؐ ؑ ـ ل ٦ آ ٌ غ ؎ ٕ ، ف ٔ *P5ر غ ؎ أ CMSとは独⽴した開発が⾏える 開発する場所
24. #fec_fukuoka CMSもフロントエンドも⾃由に選べる Headless CMS Web Frontend React (Gatsby) Vue (Nuxt) React (Next) Vue (Gridsome) etc Headless CMS or or or or
25. #fec_fukuoka 初期コストを抑えつつ、継続的に開発できる WordPress 内製 CMS 初期コストは低いが、運⽤期間が⻑くなると 開発コストが⾼くなる 初期コストは⾼いが、運⽤期間が⻑くなると WordPressと⽐べ相対的に開発コストが低め Headless CMS フロントエンドのみの開発でいいので 初期コストが⽐較的低く 運⽤期間が⻑くなっても そんなに開発コストが変わらない *グラフはイメージ図です Ꟛ涪؝أز 麊欽劍꟦
26. #fec_fukuoka 例) Contentful ManagedなHeadless CMS
27. #fec_fukuoka 例) strapi OSSのHeadless CMS
28. #fec_fukuoka 例) WP REST API WordPressでも Headless CMS的な使い⽅できます WordPress 4.7からコアに採⽤
29. #fec_fukuoka 例) Shopify API ShopifyでもAPIを使って Headless CMS的な使い⽅できます
30. #fec_fukuoka Headless CMS登場の時代背景 • 表⽰端末の多様化。 • Web周辺ツールの改善。（検索・分析・フォーム最適化・課⾦等） • アプリケーション分割の⾵潮。 • SPA開発の⼀般化・開発資産の蓄積。
31. #fec_fukuoka エンジニアから⾒たメリット • 他のサービス開発で使っているスタックで開発できる。 • プロダクトとスタックを揃えるとサイトの運⽤が⽚⼿間になりにくい。 • フロントエンド界隈で成熟した便利な概念を使える。 • Scoped CSS, ComponentベースでのUI構築。 • バックエンドと分離しておけば、後々部分的に差し替えられる。 • 開発環境も簡単に⽴ち開発速度を維持できる。GitHubにも載せられる。 • 普通のWebアプリケーション開発。 Headless CMSを使うとどうなるか？
32. #fec_fukuoka ビジネスサイドから⾒たメリット • 実装・計測などの⾃由度が⾼く、戦略的にサイトを成⻑させられる。 • 管理画⾯のバグや障害で消耗しない。 • 速度の最適化をやりやすい。 • 謎プラグイン導⼊がしにくく遅くしにくい。あとは実装次第。 ServiceWorker対応など • 速度を上げるとサイトの数字がよくなるなどの話もある。 • 採⽤で強い⼈が集まる可能性がある。 Headless CMSを使うとどうなるか？
33. #fec_fukuoka エンジニアから⾒たデメリット • JS⼒が問われる。 • SPA特有の苦しさがある。 • GoogleTagManager、計測、A/Bテストなど。 • イベントトラッキングは⾮常に仕込みやすい。 • WordPressにあったような便利なプラグインはないので、基本⾃前で作る かnpmパッケージにお世話になる。 Headless CMSを使うとどうなるか？
34. #fec_fukuoka ビジネスサイドから⾒たデメリット • プラグイン導⼊で済んだものに対して、いちいちエンジニアに変更を求め ないといけない。（WordPressと⽐較した場合のデメリット） • 管理画⾯のカスタマイズにHeadless CMSの縛りがある。 • WordPressでは簡単なことができないことがある。 • ホスティング型のHeadless CMSは⾼い。 Headless CMSを使うとどうなるか？
35. #fec_fukuoka 本当にできるの？
36. #fec_fukuoka 開発事例
37. #fec_fukuoka WordPressのフロントエンドをReactにリプレース 事例1 https://kobit.in
38. #fec_fukuoka WordPressのフロントエンドをReactにリプレース 事例1 Headless CMS Frontend React (Gatsby) WP REST API Webhook WordPress
39. #fec_fukuoka WordPressのフロントエンドをReactにリプレース • 開発からリリースまで120h。 • ほとんどの時間をリダイレクトや仕様の維持に。 • 約900記事のページをGatsbyJSでビルド。 • 全ページ数えると1600枚ぐらいのHTMLが出⼒されている。 • デプロイが20分*から6~8分まで短縮された。 • ビジネス側には速度・セキュリティ⾯のメリットが刺さった。 事例1 *WordPressをECS上で運⽤していたためデプロイが⾮常に⻑かった。 概要
40. #fec_fukuoka WordPressのフロントエンドをReactにリプレース • 早くしてほしいというビジネスからの要望。 • 開発環境⽴てるのも、デプロイも⾯倒という不満。 • プロダクトでReactを使っていること。 • このサイトとは別にWordPressがあってそちらで検証。 事例1 導⼊の経緯
41. #fec_fukuoka WordPressのフロントエンドをReactにリプレース • 開発環境が `yarn develop` だけで⽴つようになった。 • 記事データは常に本番のWP REST APIから取得する。 • ビジネスの⼈がプルリクエスト投げてくれる出来事があった。 • 普通のReactアプリケーションとして開発できるので体験がよい。 • Netlifyでデプロイが完結するようになり、構成がシンプルになった。 • Lighthouseのパフォーマンススコアが50点台から90点台に。 事例1 いい点
42. #fec_fukuoka WordPressのフロントエンドをReactにリプレース • 最初はデザインリニューアルも同時にやろうかと思ったが断念。 • スコープでかすぎて終わる未来が⾒えなかった。 • JSXに書き換えるのがしんどい。 • 治安の悪いCSSをコンポーネントに収める作業。 • デプロイが6~8分。もう少し短くなると嬉しい。 • フレームワークのコアの改善を待つ。 事例1 つらい点
43. #fec_fukuoka Headless CMSを利⽤したブログの新規構築 事例2 https://mottox2.com
44. #fec_fukuoka Headless CMSを利⽤したブログの新規構築 事例2 Headless CMS Frontend React (Gatsby) Web API Webhook esa.io
45. #fec_fukuoka Headless CMSを利⽤したブログの新規構築 • 開発からリリースまで4h。 • esa.io（情報共有ツール）をHeadless CMSとして使⽤。 • APIの利⽤制限があるSaaSでも静的サイトとしてビルドすれば回避可能。 • Gatsbyのキャッチアップ、バージョンアップテストに使⽤。 • GitHub: https://github.com/mottox2/website 事例2
46. #fec_fukuoka 銀の弾丸ではありません
47. #fec_fukuoka 銀の弾丸ではない • デメリットもあるので銀の弾丸ではないがBetterな選択肢。 • 開発者が関わりだした時点でフロント/バックの分離を検討する。 • 内製に差し替えるコストも低いので後から移⾏可能。 • フロントエンドの⼈としてはいい選択肢。 • いつでも変えられるという安⼼感が重要。捨てやすく。
48. #fec_fukuoka 現実的な⼀歩⽬ • WordPressでもWP REST APIを採⽤することでHeadless CMSとして使え るのでいい選択肢になりうる。 • 開発者として関わるのであれば、Monolithicで作り始めないこと。 • 最初はHeadlessCMSで作って、ビジネスの数字がよくなったら独⾃CMS のバックエンドに差し替えるなどの⼿法を検討。 • Webアプリケーション開発における当たり前の⽅法で作りたい。
49. #fec_fukuoka Webは着実に進化しています。 Headless + 現代のフロントエンド技術で幸せな開発を！
50. #fec_fukuoka @mottox2 @mottox2 / Frontend Conference Fukuoka 2018 Thank you!