依存ライブラリを減らす

V
6 min readOct 9, 2023

自社主力製品(以下自社製品)の依存ライブラリを減らしたので、雑に書いていきます。

もともと、自社製品の依存ライブラリは多くありません。Erlang/OTP というマニアックな言語で書かれていることもあり、多くの依存ライブラリは自前で書いています。

自前ではない依存ライブラリは JSON、JSON スキーマ、HTTP サーバー、HTTP クライアント、Raft などです。

今回は HTTP クライアントをライブラリ依存が少ないライブラリに変更し、さらに JSON スキーマを Fork し、依存しているライブラリを減らしました。

HTTP/1.1 クライアント Hackney の削除

Hackney は Erlang の HTTP/1.1 クライアントです。作者は gunicorn の開発者でもあります。

Hackney 簡単に使えて、機能が多いため、悪くないライブラリなのですが、思いのほか罠やバグが多く、たまに苦しめられることもありました。

今回は一念発起して、すでに HTTP/2 クライアントとして利用している Gun という HTTP クライアントに切り替えることにしました。

Gun は低レベルな API のみを提供しているため、HTTP Proxy 周りや証明書検証周りを自分で組み立てる必要があり、この辺りの実装と検証コストが高く Hackney を使い続けてきました。

ただ、Hackney は依存するライブラリが多く、さらに最近では積極的にメンテナンスされていないというのも理由がありました。

Hackney から Gun に切り替えるだけで依存ライブラリが 7 つ減るというのも大きかったです。

- {<<"hackney">>,{pkg,<<"hackney">>,<<"1.19.1">>},0},
- {<<"idna">>,{pkg,<<"idna">>,<<"6.1.1">>},1},
- {<<"metrics">>,{pkg,<<"metrics">>,<<"1.0.1">>},1},
- {<<"mimerl">>,{pkg,<<"mimerl">>,<<"1.2.0">>},1},
- {<<"parse_trans">>,{pkg,<<"parse_trans">>,<<"3.4.1">>},1},
- {<<"ssl_verify_fun">>,{pkg,<<"ssl_verify_fun">>,<<"1.1.7">>},1},
- {<<"unicode_util_compat">>,{pkg,<<"unicode_util_compat">>,<<"0.7.0">>},1}]}.

JSON Schema ライブラリ Jesse の Fork

Jesse は Erlang で書かれた JSON Schema ライブラリです。HTTP API のバリデーションに利用しています。定期的に Pull-Request を送っていたのですが、メンテナンスがほとんどされていないことやタグも積極的に打たれないため、Erlang のパッケージシステムである Hex から利用する事ができません。

そのため、Erlang/OTP 26.0 が出たタイミングで自社で fork をすることにしました。

かなり大幅にコードを書き換えました。JSON Schema は対応している最新版である Draft 6 のみに対応。さらに Erlang/OTP やビルドツール rebar3 も最新版にのみ対応。CI やテストが通らなくなっていたのを修正、というか書き直しました。

古いライブラリのため OTP で対応した機能を使っていなかったり、実質使われていないライブラリを削除しました。

これにより依存ライブラリを 2 つ減らすことができました。

- {<<"jsx">>, <<"D12516BAA0BB23A59BB35DCCAF02A1BD08243FCBB9EFE24F2D9D056CCFF71268">>},
- {<<"rfc3339">>, <<"1552DF616ACA368D982E9F085A0E933B6688A3F4938A671798978EC2C0C58730">>},

Fork に対する考え

個人的には企業なのであれば、積極的に Fork して良いと思います。実際、自社では Erlang/OTP すら Fork して運用しています。

Fork することで、Pull-Request を取り込んで貰うためのコストをあまり払わなくてイイというのもあります。もちろん Pull-Request 自体は可能な範囲で出すべきですが、依存ライブラリを減らしたり、Erlang VM の対応バージョンを上げるといった対応は取り込む側もめんどくさいと思います。

ライブラリの依存を減らす

ライブラリの依存を減らすのは、問題が起きる確率も減らす事になると考えています。そのため、可能な範囲で依存するライブラリを減らしていくというのは重要です。

まとめ

自社製品の依存ライブラリを、これ以上は削れないところまで削ったので、かなり満足しています。

--

--