アニメ録画予約アプリを作ってみた① (アーキテクチャ編)
はじめに
はてなブログ初投稿です。最近業務でフロントエンド開発を行うことになりました。
そこで勉強がてらで作ったWebアプリの話をしたいと思います。全4回の記事になりますがよろしくお願いします。
何を作ったか
タイトルにもなっていますが、一言でいうと「TweetDeck風のアニメ録画アプリ」です。 ソースコードはgithubにあります。
情報取得先の利用規約の関係で画像にぼかしを入れています。
1週間先までのアニメ番組が曜日ごとに並んでいて、いいねボタンを押すと各自が所有しているNanseにクエリを投げて録画予約をします。
本アプリを開発したモチベーションとして、新しいクールが始まったときに、できるだけ楽に追いかけるアニメを選定できないか?があります。そのため、予約のたびに設定や確認をごちゃごちゃ出さず、ふぁぼる感覚で予約できるよう意識しています。
加えて、番組タイトルをクリックするとそのタイトルでGoogle画像検索を行う機能もあるので、 キャラデザで予約するかを決めることも可能です。いわゆるパケ買いみたいなもの。
※いまのところ外出先から予約することはできません。
アーキテクチャ
アプリの説明をこれ以上してもしょうがないし実際に触ってもらうのが一番早いと思うので、 以降は技術的な話題にフォーカスします。
アプリの構成要素は下図のとおりになります。ごく一般的なWeb 3層アーキテクチャといえなくもない…のか…?
とくに言うことはありませんが1点だけ補足すると、 CHAN-TORUというサービスを利用してNasneを操作しています。 言い換えれば、本アプリはアニメ録画に特化したCHAN-TORUのラッパーみたいなものです。
誤算
上記の構成に落ち着くまでに3つほど誤算がありましたが、長いので読み飛ばしてもらって構いません。
誤算①:Nasneを直接操作できない
当初はCHAN-TORUを利用する予定はなく、APIを使って直接Nasneを操作できないか検討していました。 NasneのAPIを調査した記事もありましたので。
そこでWiresharkを使ってパケット解析してみたのですが、Nasneには操作によってSOAPとRESTという2種類のAPIが実装されているようです。
Nasne HOME (設定画面)で見られる内容は基本RESTで実装してあるのですが、その他の主要な情報参照やクエリはSOAPで実装されています。(番組表参照や、録画予約済み番組一覧取得などなど)
ということで、本アプリの開発には SOAP の仕様を理解するのが必須、となってしまい、一度は諦めそうになりました。
しかし、その後CHAN-TORUというサービスを見つけ、RESTのみ実装できる目処が立ったので無事解決(これには別の苦労があったのですが、次回書きます)。
なお、SOAPに立ち向かった偉大な先人のブログはこちら: https://moroya.hatenablog.jp/entry/2013/09/04/234513
誤算②:ブラウザからCHAN-TORUのAPIを叩くとCORSエラー
これは単に私の知識不足でしたが、フロント側でAjax通信を使って異なるドメインの情報を取得することって、基本できないんですね。セキュリティ上の理由でブラウザがブロックする。
自動でアニメを録画してくれるWebアプリを作ろうとしてたけど頓挫した https://t.co/lDQ7cW27K6
— NY240 (@nagoyan240) January 13, 2020
結論としてはサーバサイドのNodeを用意して、こいつを仲介役にすることで解決しました。
誤算③:外部APIのレスポンスが遅い
はじめはアプリ画面を開いたときにいちいちCHAN-TORUに番組表情報を取りに行っていましたが、はっきりいってレスポンスが遅く、ユーザビリティが良いものではありませんでした。加えて、画面のリロードのたびにAPIを叩くのではCHAN-TORU側にも負荷がかかります。
そこで、バッチ処理で1日1回だけ番組表を取得し、自前のDBにストアするようにしました。
一方で、予約済みの録画情報については、
1. 番組表よりデータ量の少ないこと
2. 更新タイミングが不定であること
により、バッチでDBに格納せずに毎回CHAN-TORUに問い合わせるようにしています。
このような誤算が重なって、はじめはフロントエンド開発の練習のつもりだったのが、 サーバサイドとDBまで用意するはめになってしまいました。まあいい勉強にはなりましたが。
次回以降の予定
今回はアプリの紹介と全体構成を軽く説明しました。 次回以降は技術的詳細についてもっと踏み込んで書く予定です。
3日坊主にならないように頑張ります。それでは。