Django 製 CMS Wagtail で Blog を作ってみる
1 like2,215 views
PyCon JP 2019 ポスターセッション発表資料。 自分のブログをリニューアルする際に Django 製 CMS である Wagtail を選び、 GatsbyJS で静的 HTML 化しつつさらにはサーバーレスにも手を出すというあくなき挑戦の記録。
Django 製 CMS Wagtail で Blog を作ってみる
- 2. ⾃⼰紹介 • 1981年、東京⽣まれ。 • 修⼠（史学）。専攻は中国とモンゴルの祭祀史。 • 発達障がい当事者。ADHDと⾃閉スペクトラム、多分両⽅ある。 • プログラミング歴は社会に出てから。 • 現在の所属：株式会社サザビーリーグHR • Pythonは今回の個⼈開発がほぼ始めて。 • 簡単な分析系プログラムは書いたことがある。 • 業務での開発では主に.NET（C#）を使⽤。 • 他に興味あるのはRuby、JavaScript/TypeScriptなど。 • 同⼈で評論も書いていたり。 • ちょっとカウボーイの気がある……
- 4. 今回の⽬的 • Middleman（Ruby製）で作ったブログのリニューアル • Markdownをファイルで書く⽅式からの脱却 • モバイル環境でMarkdownのファイル管理はやりづらい • 将来的に執筆者を増やす際、CMSがあると便利 • 技術的負債がたまりにたまっていたのでリプレース • ⾃社HPリニューアルに向け技術PR • やっていることは現⾏ブログと同じ • リニューアルの計画がある模様 現在のブログサイト。Middleman製。 https://huideyeren.info/
- 5. WAGTAILとは？ • Django製CMS • 制作にはDjangoの知識が必要 • 基本的にModelを書けばCMSになるようになっている。 • 今回もほとんどModelの編集で事⾜りた • 拡張もDjangoの流儀に則って⾏えば⼗分 • Djangoベースなので情報が得やすい • akiyokoさんの『現場で使えるDjangoの教科書』シリーズに はお世話になりました • ⽇本語化、いやi18n対応されている • ITリテラシーと英語⼒が⼗分でない⼈にも使いやすい • その気になればHeadless CMSにする事も可能 • 今回はここが最重要 • モバイルでも使えないことはない
- 6. 今回の構成図 AWS Cloud VPC Amazon API Gateway AWS Lambda Amazon Aurora Serverless Amazon Simple Storage Service NetlifyReaders Writer Trigger at 11:30 Request for build
- 7. WAGTAILを選んだ理由 ちょうどよいCMS がWagtailだった Pythonで何か作ってみる のにちょうどよい Headless CMSにできるの にちょうどよい Django Rest Frameworkも あるし、APIとして使うの は⼗分 他の⾔語で要件を満 たすCMSがなかっ た Rubyでは良さそうな物が なかった ちょっとSquidex（.NET 製）が気になったが採⽤ しなかった 運⽤代はかかっても よいのでインストー ル型の⽅がよい でも、かかって$30ぐらい までが理想
- 8. HEADLESS CMSの⻑所と短所 PROS • 表⽰とバックエンドを分離できる • 疎結合になるので、技術の進歩に追随しやすい • JavaScriptエコシステムの恩恵を受けやすい • サーバーサイドがサーバーレスだから • バックエンドにアクセスするのは編集者のみとする事で、 サーバーレスのコストダウンの恩恵を受けられる • フロントエンドは静的コンテンツのみを配信する設計とする ことで、負荷に耐えやすい構成を取ることができる CONS • 設計が⼤変になる • Python側で⾏うかJavaScript側で⾏うか考えなければいけない • 連携させることによって複雑さが増す • Pythonだけではなく、JavaScriptやアプリ開発の知識が 別途必要になる • フロントエンドとの連携がうまくいかないと使い物に ならない
- 9. サーバーレスへの挑戦 • 更新頻度はそれほど⾼くない • どうせ⽉に1~2回ぐらいしか更新しないし…… • 常時サーバーを動かしておくのはコストがかかる サーバーレスアーキテクチャーの採⽤を決定 （ただし、負荷に関しては考慮しない） • 開発中の⽉額コスト：$13~$14 • 運⽤時の⽉額コスト：$30以内におさまることを想定 • ⽉額コスト上限：$40までに収まってくれればよい そこで、WSGIアプリケーションをサーバーレス化できる Zappaを採⽤することで開発体験が普通のDjango開発からそ れないことを⾒込んだ。
- 10. ZAPPAとAPI GATEWAY、 そしてLAMBDA、 AMAZON AURORA SERVERLESS • ZappaはAWS LambdaとAPI Gatewayを使って、WSGIに 対応するアプリケーションをAWSにデプロイできる ツール • 当然のことながらDjangoにも対応 • コマンドを実⾏することによってデプロイ • Djangoのマイグレーション等も拡張でできる • ただし、デバッグがめんどくさい • ログを吐いて確認していくしかない • API Gatewayにある30秒制限がきつい • 30秒かかるとリクエストは失敗になってしまう • なおDBはAmazon Aurora Serverlessを採⽤ • Serverlessタイプなのでそんなに使わなければ安い！ • リクエストを受けると約30秒のタイムラグの後起動するが、 最後のリクエストから5分経つと⽌まってしまう • なのでDBが⽌まっているときに管理画⾯にアクセスする と最初の1回は必ずエラーになる！！
- 11. GRAPHQLとの格闘 • WagtailとGatsbyの間のインターフェイスはGraphQLを 使⽤することに • WagtailでGraphQLを扱うプラグインはwagtail-graphql- api (https://pypi.org/project/wagtail-graphql-api/)を使⽤ • これもModelにGraphQLで扱う項⽬を書き込む事でGraphQLの スキーマに加えることができる。 • なので、最初Django Rest Frameworkを使ったときよりサー バーサイドの実装は楽になった • が、⼤量のSQL⽂、とりわけSelect⽂が出⼒されてい る • GraphQLのクエリをDjangoのO/R Mapperが上⼿に作れていな い可能性がある • パフォーマンスに関わる問題なので、PyCon JP後に改めて対応 したい。 • とりわけ記事が多くなってくると30秒でリクエストを完 遂できるかが⼼配 • ⾃分の書いたコード以外のところに原因があるとしたら、 できればコントリビュートしたい
- 12. 責務を分ける • サーバーサイドとフロントエンドで分割されたシステ ムを作るには、サーバーサイドで何をするか、フロン トエンドで何をするかしっかり決めないといけない • サーバーサイド(Wagtail)でする事 • 全ての記事の内容を保持 • ブログ記事以外のURL管理 • 画像やドキュメントなどの静的ファイルの保持 • GraphQL APIの配信 • フロントエンドサイド(Gatsby)でする事 • HTML、CSS、JavaScript、Markdownのレンダリング • ブログ記事のURL管理 • 年別、⽉別の記事⼀覧の⽣成 • RSSの⽣成 • このRSSをもとにSNSに新着記事を投稿する • sitemap.xmlの⽣成
- 13. クライアントサイドとの連携 • 当初は、記事をWagtailに登録したらWebhooksを Netlifyに投げる予定だった。 • Wagtailに内蔵されている、DjangoのSignalsを使うつもりだった • しかし、リクエストが⾶ばない…… • AWS LambdaでVPCを使っている場合は外部のインターネット に送る通信ができないと判明 • NAT Gatewayを使えば通信できるようにはなるが…… • これだけに⽉$30かける余裕はない！ • これだけで当初の予算を軽くオーバーしてしまう • そこで、Wagtailから即時にWebhooksを送ることをあ きらめた • NetlifyはURLにPOSTリクエストを投げるとビルドが⾛る仕様 • ということは即時の更新が必要でなければ、Wagtailから 直接Webhooksを送らなくても良い • Google Apps Scriptで毎⽇11:28と11:30にリクエストを送る ことで1⽇1回定期的に更新されるようにした
- 14. クライアントサイドの進捗と今後 の⽅向性 • 正直、進捗ダメです • Wagtailサイドはほぼ出来上がっていても、Gatsbyに関しては まったくと⾔っていいほどできていない • テンプレートへのデータの連係ができた程度 • デザインすらまだできていない • できればユニバーサルWebデザインを⼼がけたい • けっこう多くのことをGatsby頼りにする予定 • そもそも、1回Reactに挑戦しようとして痛い⽬にあっ た経験あり • 業務でアンケートフォームを作ったときに採⽤しようとした • その時は完全に感覚だけで進もうとしていた • Reactは、概念を理解していかないと痛い⽬を⾒る • 問題は、動きの速いフロントエンドとそのコミュニ ティの動きにどれだけ追随できるか
- 15. 技術的負債の問題をどうするか • どうも私は技術的負債を抱えるコードを書きやすい • 社内向けのSphinxのドキュメントを技術的負債にして しまった悲しい過去がある • 過去の発表『社内のマニュアルをSphinxで作ってみた』参照 • https://www.slideshare.net/iosiftakakurayusuke/sphinx- 82892226 • なのに、docstringも書けてない • 追って対応予定 • そもそもTestが書けてない • ⽇頃からTestを書く習慣を付けなければ…… • データの作り⽅も綿密に設計されていない • Userクラスとは別に著者情報を持つことに • 投稿⽇もWagtailの投稿⽇を使っていない • インポート記事の扱いもあるのでこれは仕⽅ない • というか、どういう情報を載せたいのか明確にならないまま 開発を始めてしまった • フロントエンドに⾄っては未完成
- 16. PYTHONでのWEB開発に挑戦して みてどう考えたのか？ （とりわけC#との違いとか） • 選択肢は豊富にある感じ • PEP-8やdocstringからのドキュメント⾃動⽣成など、 Pythonは「読まれる」コードの共有というところに重 きが置かれている感じがした • docstring、書かなきゃなぁ…… • 現在業務で書いているC#は「レガシーコード」 • モノリシックな構造で、ユニットテストもない • ユニットテストのないのは全て「レガシーコード」 • 今回フロントエンドとバックエンドを分けて作ったことが、 今後のシステム作りに対してよい経験になると思う • C#の実⼒を活かすとまた違ったプログラムになる • C#⼤統⼀理論 • クライアントもサーバーサイドもC#でまとめて開発 • コードも共有できる • JavaScriptに頼らざるを得ない以上、JavaScriptでできる ことはJavaScriptにやった⽅がよいと思う。 • Pythonでクライアントサイドを書くのはまだ実⽤的ではない