この記事はPHP その2 Advent Calendar 2020の19日目です。
はじめに
PHPに限らず、開発において必要な機能をゼロから実装するのではなく、既存のパッケージを使って実装の工程を短縮するというのは、エンジニアなら誰しも経験することだ。しかし、GitHubでもスターが1K超えのパッケージならいざ知らず、スター二桁程度のマイナーパッケージを使うのは躊躇する。今回は、とある開発においてマイナーパッケージを使った結果どうなったかを記す。
発端
とあるサービスのリニューアル案件において、GraphQLベースのサーバーからデータを取得する必要があり、本来であればフロントエンド側でApolloあたりのメジャーパッケージを利用できれば良かったのだが、一旦結果をバックエンドで受けてからviewを出力する設計のほうが後々メンテナンスしやすいという結論に至ってしまった。このため、急遽バックエンド側で使用できるGraphQLクライアントが必要になった。
Guzzleをベースにして書いても良かったのだが、Githubで検索したところ、euautomation/graphql-clientというクライアントパッケージが見つかった。スター数は当時20前後。さて、これを使うかどうか私は悩んだ。
採用に至るまで
コードをチェックし、テストも一通り用意されていることを確認した。マイナーパッケージの場合、いつメンテが放棄されるか分からないので、いざとなったら自分でメンテする必要がある。今回はその点を判断基準として採用することを決めた。
採用から2年・・・
リニューアル案件を無事リリースし、そこから約2年が経過したことで、使用しているFWのバージョンアップが必要になり、それに併せ諸々のパッケージも更新することになった。しかし、本パッケージは恐れていた通り、アーカイブこそされないもののメンテされていない状態となっていた。結果本パッケージのcomposer.jsonが、Guzzleのひとつ前のバージョンである6.x止まりとなっていたため、FWや他のパッケージが要求する7.xに対応できなかった。
このためリポジトリをforkし、composer.jsonの記述を変更したPRを出したが、マージされることはなく、結局forkしたリポジトリをcomposerでrequireして対応することになった。
まとめ
マイナーパッケージとはいえプロジェクトを効率的に推進するために必要であれば、導入すべきという気持ちは今も変わらない。しかし、こういった残念な結果になることが多々あるので、自分自身がメンテナンス可能かどうかという判断基準が重要である。