Symfony3.4以降 -- なぜ LaravelでなくSymfony ? --

こんにちは、株式会社CHAPTER-THREEの井川です。

Symfonyの日本語記事の少なさを少しでも解消し、Symfonyの魅了を少しでも届け、
ユーザーを増やすための記事です。

前提

Symfony の言語仕様が今の形になった 3.4以降。今は、PHP8.0のAttribueに対応した6.0をベースに話を進めます。

普段業務でやっているのですが、もし詳細に間違え等ありましたら直しますので教えてください！

良質の資料の紹介から。

僕は、Symfonyのことを調べるのは、ほぼこの３サイト。
英語サイトは、ブラウザの翻訳の操作に慣れるとなんとかなります。

• Symfony日本語入門【公式】
  ここは、読み物として楽しい。やっぱり日本語だと読みやすい。

• Symfony公式サイト[英語]
  仕事の調べ物はほぼこの公式サイト。上記の日本語入門を読んでおけば、どこを調べればいいのか大体検討がつきます。

• Symfony チュートリアル[英語]
  ここは、メルマガ登録してあって、来るメールは英語だが、タイトル見て面白そうな機能な場合、チュートリアルなのでコード見れば、どう作るかがわかります。

---

Symfonyを私が選んだ理由

背景

私は、小学校5年生の時にその当時「マイコン」という言葉が生まれた頃。
当時BASIC、マシン語のプログラムを書いていて、学生自体は言語オタク(アセンブラ,FORTRAM,C,C++,LISP,Prolog,Modula-2,Smalltalk,Pascal。COBOLだけやってない)、社会人になって20年以上、この業界でBtoBのマルチベンダーのSIer、システム屋をやってます。

仕事はMS系だったんですが、仕事で本格的にWebも含めたBtoBシステムを組むために、言語選択とフレームワークを選択する事になりました。

選定条件

• システム屋がWebを始める場合、Wordpressと連携するシステムが組めたほうがいい。
• システム屋がWebを始める場合、EC-CUBEもカスタマイズ出来たほうがいい。
• ある程度大規模なシステム、複数人数での開発にも耐えられるようにしないといけない
• Javaは開発コストがかかるし、ORACLEに買収されてから、ちょっと雲行きも怪しいので選択肢からは外す
• 納めた後、改修や追加案件で長くお客様と付き合いたいので、長く信頼できる視点で選択をする

言語の選択肢

• Python

  • ⭕️ AIもやりたいし、流行っているので有力候補。
  • ❌ WEBがとてつもなく遅かった。特にマルチユーザーや大きなアクセスには耐えられそうもない

• Go

  • ⭕️ Googleが開発したので、すぐには消えないし、悪くないかと。
  • ❌ 資料がないし、新し過ぎで歴史もないので、言語仕様の変更が怖い

• ASP.NET

  • ⭕️ .NET系なので、順当と言えば順当。仕事でも使っていた。
  • ❌ Microsoftが迷走してるし、オープンソースの恩恵がほぼ受けられないと思った。

• PHP

  • ⭕️ 一番社内に馴染みがある。WORDPRES,EC-CUBEともにPHPなので。
  • ❌ 複数での開発や若干のパフォーマンスが気になった。

• Node

  • ⭕️ サーバーサイドもクライアントも同じ言語というのは魅力。
  • ❌ そのそもJavascriptのソースがメチャクチャになりがち。仕様(バージョン)乱立の管理ができる気がしない

• Ruby

  • ⭕️ 特にRuby On Railが定評がある
  • ❌ Ruby On Rail以外の話を聞かない。10年前ならRubyは有力だったが、今から始めるとなると躊躇

PHPを選択❗️

結局、開発スピードとフレームワークの多さでPHP。

色々デメリットは理解していた。
特に変な書き方が出来ることはフレームワークの選択で回避出来ると判断。

パフォーマンスもちょっと気になったが 8.0 からJITが入ると聞いていた。

また、弊社はソフトだけでなく、インフラも行うので、サーバーセッティングのことも含めると、PHPが一番。

何より、(WORDPRESSのおかげだが)全世界的に一番のユーザーを誇る信頼性で決定。

PHPのフレームワークの選択肢

