2020年にNPB開幕できたので作ったWebサービスをブラッシュアップした話
この記事は「個人開発 Advent Calendar 2021」9日目の記事です。
はじめに
こんにちは、ちなヤクちなハムです。日シリ熱かったですね！20年ぶりの日本一だああああああああああああ！
それはさておき、昨シーズンであるところの2020年は、開催が危ぶまれましたが日程を繰り下げて6月から開催されました。そしてその際にWebアプリを作成しました。
簡単に紹介すると、チームを選んでお好みの打順を組むといった内容です。
この時は爆速（自分比）で開発しましたが、今年に入ってからブラッシュアップしました。どう改善したかを昨年版と比較しながら書いていきます。
URLはこちら
2020年版：https://battingordermaker.web.app/
2021年版：https://npb-battingorder-maker.netlify.app/
改善点その１：選手データをJSONファイルからDjangoに持たせるようにした
元々、Vue.js（Vue CLI）で作成してFirebaseにホスティングしていたのですが、選手データをどう持たせるかなと思ったときにJSONファイルで持たせるようにしたため、ざっと700人前後の選手をチームごとに手動でJSONファイルに書き込んでました。FirebaseのDBを使えよ感がありますが、当時はなるべく早く作ることを念頭に作成していて、Cloud FirestoreでもRealtime Databaseでも学習コストかかりそうだったので苦肉の策です。
そうそう選手の移籍とかないやろという見通しの甘さでしたが、そこそこの頻度でトレードや途中加入、育成から支配下登録があり、そのたびJSONファイルを修正してデプロイするのが面倒になりました。
そこで選手情報の更新が容易になるように、DRF（Django REST Framework）で選手情報を登録し、フロントエンド側からAPIを叩いてデータを取得するようにしました。Djangoであれば管理画面も用意されているので、選手情報に変更があれば開発環境が入ったPCでなくても最悪タブレット等でちょちょっと更新できるのが楽です。デプロイも不要だし。
また、せっかくなのでNPB公式HPから選手情報をスクレイピングで取得する機能も作成しました。ちょっと改善の余地はありますが、開幕前やトレード期限、シーズン終了時に多くの選手情報が変更になった際に楽に更新ができるようにしました。（ちなみに手動実行です）
また、構想中のスマホアプリでもこれを基盤にして情報取得しようと思っているので一石二鳥です。
また、レコード数がたいしたことないのでHerokuにデプロイしています。
改善点その２：フロント側をNuxt.js + TailwindCSSで作り直した
当初はVue.js（Vue CLI） + BootStrapで作成していましたが、せっかくなのでNuxt.js + TailwindCSSで作り直しました。
これの為というかもともとVue.jsでアプリ作ったし、次のステップとしてNuxt.jsにも手を出してみたかったので勉強していたこともあり採用しました。TailwindCSSも流行っている雰囲気だったので触ってみようくらいの感じです。
ついでにNetlifyにホスティングするようにしました。
また直接は関係ないですがNuxt.jsの開発環境をDockerで作成しました。
やってみたてんこ盛り。Djangoの方もゆくゆくはDockerにしたい。
Nuxt.jsにしたお陰でOGPやファビコンやアナリティクス等の設定が楽になったりプラグインの管理が楽になったりしました。publicRuntimeConfigやprivateRuntimeConfigも使えるしね。
ちなみにVue/Nuxtは以下の本で勉強しました（ダイマ）
改善点その３：画像をそのままTwitterに投稿できるようにした
元々はハッシュタグを入れ込んだツイート画面に遷移させることはできていましたが、画像は保存してもらって自分で添付してもらう方式でした。当時は若く、TwitterAPIの理解が必要でした。
もちろんそんな手間なことしないで投稿できたほうがいいので、これを機にTwitterAPIを勉強してボタン一発で投稿できるようにしました。
Djangoで認証→画像付きツイートをどうやったかは12/16公開予定のQiitaで詳しく解説しています。
バックエンドを用意したことにより、フロントエンドのみだった場合より比較的導入が容易でした。Pythonであればtweepyも使えますしね。
ただ、今回は画像をhtml2canvasで作成しているため、そのままではtweepyを使って画像付きツイートができません。
（html2canvasではbase64で画像が生成されるが、tweepyではbase64そのままだと扱えない）
そのため、TwitterAPIがcallbackするまでをtweepyを使って、callback後の処理はbase64をそのままUploadするためにTwitterAPIを直接使っています。
base64をデコードすればいいんでしょうけど、主にTwitterへ投稿したらWeb側では画像を持たない仕様のため、デコードして画像をどこかに保存してtweepy使うより、base64のままUploadした方が処理が少なくていいかなという判断でした。こういう場合みんなS3とかに保存してるの？
また、本来であればCookieとかSessionとかlocalStrageとかを使って画像と本文を保持しておくんでしょうが、Djangoでうまくできなかった（自分の理解不足の）ため、Twitter認証する前に、DBにoauth_tokenをキーにして画像（base64形式）と本文を保存しておき、callbackしたらまた取得するという「なんとかした」感満載の作りになっています。んにゃぴ・・・。
（ちなみに投稿に成功したらレコードを削除し、失敗しても１日経ってから削除するようにしています）
改善点その４：GitHubにpushしたらデプロイされるようにした
元々はFirebaseにデプロイする前にビルドして、ビルドできたらデプロイという流れを手動でやっていました。（GitHub Action等使えばよかったのですが・・・）
以前Herokuにあげてた他のアプリも、GitHubにpushしたあとに手動でHerokuにpushしていました。めんどい。
既に上記でフロントエンドはNetlify、バックエンドはHerokuを使っていると書きましたが、pushしたらデプロイされるのマジ楽ですね（今更）。
どちらもそれぞれの管理画面からGitHub連携するだけで自動デプロイできるようになります。設定も楽ちんちん。参考記事も日本語でたくさんあります。なのでここはあまり書くことありません。巨人の肩乗りまくり。
おまけの構成図
あまり厳密ではないかもしれませんが、ニュアンスが伝わればと思います。
2020年版の構成図
2021年版の構成図
おわりに
普段使わない技術が使えておもしろかった（小並感）
作ったら作ったでまだまだこうしたいとかこうしたらいいかと改善点を思いついたので、少しずつ改善していこうと思っています。
興味をもっていただけたら、ぜひ使ってやってください。
サポート、私の好きな言葉です。