.envを活用して単一のLaravelプロジェクトで複数のサービスを切り分けてみる
当ブログをご覧頂きありがとうございます。
エンジニアの杉山です。
今回は表題の通り、Laravelのカスタマイズに関して書いていこうと思います。
Laravelは非常に使いやすく、柔軟なフレームワークで弊社の幹事シリーズでも使用しています。
ただ、構造的に複数のサービスを同居させやすいような構成にはなっていません。
しかしながら、殆どは共通機能による実装がメインとなっていて、一部だけが異なるようなサービ
スを展開したいことがあると思います。(弊社の幹事シリーズもそうですw)
ポイントとなるのは共通機能をどのように扱い、差分をどのように管理するかになると思います。
取れる手法としては
- APIに切り出して管理する
- Git SubmoduleやSubtreeで管理する
- Composerを使用してPrivate Repositoryとして管理する
- 同一のプロジェクト内で複数のサービスを管理する
などがあります。
それぞれにメリットがあると思いますが、今回は 4 のパターンについて考えてみます。
(個人的にはソースが一つのプロジェクトに纏まっていると管理しやすくて好ましいです。)
.envにサービス毎に変化する項目を纏める
Laravelのプロジェクトでは基本的に環境毎に変化する項目を.envファイルで管理します。
(DBの接続定義やセッションの設定など)
そこで、サービス毎に変化する項目(=環境毎に変化する項目)を纏められれば管理上もシンプルで
見通しも良く出来るのではないかと考えました。
Route設定を.envから読み込むようにしてみる
複数のサービスを管理する際に分けたい設定としてRouteがあります。
RouteServiceProviderから必要なファイルが読み込まれており、以下のような実装です。
routes/api.phpやroutes/web.phpは文字列で与えられている為、ここを.envからの読み込みに変更
します。(直接.envを読み込むよりconfigを介した方がまとまりが良くなります)
これで.envの設定に応じてRoute設定が切り替わるようになりました。
モジュールを.envから読み込むようにする
AppServiceProviderなどの各種プロバイダーもサービスによって微妙な差異が出ることもあるので
はないかと思います。
基本的なProviderは以下のようにconfig/app.phpで設定されています。
このregister()とboot()に対応する関数を持つクラスをサービス毎に用意して、ここからその関数を
呼び出すように変更してみます。
まずはインターフェースを定義して、共通の呼び出しが出来るようにします。
続いて、AppServiceProviderにインターフェースをベースにクラスをインスタンス化する処理を追
加します。
.envにAppRegistrantを継承したクラスのnamespaceを定義して、configから参照できるようにし
ます。あとはApp\xxxx\AppRegistrantに任意の処理を記載すればOKです。
あとはこのパターンで分けたい設定を.envと連動するようにしていけば、.envをベースにして共通
部分とサービス固有の部分を同居させつつ、Laravelの機能をうまく活用できると思います。
まとめ
LaravelはPHPのフレームワークとしては非常に使いやすく、エコシステムも充実しているのでデフ
ァクトスタンダードと言えるのではないかと思います。さらにカスタマイズもしやすいので少し工
夫をしてあげると色々な使い方が出来ます。今回の内容もぜひ試してみて頂けると幸いです。
ここまでお読み頂きありがとうございました！
ユーティルでは共に「デジタルを広めて日本の中小企業400万社を変革する挑戦」をしてくれる仲間を募集しています。興味を持って頂けましたら軽い気持ちでお話だけでも聞きに来て頂けると幸いです。
ではまた次のブログでお会いしましょう！