• Laravel

  • ⭕️ AWSやVueなどの親和性も高いし、抜群に流行ってるし勢いがある。
  • ⭕️ 日本語の資料も多い。1番の有力候補
  • ❌ 1番勢いがあるってことは、言語仕様も大きく変わる可能性もある、、、

• Symfony

  • ⭕️ 大規模開発は問題なさそう。ec-cube社が選択した理由一番気になる。
  • ⭕️ LTSがちゃんとしてる
  • ❌ 学習コストが高そう。フロントエンドにはVueを使いたいが親和性は？

• CakePHP

  • ⭕️ とっつきやすく複数人開発を行う学習コストが一番低そう
  • ❌ 大規模サイト対応できるか不安？Laravelに勝てるか？

Symfony を選択

LaravelもSymfonyがベースという事と、ec-cube社がec-cubeは3.xではSymfony2、4.xからSymfony3.4を選択していた信頼度で、大きくSymfonyに傾いていた。

最後的に、Laravelでnamespaceが(その当時)使えなかったことで。

• 複数人での開発がしにくい -> 管理もしにくい -> バグがでてプロジェクトが炎上
  と判断。

また、言語仕様が固まってなく、言語仕様もまだ大きく変わると予想

• Laravelで納め -> 追加案件受注 -> バージョン上げるのが大変 -> 全社の言語バージョン管理が大変

Symfony を調べれば調べるほど、まぁちゃんとしてるし、信頼もできる。

「学習コストが高い」って噂は、どうやら高機能、というよりあらゆるケースを考えて作られてるので、本当の意味で全体把握をするのが大変。ということだと理解。

必要ない機能は、ある程度無視していいし、必要な時に調べて出来ればいいの。PHPは最悪ソースが見れるので、解析可能。

Symfony自体がパーツ化されているので、Laravelを筆頭に知らないうちにSymfonyを使っているものが多い。

「フレームワーク」と言うものを、自分含め社内に浸透させるのに、純粋にSymfonyはとてもいい教材でもある。

結局、僕のSymfonyに対する理解は

• 「やりたいことはSymfonyだけで全て出来る」
• 「純粋にFrameworkとしてよく考えられて作ってある。美しい」
• 「元から複数人開発や大規模開発を想定してる。当然メンバー内の初心者もいる」
• 「バージョンアップの計画もはっきりしているし、すでに隠れも含めるととてつもないユーザーがいる」

. . . ということは . . . 3.4以降なら納めた物のバージョンアップも楽なはず❗️

結果、Symfonyを選択しました。
当時Symfony 3.4が全盛で4が出てきた頃だったかなぁ

実際5年使ってみて

　まだ、Laravelは横目で見ているが、Symfony を選択して正解だった。

　使い始めに先ずやったのが、twigの base.html.twig を stisla ベースに作成。

　このことで、とりあえず見栄え良く、お客様に手軽にサイト構築して納める。また、追加で言われたことをちょこちょこっと追加納品している。

　バージョンに関しては3.4から使い始め、現在6.1。 5.4あたりで認証の仕組みが変わった時にはちょっとビビったが、それ以外は、とてもスムーズにバージョンアップを行えてる（と言うかいつでも出来そうだから、放置もちょこちょと増えて来ちゃった）

今では色々出来るようになった。

フォーム認証、Slack、IoTとの連携、CSVダウンロード、PDF、Vue、API Platform、メール、MySQL、MS-SQL、ストアドとEntity融合、複数DB Server接続、お手軽メモリ認証、.NETサイトからの独自認証、AWS、S3、GraphQL、Shopify連携、NextEngine連携、各種モールAPI連携などなど。
　

Symfonyで仕事をすると、
全ての経験が積み重なって自分達に技術力が貯まっていってる感がある。

これが一番選んで良かったことかな。嬉しい。
　

もう公式のSymfony.comで慣れてしまったが、やっぱり日本語資料が欲しい。
Webに出て来る日本語資料は結構古かったり、もっといい方法があるのに。。。

ということで、Symfonyの記事を一生懸命書いていこうかと。
普段業務でやっているのですが、詳細の間違え等ありましたら直しますので教えてください！

もし記事のリクエストとかももらえたら、わかることであれば頑張って書きます。

アクセス増えて来たらYoutubeもやるぞ！！！