Silex の役割の終焉 (the end of silex)
以下は上記ブログの意訳です。(google翻訳結果の日本語の不自然さを修正程度)
--- ここから ---
Symfony 4の世界でSilexはどうですか？ここ数ヶ月、Flex*1で作業する際の練習として私はこれまでにSilexで構築したアプリをSymfony 4に移行しました。結論として、Symfony 4はSilexのように利用することができると感じています。
Symfony 4とFlexを使用すると、Silexを使用する場合と同じように軽量になります。どの機能を有効または無効にするかは完全に制御できます。両方のアプリケーションのディレクトリ構造は、深さが限られているのも似ています。Symfony 4は、エコシステムという点で優れています。Symfony 4で何か必要なときはいつでも、その必要なバンドルがすでに存在している可能性があります。また、主要なものについては、レシピ*2によって統合が容易になります。Symfony 4の大きなセールスポイントは、HTTPメッセージ用のルータとクラスを、鐘や笛などを含むモノリスへと非常に簡単にアプリケーションを拡張できます。
Symfony 4はあなたのすべてのサービスをほぼ自動的に設定するので、Silexから移行することも簡単です。だから、Pimpleからの移行はSymfonyの設定で置き換えなくてもほとんどすべてのコードを削除することができます。
これらすべての理由から、私は Silex がもう必要ではないと思います。そこで、私たちはSilexでSymfony 4をサポートしないことに決めました。少なくとも、3.4で追加された新機能は追加しません。Silexの現在の安定バージョンは、バグやセキュリティ問題のためにまだメンテナンスはされますが、2018年6月までとします。
Symfony 4とFlexの統合されたコミュニティを持つことはすばらしいニュースであり、過去数年間でのDX体験を取り巻くすべての作業の暗黙の目標です
--- ここまで ---
ここからはポエムっぽい内容ですが個人的な感想です。
Silexは PHPで Ruby の Sinatoraのようなマイクロフレームワークっぽい記述で書けるフレームワークとして登場しました。 「これは楽しい！」と思い、ドキュメントを翻訳したり色々使ってみたりしていました*3 また、WEB+DB PRESS にも紹介記事を書いたりもしました
ただ、マイクロフレームワークとして使えるというだけで、Symfony Componentが利用されていたり、決して軽量なフレームワークというわけでもないですし、それなりの規模のアプリケーションを構築しようとすると「それなんて オレオレSymfony？」みたいになるというのもあり、なかなか使い所が難しいフレームワークでもありました。
個人的にはマイクロフレームワークで何か書くのであれば、Slim, Lumenを選択するほうがマッチすることが多かったと思います。
本当に欲しかったのは Pimple だけで、Pimpleだけを使うという判断もありました。 色々とSilexからは勉強させてもらったと思います。
今後移行するのであれば、Symfony4 へ移行させることでフィットすることは多いと自分も思います。 というのもSilexを選ぶ場合は、それなりに複雑なアプリケーションを構築したい場合に選ばれている印象があるからです。
もし、本来のマイクロフレームワークっぽくさくっと使いたいのであれば、Slimや Lumenで書き換えてみるのも結果すっきりするかもしれません。
もしくは APIサーバーを書きたいのであれば BEAR.Sunday がしっくり来るかもしれません。 もしくは 一度 PHPを離れて Goの goji で書いてみるとか。
Silexのポエムブログが意外となかったので連休ということで書いてみました。
