・0 pv・4 min read
Laravel SailプロジェクトでPDF生成：Snappyの代替ライブラリを探る - 未解決の旅
laravel-snappyの代替案の検討
wkhtmltopdfのPublic archiveを機に、laravel-snappyも今後利用できなくなるのでは？という不安があったため代替ライブラリを探すことにしました。
GitHubリポジトリ（引用）
なぜ、wkhtmltopdfがPublic archiveになったからlaravel-snappyの代替を探すのか？ということですが、これはlaravel-snappyがwkhtmltopdfを利用しているからですね。
GitHubリポジトリ（引用）
そのままだと、古いままの利用となるのでセキュリティリスクの発生、CSSやブラウザの仕様変更についていけなくなるのでは？という懸念があります。
そのため、今回はこのライブラリの代替案を探しいくつか試してみた過程を書きたいなと思っています！
注意点
- 記事を書いている人は弱々2年目程度のエンジニアです。
- まだどのサービスを利用するのか？決定できていません。あくまでも過程であることを注意してください。
- 教えるというものではなく、こんな感じで勉強してます～みたいな感じなのでゆるーく見ていただけると嬉しいです。
こんな感じで書いていますので生暖かい目で見ていただけると幸いです！
とまぁ前置きと言い訳はこのくらいにして今段階で調べたことを書いておきたいなぁと思います。
代替案の検討
一旦自分が調べたいくつかの案を箇条書きで書いておきます。
それについて自分が検証した感じこうだったなぁというのをちょろちょろ〜とメモ書きする感じで行こうかなと思います。
- mPDF
- domPDF
- Headless Chrome（Browsershot & Puppeteer)
- Seleniumコンテナ環境
- 有料サービスの検討
1.mPDF
- laravelでPDF生成といったらの代名詞的存在
- そのためComposerを使用して簡単に導入可能です。
- フォントの導入は必要なかった。（確か...）
- 日本語表示は可能ですが、一部CSSが反映されずJavaScriptに対応していない。
- scriptタグで読み込まれるものが使えない。 ※CSSの反映について私のプロジェクトの場合ですので、使用する際は各々のプロジェクトで確認してください！）
- 利用できるCSSは多いが、JavaScriptの非対応は大きな問題だと考える。
2.domPDF
- こちらもlaravelでPDF生成と調べると必ず出てくるライブラリ
- 日本語に対応するためにはフォントの導入が必要になります。
- 文章が折り返されず見切れてしまうので、設定で折り返しを行わないといけない。（ただ変なところで折り返されたりする...）
- 対応しているCSSが少ない。特にCSS3に対応しているのが少ない印象。
- 絵文字や環境依存文字（機能依存文字）は使用できなかった。🌟←こんなやつ
3.Headless Chrome（Browsershot & Puppeteer)
- PuppeteerとBrowsershotを使用するのだが、導入が非常に複雑。
- M1・M2チップではChromiumの動作が不安定（というか動かない。）
- Browsershotは簡単に導入できるのだが、Browsershotで利用するPuppeteerとChromiumがうまく入れれない。（Puppeteerを入れると入るらしいんだが...Chromiumが入らなかったりと訳がわからない。) Browsershotの導入は以下のGithubで確認してみてください。
Githubリポジトリ（引用）
4.Seleniumコンテナ環境
- 'seleniarm/standalone-chromium'イメージを使用。コンテナは起動するが動作が不安定。
- 特にM1・2チップでの動作に難あり。
- 仕組みとしては、仮想でchromを起動し該当のページをスクショしてPDF化するらしい...たしか...
5.有料サービスの検討
- 以下の3つのサービスの利用を検討しています。
- PDFShift
PDFShift公式- DocRaptor
DocRaptor公式- API2PDF
API2PDF公式- API2PDFはwkhtmltopdfとHeadless Chromeなどで生成しているらしい。
API2PDFのDoc（引用） - 個人的にはPDFShiftを試してみたいなぁと思います。無料枠もあるみたいですし...
まとめ
とまぁ...こんな感じでまとめてみましたがどうでしょうか？
個人的にはPDFShiftがかなり自社サイトなどで利用しやすそうだなぁと思っています。
それぞれ、検討はまだまだ不十分ではあるでしょうし、私自身のスキルではさして細かく検討できていないのでなんとも言い難いところではあります...
ざっくりとまとめを言うのであれば、そこまでデザインが複雑・高度なものでなければ導入が簡単なmPDFやdomPDFを利用するのが良さそうです。
また、技術的なスキルが高い人であればHeadless Chromeなどを自分で立ち上げる・構築することでwkhtmltopdfの代替とできるかもしれません。（ただ、他のブラウザでできるかなどの検討は必要かもしれませんが...）
技術があまり高くない、導入までの検討にあまり時間をかけられない、あるいは予算を出すことができるよ！ってところは有料サービスの検討も十分に可能性はあるかなと思います。
私自身は、PDFShiftが使いやすそうな印象を感じたのでこちらを無料枠の範囲で使ってみて最終的に決めていくことができればいいかなぁと思っています。
技術を選定するのはとても難しく正直これで良いのか全くわからないまま手探りでやっているので、本当なんとも言えませんがちょっとずつ勉強して行けたら良いなぁと思います。
ここまで読んでいただきありがとうございました！少しでもお役に立てれれば嬉しいなぁと思います。（いつもいろんなエンジニアさんが書いてくださった記事に助けてもらっていますので...！）
それではまた次何かしらの記事を書いた時にお会いできることを？楽しみにしています...！