先日、Laravel JP Conference 2019に参加してきました。今回は参加したセッションの紹介記事となります。
パッケージ開発のやり方と利点についての発表です。
発表者は後藤知宏(@_mikakane)さん
資料はこちら
パッケージ開発というと難しそうというイメージがあるかもしれませんが、再利用を前提としないでプロジェクト内で使用する前提であれば多くの設定を省略することができ、簡単に開発できるようになっています。
通常のLaravelでできることはたいていできます。
アプリケーションの特定の機能をパッケージ化して分けると以下のようなメリットがあります。
機能を別パッケージとして分ける上でappでしかできないことに注意しましょう。appでしかできないこととしては以下のようなことがあります。
アプリケーションの根本的な制御は、appで行い、各種ロジックはパッケージで行うのが良いでしょう。
デプロイの種類、アンチパターン、Laravelでの注意点や周辺ポイントについての発表です。
発表者は鶴島 剛(@t_tsuru)さん
資料はこちら
Laravel職人にとっての理想のデプロイとは、例えば以下のような条件があります。
デプロイの種類をざっくり分類すると以下の3種類に別れます。
あるエンジニアが一人だけのスタートアップで、Laravelを利用してサービスをEC2でリリースしたというシナリオで、問題点とどうすればよかったかを紹介しています。重要なポイントは以下のとおりです。
1台のサーバで稼働する前提で作らないこと、永続データはすべて切り離せる状態を作ることが重要です。例えば、
具体的なパフォーマンス改善方法に関する発表です。
発表者は富所 亮(@hanhan1978)さん
資料はこちら
「遅い」は主観であり個人差があるため比較できない。改善のためには、コンテキストや数値を明確化する必要があります。
ウェブアプリケーションは様々な要素で構成されています。まずは、自分の領域の狭さを知る必要があります。
ウェブアプリケーションのレイテンシーはユーザ側/サーバ側のネットワーク、ユーザ側/サーバ側のプロバイダ、光ファイバー等の伝送媒体に分けることができます。例えば大陸間のネットワーク通信のような原因で遅い場合は、ウェブアプリケーションでは改善できないのでCDNなどのソリューションが必要となります。
ウェブアプリケーション全体のレイテンシーを確認して、ウェブアプリケーション単体の応答時間に原因があるとわかってはじめてチューニングを開始できます。
しかし、ウェブアプリケーション単体のレスポンスが悪かったとしても本当にウェブアプリケーションが悪いとは言い切れません(同一サーバ上の別プロセスがリソースを消費しているケースが有る)
メモリ使用量、CPU使用率、ディスクIO、ネットワークIOなどの継続的な計測が必要です。この段階では、プロセス単位でのCPU使用率やメモリ使用量などから、どのプロセスがボトルネックになっているのかを特定します。
ウェブサーバのログからレスポンスタイムが遅いURLを探します。
コードの実行にどの処理がどのくらい時間がかかっているかを測定します。
レイテンシーの中でボトルネックになっている処理をチューニングしていきます。ここではボトルネックの改善→レイテンシーの確認を繰り返しループさせます。
Laravel+Vue.jsでAPI開発を効率化させる方法の発表です。
発表者は松本 宏太(@kotamats)さん
資料はこちら
Vue.jsのコードとLaravelのコードが同一リポジトリに存在する場合、デプロイに時間がかかるためフロントを少し修正した場合でも毎回デプロイに時間がかかっていた。リポジトリを分けることでデプロイが早くなりました。
Vue.jsとLaravelのリポジトリを分ける上で、以下のような注意点があります。
Laravel標準のAPIテストが優秀。拡張してspecファイルを出力するようにした自前のプラグインを使っている。
Laravelの重要な機能であるServiceProviderとDIに関する初学者向けの発表です。
発表者は前田 和人(@chiroruxxxx)さん
資料はこちら
Laravel JP Conference 2019の参加レポートでした。どのセッションも面白く、特にパッケージ開発は取り入れていきたいと思いました。