概要
こちら3/18 に行われた下記のイベントに参加しました。
その際のメモや思ったことを書いていきます。
注意点
- 私はサーバサイドエンジニアなので、フロントエンド周りは私の知識不足で理解しきれなかった箇所がありました
- 感想はあくまで一個人の感想です(小学生みたいな感想しか書いてないです)
- 間違って理解している箇所もあるかもしれないので、そこはマサカリ投げていただけると嬉しいです
- 誤字脱字があるかもです
目次
- 会場提供のITプロパートナーズ様、飲食提供のULURU様からの会社/事業紹介
- 「グローバルstoreを利用する際はMixinではなくPlugin使った方がいいんじゃないか？説」 by レアジョブ様
- 「Laravelを本番環境にデプロイするまで」 by ULURU様
- 「SPAリリース後の問題とその対策」 by ITプロパートナーズ様
- 「アイスタイル特設サイトに置けるVue.jsの導入事例」 by アイスタイル様
- 「Laravel Queueの運用管理」 by オープンロジ様
- 「Monolith→MultiRepo→MonoRepoでのリポジトリ戦略」 by Scouter様
メモ、所感
1. 会場提供のITプロパートナーズ様、飲食提供のULURU様からの会社/事業紹介
- ITプロパートナーズ様、ULURU様からの会社やサービス、使っている技術の紹介
- 綺麗な会場と美味しい食事を用意してくださりありがとうございます！
- イベント運営にとっては「場所の確保」と「食事の確保」は本当に大変です
2. 「グローバルstoreを利用する際はMixinではなくPlugin使った方がいいんじゃないか？説」 @レアジョブ様
スライド
メモ、感想
- Vue.jsのMixinについて
- Vue コンポーネントに再利用可能な機能を持たせるための方法
- Mixinを使っている上で困っていること
- どこで定義されているかわからなくなる
- Mixinで定義しているのに、さらにimportしている
- 実行順序とかよくわからなくなる
- Mixinの代替策として
- Storeをプラグイン化して使おう
- カスタムディレクティブにstoreを追加する感じらしい
- 感想
- フロント初心者の身としてはまあまあ難しい
- ただMixinに似た課題はどんなシーンにもありそう
- その際にもっといいやり方はないかを模索することの必要性は改めて感じた
- Mixinは便利な反面運用が面倒そうというのを覚えておく
3. 「Laravelを本番環境にデプロイするまで」 by ULURU様
スライド
メモ、感想
- ローカル環境を作る
- Laradockで作成
- 諸々環境設定
- Elastic Beanstalkを使って本番環境の用意
- コンソール画面でポチポチ対応
- GitHubの設定
- こちらもGitHub管理画面でポチポチ設定したらしい
- CI/CDパイプラインをCircleCIで実現
- その前にAWSのIAM Role を設定
- その上でCircleCIの設定
- 諸々環境設定でハマったけどそれも一つずつ対処したらしい
- 感想
- GitHubで運用するなら真似したいお手本のような環境構築(弊社はGitLab)
- Laradockはどこまで有用なのかは少し気になるところ
4. 「SPAリリース後の問題とその対策」 by ITプロパートナーズ様
メモ、感想
- SPAにしたのはいいけど、その後出てきた課題とその解決策について
- 課題1 画面の表示が遅い
- SPAだから早くなるわけではない
- ちゃんと設計しないと遅くなることもあるとのこと
- 課題1に対して解決策
- 解決策1 データ取得のタイミングを変更
- 具体的にはSSRをしていたのを、ブラウザ側でCreatedしたらしい
- 上記処理に変更したのはメインコンテンツ以外の箇所(サイドとか)
- 解決策2 更新頻度の高くないデータはVueのBuild時に事前に取得する
- APIを叩く頻度を少なくする為の処置
- これを本当にするべき箇所かどうかは見極める必要がある
- 解決策2つで爆速したらしい
- 解決策1 データ取得のタイミングを変更
- 課題2 特定ページへのAPIが増えてきて遅くなる
- 運用していくとどんどん特定のAPIを用意していき、どんどん遅くなるらしい
- 課題2に対しての解決策
- APIをまとめる為の共通の仕組みを作ったとのこと
- 時間的制約からこのような処理をしたらしい(本来はAPIの設計をし直すべきとのこと)
- まとめ
- SPAではAPIのフロントエンドのライフサイクルを意識しないとダメとのこと
- でもSPAは作るのがとても楽しいからおすすめ
- 感想
- 銀の弾丸は存在しないことのいい事例
- 正直具体的なイメージが沸いてないですが、こうやって課題解決していくのは本当に見習いたいです
5. 「アイスタイル特設サイトに置けるVue.jsの導入事例」 by アイスタイル様
スライド
メモ、感想
- 特設サイトをVue.jsで作った時の話
- スパイクアクセスがあるとのことなの全部AWS上(CloudFront,S3,AWS Lambda, EC2)でできるようにした
- ただ静的ファイルにページ要素を埋め込む必要があるが、それが日毎に変わるので、日毎のディレクトリをコピペしていくスタイルにしないといけなかったらしい
- その辺りはgulpなどを使って少しでも楽にしたらしい
- 感想
- スケールアウトしやすいアーキテクチャがとても参考になりました
- でも特設サイトならではつらみがありそうだなあと実感
6. 「Laravel Queueの運用管理」 by オープンロジ様
メモ、感想
- コマンドクエリの責務分離
- 書き込みの場合はJob Queueを使っている
- オープンロジさんは書き込み処理はほぼQueueを使っているらしい
- JobQueueはLaravelで実装するとすごく楽とのこと
- jobを作ってdispatchするだけ
- Jobのモニタリング、ロギングをしていくには
- Laravel Horizon
- Laravel Telescope などがある
- Laravel Telescopeはあくまでdevelop環境でやるべき(本番環境で使ってpublicにロギングされているサイトがあるとのこと)
- 感想
- 書き込み処理はJobQueueでできるようにするのは1つの理想形な気がした
- ツールを使ってJobQueueをやるのは大切な気がした
「Monolith→MultiRepo→MonoRepoでのリポジトリ戦略」 by Scouter様
スライド
メモ、感想
- リポジトリ戦略
- 関連するユーザーが多い
- それぞれのユーザーで同ドメインの情報を扱う
- 重複コードの扱いが大変になってきたのを解消したい
- 様々なリポジトリ戦略を取り入れてきた
- Monolith
- いわゆる一般的な構成
- 問題点として、複数アプリケーションでコードのシェアができない
- MultiRepo
- 共通コードをパッケージ化
- 一見良さそうに見えるが、開発手順が煩雑になるという課題がある(バージョンが煩雑化する)
- 「ダイヤモンド依存関係の闇」があるらしい
- Monorepo
- 全ては一つのリポジトリへ
- パッケージという概念は残しながらもGitのリポジトリは単一化
- バージョンが単一化されるというメリットあり(MultiRepoの課題は解消される)
- コード解析が可能になるらしい
- ビルドやcloneのコスト増大というデメリットがあるらしい
- Googleなどの大手企業、LaravelなどのOSSでも使われているらしい
- 全ては一つのリポジトリへ
- 感想
- 難しい。。というよりあまり考えたことのない領域。。
- ただ今メインで改修しているのはMultiRepoだなあとか思ったりはしている
- そう考えたら課題感はわかった
- LaravelがMonorepoという例が比較的イメージしやすかった(確かにvendor配下に全てのソースコードが入っているので)