トップ > PHP > BEAR.Sundayを採用した理由

BEAR.Sundayを採用した理由

PHP 登壇 ソフトウェア開発 カンファレンス/勉強会

2019/04/02 下記の箇所を修正と追記

もちろん、それぞれ別のインターフェイスで実装すればいいじゃないかという話もあるとは思います

前置き


先日のPHPerKaigi2019で

「たった1人のAPI開発 BEAR.Sundayで解決した課題たち」という題目で発表させていただきました

BEAR.Sundayを採用した理由という内容で質問をいただいたので、自分のためにも改めて整理して、この記事にまとめました

ご質問いただきありがとうございました！




前提として

フレームワークを選ぶにあたって、比較対象はLaravelでした

CakePHPはほとんど触ったことがないので、最初から対象から外していました

Slimは経験あるが今回の規模とは合わないとおもい、こちらも最初から対象から外していました




学習コスト

BEAR.Sundayはもちろん学習コストはかかるのですが、Laravelも学習コストはかかると思います

自分自身もBEAR.Sundayでの本格的な開発は初めてだったのですが、

フレームワークの学習コストはBEAR.SundayとLaravelで大きな差はないと感じました

他の人が試行錯誤した記事等はLaravelに比べて少ないので、そこはデメリットだと思います


もう1つBEAR.Sundayの特徴として、フレームワークがライブラリを提供しないので、

必要なライブラリたちを自分たちで選択しなければなりません

HTTPクライアントはGuzzle, SQLクライアントはAuraSQLといったように、プロダクトにあわせて自分自身で選択していきます

ここのライブラリの選択は多少の経験がいるかなとは思うので、少しコストは高いかもしれません


試行錯誤した記事の不足やライブラリの選択等で苦労しても、

この苦労はコストではなく投資で、実装と運用の部分で回収できると思いました

(ここは自分の感覚なので保証は全くできません………)




それでもBEAR.Sundayを採用する理由

DI

リニューアルの案件だったので、旧APIとの互換性を保つことや、複数のインフラプラットフォームをまたぐ場合などに

1つのクラスに同じインターフェイスの異なる実装を注入したいことがあるなと思っていました

これがたしかLaravelでは、できないかやりづらかったと思います(もしできるよ！という場合は何卒ご教授ください！)

BEAR.Sundayではこれが 名前付き束縛 で柔軟に解決できるのがありがたかったです

https://bearsunday.github.io/manuals/1.0/ja/di.html

--- ✁ ---

(もちろん、それぞれ別のインターフェイスで実装すればいいじゃないかという話もあるとは思います)

↑も選択肢になるかとおもったのですが、インターフェイスが実装の詳細を知っていることになり、

実質的に実装に依存するかたちになるので、なし

--- ✁ ---

加えて、コンテキストで依存を入れ替えれるのも魅力的でした！

https://bearsunday.github.io/manuals/1.0/ja/application.html



AOP

標準サポートしており、キャッシュ、トランザクション、バリデーション、ログで活用でき、実装も運用もスムーズにできると思いました

特にAOPを活用したBEAR.Sundayのキャッシュはクライアントキャッシュにも対応していて、とても魅力的でした

https://bearsunday.github.io/manuals/1.0/ja/resource.html

https://bearsunday.github.io/manuals/1.0/ja/http-cache.html



バージョンアップのコスト

Laravelを使っていたときにバージョンアップに少し苦労したことがあり、

社内の他のプロジェクトでも苦労しているのがいくつかあったので、そこが少し気がかりでした

新規事業なのに、そこは気にしなくてもいいのでは？というのもあると思います

ただバージョンアップに苦労しなくても済むのであれば、それにこしたことはないかなという思いです


補足

https://bearsunday.github.io/manuals/1.0/ja/version.html

フレームワークのコアパッケージはユーザーコードに変更が必要な破壊的変更(breaking change）を行いません。



json_schemaとApi.Doc

Laravel + Swaggerで過去に苦労していた、APIとドキュメントの整合性を今回はどうしても解消したかったです

BEAR.Sundayはバリデーションも含めて、json_schemaとApi.Docでやりたいことが実現できることが調査でわかっていました

自分の知識不足、調査不足の可能性は多いにあり、

Laravel + SwaggerでもAPIとドキュメントの整合性やドキュメントとバリデーション, テストなどできるかもしれません

先にjson_schemaとApi.Docと実現できる確信を持てたので、BEAR.Sundayを採用しました




社内事情

自分から誰かに引き継ぐとなっても、社内にはBEAR.Sundayに詳しいメンバーが多いので大丈夫という社内事情もあります…！

郡山さんも社内にいらっしゃたので、その点は弊社独自の部分だとは思います