wkhtmltopdfの次どうするか問題 - おもしろwebサービス開発日記の続き。
上の記事でも書いていますが、令和の今RailsアプリケーションでPDFを生成する基本的な方針としては次の2択だと思っています。
- chromeを使ってHTMLからPDFに変換する
- Thinreports などで直接PDFを生成する
「chromeを使ってHTMLからPDFを生成する」のgemとしてはgroverが有名ですね。だけどこれはruby -> puppeteer -> chromeという構成で、間にnode製のツールであるpuppeteerが挟まっています。
ferrum はrubyから直接chromeを扱うgemなので、これを利用するとnodeが不要になるしメモリ消費量も多少下がるはずだしいいじゃん、と前記事を書いているときは思っていました。しかしferrumはあくまでchromeを操作するのが目的のツールなので「Railsが生成したHTMLからPDFを生成する」ために必要な機能は備えていません。
例えば「RailsでrenderしたHTMLをchromeに食わせてPDFに変換する」部分は自分で書く必要があるし、「HTML中の相対パスで書かれているリンクを絶対パスに変換する」というのも必要になってきます。
なのでferrumだけだといろいろ自分たちで頑張らないといけない部分が多かったのですが、この面倒な部分をやってくれるgem ferrum_pdfが去年くらいからリリースされています。まだ個人的には使えてないですが、@takeyuwebさんは導入したことがあるようです。
なのでgroverを使うようなケースであればferrum_pdfを試してみるのがいいかと思っています。
でも本当にこれでいいのかな？
ferrum_pdfを使うにしても結局「chromeを使ってHTMLからPDFに変換する」形式なのでアプリケーションサーバのメモリが心配になるケースがありそうです。その場合は別インスタンスに「HTMLをPDFに変換する専用アプリケーションサーバ」を立ててPaaSSaaSのように運用するのがいいんじゃないかな〜とぼんやり考えています。そうするとメモリ消費量が心配になったときにHTML->PDFの部分だけスケールアウトできるので…。
この手のPaaSSaaS自体は探すといくつかヒットしますが、HTMLを外部サービスに投げたくない場合がほとんどなはず。
ｶｯとなったら作るかもしれませんが直近ではその予定がないので、もし興味のあるひとがいたら作ってもらえると嬉しいです。
