Laravel Meetup Tokyo Vol.11で「Laravelを使った既存WebサービスのAPI化」について発表してきました

laravel-meetup-tokyo.connpass.com

発表してきました!

資料はこちらになります。

発表してどうだったか?

個人的に凄い良かったです。

何が良かったかというと、発表後にハッシュタグで#LaravelTokyoで見てたのですが、「複数DBにこそリポジトリパターンを活用したほうがいい」とか、「その設計だとテストを書く際に大変なのでは?」などの指摘を頂いて、改めて「自分の今の実装パターンにはメリットもあるが、デメリットもあるのだと」再考する機会を得ました。

togetter.com

というのも、社内でLaravelを本格的に活用して開発して人が多くはなく、自分も手探りな状態で「これで本当に正解なのだろうか?」という確証はない状態で日頃開発しています。

そう言った意味で自分の発表はLaravelを使った設計の1つの解答例として発表してみたのですが、これはこれでデメリットとメリットがあるのだと気づいたのが、個人的に大きな収穫です。

自分が発表したAppServiceに切り出す手法は確かにディレクトリ階層で見たときに、どのサービスクラスがエンドポイントの役割を持っているのかを判断でき、他のエンドポイントでも使い回しができるメリットがある一方で、Contorllerでの役割を単純にサービスクラスに切り出したただけのと、1つのエンドポイントのテストでGET、POST、PUT、DELETEを集約してしまうデメリットが発生して可読性は下がります。

なので今後の課題としては、各AppServiceに切り分けなくても責務を分担できる実装パターンと、テストをどうするべきか?に焦点を当てて実装を考えて行こうと思います。

設計に強くなりたい

自分の例ではControllerが段々肥大化してくる為、それを避けるためにAppServiceとして切り出す手法を取りましたが、それは今の自分の環境での対応であって、もっと良い分け方というか、設計があると思います。ただ、現状自分にはその視点が足りてない為、勉強会に参加してアプリケーション開発における設計について学んで強くなりたいなと思いました。

後今回は発表後に懇親会の時間があまり取れなかった為、他の参加者の方々と設計や責務の分け方についてお話できなかったので、次回の懇親会の際にそこら辺の話ができればと思います!

こう...もっと「皆さんどうやって責務分けているですか~!、どんな実装パターン導入してるんですか〜！」という話を懇親会で聞けなかったので、次回は積極的に絡みに行こう。
— えんどぅー (@Fendo181) September 14, 2018

最後に宣伝

2019年2月16日(土曜日)にLaravel JP Conferenceがあります！！！

conference2019.laravel.jp

現在スポンサー募集が始まったばかりで、スピーカ募集は10月頃だと思うので応募して下さい〜！よろしくお願いします！

Laravel JP Conference 2019のスポンサー募集が開始いたしました！
たくさんのご応募お待ちしております！

ご応募は以下のURLからよろしくお願いいたします。https://t.co/sqvDIk0pD0 #laraveljpcon
— LaravelJPConference (@laraveljpcon) September 17, 2018