以前開発した自分用ブックリーダーWebアプリに機能追加をするニーズが出てきました。
大量に自炊して、自宅のNASに保存されているPDFデータをWebp圧縮したZIPファイル形式に
一気に変換しなければならないことに気が付きました。
別にPDFのままで使っても良いという仕様にはしているんですが、Webpの圧縮率が良すぎて、メモリの節約になる上、自宅のローカル環境で使う分にはさほどスピードは気にならないんですが、屋外WANでアクセスするとめっぽう遅いので、標準的に最大圧縮されている状態が望ましいと思いました。
他にも追加したい機能はたくさんあるんですが、まずは利用する上でもっとも重要になるファイル圧縮問題として、
データコンバーター機能について仕様を考えてみたいと思います。
今回は、仕様検討のあーだこーだという思考をブログを書きながらまとめてみるので、プログラミングは行いません。
サービスフローを考える
今回のブックリーダーは、基本的に自分の持っている書籍を自炊（スキャン）したデータで、多くの場合がPDFデータですが、たまにJPEGファイルをZIPに圧縮している場合もあり、その2つに対応する必要があります。
WEBPに変換してZIP圧縮するシステム仕様は、
#4に書いているので、こちらも合わせて御覧ください。
参考リンク :
#04 zipデータのコンバート処理
サーバー上に自分の
本棚ページというのを設けて、そこに、手持ちの元ファイル（PDFやJPEGを固めたZIPなど）をアップロードして、順次変換させていくというサービスを追加しようと思います。
データ変換が完了したら、その書籍を読むことができるという風にすることで、ネット上にある自分の本棚を整理するのが少し楽しくなってくるんじゃないなか〜と考えてみました。
ということは、本棚の整理を便利に行えるように、何かしら
UI/UXを工夫しないと、整理しづらいデータやファイル管理システムって、なかなか使いづらくなりますからね。
サムネイルなども加えて、見栄えの良いサービス設計をする必要が理解できました。
データフローを考える
1つの書籍ファイルデータの変換にかかる時間が、数分から数十分ぐらいかかってしまうので（ページ数に応じて）事前に
WIFI環境などで元ファイルをアップロードして、
それらを
バッチ処理的に圧縮処理をしていくというフローが必要です。
もちろん、複数ファイルを処理していくんですが、サーバーのCPU数に応じて処理をする方式と、別に立ち上げているサーバーを並行作業ができるAPIとして実行できるようにする方式を考えています。
クラウドサーバーであれば、複数台のインスタンスを立ち上げる必要があるんですが、WAN接続されている自宅サーバーなども使ったり、レンタルしているけど、あまりアクセスが無いWebサーバーなど,
あまっているサーバーリソースを有効活用できるので、この方式を採用しようと思います。
大量のファイルを一気にアップして、順次変換完了していくのを眺めているのも、なかなか楽しいかもしれません。
別の人が使うことを考える
ブックリーダーも、家族内で共有したり、友達などにチラ見せするという事も考えて、他の人も圧縮することを考えると、ログインをして自分と他人を切り分ける権限や、読み書き権限などを明確にしなければいけません。
ということで、フロントエンド側では、ブラウザキャッシュによる個別のデータ管理、サーバー側では、ユーザーデータ管理を行う仕様を追加しなければいけませんね。
誰がいつアップロードして変換した書籍データなのかもデータベース管理しておかないといけないので、なかなか幅広い開発になりそうです。
システムまとめ
上記の思考をまとめてみました。
# 本棚ページ
# サーバー処理
- 複数ファイルをアップロードできる事を前提にするけど、上限容量を設けてサーバーの負荷対応を行う。
- アップロード後に、元ファイルを格納する場所と、変換後のファイルを格納する場所を確保
- 変換が完了した元ファイルは、削除するが、トラブルの時の対応を考えて、一定期間保持してから、削除する仕様にする。（日次の削除バッチ）
- 1ファイル毎の処理をAPI化して、別サーバーで受付ができるようにすることで、同時にマルチ処理が実行できる仕様を確保
# 変換API仕様
- 変換APIのエンドポイント一覧を、API名を付与して管理
- PDFを受け取ることで変換開始する。
- 変換を開始したAPIは、busy状態にして、受付をストップする。（基本的に1API,1ファイル実行
- ページ単位でのAJAXレスポンスを行いタイムアウトを防止する。（ページ単位で変換データの受取をする）
- もし、APIが途中作業停止した場合は、作業途中のページから別のAPIで作業を続行する。
# 本棚一覧表示処理
- 書籍の表紙（1ページ目）をサムネイルとして画像作成して、本棚のサムネイルビュータイプの表示に利用する。
- サムネイル以外にも、書籍タイトル（ファイル名）の文字列一覧表示も設ける。
- コンバートが完了していない書籍は、「変換中」の表示サムネイルを表示（変換処理が開始していないものは「変換待ち」の表示）
# ブックリーダーアクセス
- 変換完了してサムネイルが完了した書籍は、ファイルのパス(URL)をクエリに付けてブックリーダーにアクセスすることで、書籍を読むことができるようになる。
# データ管理
- ファイルデータは基本的に日付フォルダ/ユーザー名+hash値で管理する
- 元ダイル名をタイトルとして、書籍データベースを構築。
- データ内容 : [ユーザー名、アップロード日、コンバート完了日、書籍名、書籍ページ数、変換後容量]
かなりザックリしたまとめですが、細かなプログラミング仕様に関しては、コーディングしながら、コード内でまとめていきたいと思います。
（githubに反映されます）
このブックリーダーアプリを早く実用的に使いたいという意見をもらい、しばらく放置していましたが開発再開することにしました。
ご意見、ご要望、ご質問、応援メッセージなど、ありましたら、お気軽にお伝えくださいませ。
0 件のコメント:
コメントを投稿