PyCon JP 2019 ポスターセッション発表資料。 自分のブログをリニューアルする際に Django 製 CMS である Wagtail を選び、 GatsbyJS で静的 HTML 化しつつさらにはサーバーレスにも手を出すというあくなき挑戦の記録。

1. DJANGO製CMS
WAGTAILでBLOGを
作ってみる
⾃分のブログをリニューアルする際にDJANGO製CMSである
WAGTAILを選び、GATSBYJSで静的HTML化しつつさらにはサーバー
レスにも⼿を出すというあくなき挑戦の記録。
BY IOSIF TAKAKURA

2. ⾃⼰紹介
• 1981年、東京⽣まれ。
• 修⼠（史学）。専攻は中国とモンゴルの祭祀史。
• 発達障がい当事者。ADHDと⾃閉スペクトラム、多分両⽅ある。
• プログラミング歴は社会に出てから。
• 現在の所属：株式会社サザビーリーグHR
• Pythonは今回の個⼈開発がほぼ始めて。
• 簡単な分析系プログラムは書いたことがある。
• 業務での開発では主に.NET（C#）を使⽤。
• 他に興味あるのはRuby、JavaScript/TypeScriptなど。
• 同⼈で評論も書いていたり。
• ちょっとカウボーイの気がある……

3. 今回のキーワード
$30
30秒
5分

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でクライアントサイドを書くのはまだ実⽤的ではない