nodejsで画像ファイルのサイズ変更をする処理に時間を費やした話

何かを作っている時間が至福の時間である、ユゲタです。 ついこの間まで、wordpressが使いづらかったので、自分で使いやすいPHPフレームワークを使って、実際に仕事でも活用していたんですが、 最近はもっぱらNodejsになってしまいました。 そして、Reactの使いづらさを克服しようと思って、フレームワーク作りに勤しんでいますが、Nodejsって本当になんでもやりたいことのライブラリがそろっていて、 めてゃくちゃ今どきの環境であることを体感できます。 そんなフレームワーク作りの中、サーバーサイドで、画面サイズに応じて画像ファイルのサイズを自動的に縮小するような処理を追加しようと思った時に、休日をまるまる費やしてしまったという話をします。

Nodejsの画像リサイズ処理は「sharp」一択しかない

2022年1月時点での話ですが、画像のリサイズができるモジュールを探してみたところ、次の４つほど見つけることができました。

1. sharp
2. Imagemagick
3. jimp
4. lwip

実はこの全てのモジュールを一旦組み込んで画像リサイズ処理を作ってみたんですが、どれもそれぞれ別の課題が潜んでいたことが判明。

sharpの問題点

node_modulesにインストールされたモジュールが、CPU依存するもののため、M1 macでインストールしたsharpモジュールをDockerを立ち上げた際にnodeファイルを実行すると、エラーが出てしまう。

Imagemagickの問題点

基本的にImagemagickをインストールして、そのライブラリをコントロールするコマンド実行型モジュールなのだが、 Imagemagick自体がM1 macに対応していないらしく、まともにインストールできないので、NG

jimpの問題点

CPU依存も無く、少し処理が遅くはあるが画像リサイズはできるのだが、webpフォーマットに対応していない為、NG

lwipの問題点

オワコンのため、NG 上記の結果から、画像フォーマットがwebpにも対応していて、画像変換自体に問題がないsharpを使うのが賢明と判断した。

CPU依存をどう対応するのか？

これは、dockerを利用している人がみんな行っている、node_modulesを、共有しないようにして、Docker内で別のnode_modulesを構築することで、解決できるという事で作業を行うことにした。 最初は、.dockerignoreファイルを作って、node_modulesを除外すればいいだけと思っていたけど、docker-composeを使った.dockerignoreって、全く言うことを聞いてくれないので、 この方法は除外。 docker-compose.yml内でvolume指定している以上、どうしても、node_modulesがリンクされてしまうのだが、 裏技として、からフォルダを作って、node_modulesをその空フォルダで上書きリンクしてあげることで、空のnode_modulesフォルダリンクをすることに成功しました。 さらに、Dockerfileで、npm runしてあげることで、無事にM1 macとDockerのどちらでも、便利にnodeファイルが実行できるようになりました。

開発者として感じたこと

オワコンモジュールに振り回された事は、仕方がないかと思ったが、環境に応じた処理依存をしてしまうモジュールは何とも使いづらく、マルチプラットフォーム環境で、起動処理時に振り分けをする程度の事をしてくれてもいいのに・・・と感じてしまった。 確かに、無駄な処理をいれて、処理速度が遅くなるのもわかるが、それであれば、開発環境、本番環境のような切り分けをオプション設定できるとか、いろいろとやりようがあるはず。 あまり無理な要望をするつもりはないが、今どきの開発環境にもこだわってほしいと個人的には思った上で、自分の作るシステムは、そうしたUXが行き届くようにしなければ・・・と改めて気付かされたモジュール構築話でした。