Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Phoenix LiveViewをプロダクション利用してみた所感
Search
mokichi
May 18, 2022
Programming
3
910
Phoenix LiveViewをプロダクション利用してみた所感
mokichi
May 18, 2022
Tweet
Share
More Decks by mokichi
See All by mokichi
Elixir以外の言語もよく使うエンジニアが考える、Phoenix LiveViewの使いどころ
mokichi
1
340
Rubyistから見たElixir
mokichi
1
420
動的画像変換サービス「imagepix」のご紹介
mokichi
1
250
Phoenix1.6で標準搭載されたLiveViewに入門してみよう
mokichi
0
220
Ractorが出たからRubyの並列処理をおさらいする
mokichi
0
730
WebエンジニアのためのKubernetesサクッと入門
mokichi
1
140
未来予知できない凡人の生存戦略
mokichi
0
67
Other Decks in Programming
See All in Programming
Golangci-lint v2爆誕: 君たちはどうすべきか
logica0419
1
290
設計の本質:コード、システム、そして組織へ / The Essence of Design: To Code, Systems, and Organizations
nrslib
10
3.9k
Ruby で作る RISC-V CPU エミュレーター / RISC-V CPU emulator made with Ruby
hayaokimura
5
1.2k
rbs-traceを使ってWEARで型生成を試してみた After RubyKaigi 2025〜ZOZO、ファインディ、ピクシブ〜 / tried rbs-trace on WEAR
oyamakei
0
140
“技術カンファレンスで何か変わる?” ──RubyKaigi後の自分とチームを振り返る
ssagara00
0
160
Embracing Ruby magic
vinistock
2
290
Rubyの!メソッドをちゃんと理解する
alstrocrack
2
380
UMAPをざっくりと理解 / Overview of UMAP
kaityo256
PRO
3
1.6k
複雑なフォームの jotai 設計 / Designing jotai(state) for Complex Forms #layerx_frontend
izumin5210
6
1.6k
Live Coding: Migrating an Application to Signals
manfredsteyer
PRO
0
120
Browser and UI #2 HTML/ARIA
ken7253
2
190
OpenTelemetryで始めるベンダーフリーなobservability / Vendor-free observability starting with OpenTelemetry
seike460
0
130
Featured
See All Featured
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Optimising Largest Contentful Paint
csswizardry
37
3.2k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
14
1.5k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Raft: Consensus for Rubyists
vanstee
137
6.9k
Fontdeck: Realign not Redesign
paulrobertlloyd
84
5.5k
Statistics for Hackers
jakevdp
799
220k
Making Projects Easy
brettharned
116
6.2k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
720
VelocityConf: Rendering Performance Case Studies
addyosmani
329
24k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
48
5.4k
Building an army of robots
kneath
305
45k
Transcript
Phoenix LiveViewを プロダクション利用してみた所感 2022/05/18 @ElixirImp#20 株式会社スマートアルゴリズム 齋藤 和也
自己紹介 名前:齋藤 和也 HN:mokichi 年齢:34歳 居住:東京都 出身:福岡県 🍜 Twitter:@mokichi_s12m 株式会社スマートアルゴリズム 代表取締役 複数社で技術顧問を務める
クラウドインフラを含むサーバサイド開発やDevOps が得意 Elixirを触り始めて4年ぐらい?
2022/02 WEB+DB PRESSデビューしました 🎉 WEB+DB PRESS Vol.127 特集2「作って学ぶPhoenix」 Elixirコミュニティのメンバーと共著 担当:第5章
LiveViewによるフロントエンドの開発
LiveViewの簡単な紹介
LiveViewとは • (ほぼ)JSを書かずにElixirだけでSPAを開発できる • 宣言的な記述ができたり、機能やUIをコンポーネントに分割できたりと、 現在主流になっているSPA開発の開発体験とかなり近い • 加えて、データの更新を各クライアントにリアルタイムに反映するといった、一般的 に面倒なことがとても簡単にできる •
「Twitterクローンを15分で作る」という動画が話題に https://www.youtube.com/watch?v=MZvmYaFkNJI (Phoenixの公式サイトに載ってます)
現在主流になっているSPA開発の問題点 • フロントエンドとバックエンドの両方を高いクオリティで対応できるエンジニアは稀 で、分業化が進みがち • ある機能を実装する際に、バックエンド側を対応しないとフロントエンド側が進めら れず、ボトルネックが発生する(逆のパターンもあり) 教えてくれ、PM。俺たちはあと何本APIを作ればいい? • OGPの設定が必要な場合のSSRや、JSのバンドルサイズが大きくなることによる
Core Web Vitalsの各指標の悪化に頭を悩ませがち
LiveViewの特徴 • (ほぼ)JSを書かずにElixirだけでSPAを開発できる ◦ フロントエンドとバックエンドがデータをやりとりするための APIを何本も作らなくていい (つまりAPIドキュメントも作らなくていい) • すべてのクライアントとWebSocketでつながっている ◦
状態をサーバに保持し、状態の更新をクライアントに反映させている ◦ ブラウザのCookieやLocalStorageのことを気にしなくていい ◦ サーバの負荷は当然増えるが、昨今はリソース調達が容易なためさほど大きな問題ではない
正式なお仕事として使ってみた所感 といってもレビューがメインでした...
どんなシステムを開発したのか • 企業の人がとある業務で使うためのSaaS(BtoB) • ユーザ向け画面と管理画面がある • 基本的なCRUDの画面がほとんど • 一部複雑なUIの画面がある
LiveViewの良かったところ • JSをほとんど書かず、ElixirだけでSPAを開発 ◦ APIを大量に作る必要がなかった ◦ フロントエンド/バックエンドを分業していなかったが、 LiveViewだけ触ればいいため コンテキストスイッチは少なかった(ように思う) ◦
業務で利用するサービスで、 JSゴリゴリみたいな要件がなかったというのもある • ReactやVue.jsといった人気ライブラリと似た開発体験 ◦ 宣言的な記述、コンポーネント分割 ◦ CSSに関する仕組みはないが、 Tailwind CSSを導入することでスタイリングの収拾が つかなくなるようなことはなかった ◦ CSSフレームワークを使わないのであれば、ほぼ Tailwind CSS一択な予感
LiveViewのハマりどころ • JSのライブラリと違ってサーバサイドで状態を持つため、ステートフルなシ ステムになって扱いが難しくなる ◦ データを更新しようとしたらすでに DBから削除されていた、みたいなことが起こる ◦ LiveViewが保持しているデータをそのままビジネスロジックに渡すのではなく、 APIを叩くときのよ
うにDBから再取得するようにしたほうが安心できる • ファイルアップロード周りのエコシステムが充実しておらず、自前実装が多 くなる(LiveViewだけの問題ではない) ◦ バリデーションやDB・外部ストレージとの連携など、他言語だと当たり前にライブラリがあるような ものの開発があまり盛り上がっていない ◦ 自前で実装すると、どうしてもバグや考慮漏れが発生しやすくなる
どんなときにLiveViewを選ぶのが良いか • 地図やグラフ、3DCGといった、JSのライブラリを使わないと実現が難しい ような機能が少ない場合 ◦ Hooksという機能を使えばJSとLiveViewを連携できるようになるが、そればかりになるなら JSで SPA作ったほうがいい(APIやWebSocketサーバはPhoenixで作れるよ!) ◦ ツール系のサービスや管理画面の開発とかだとすごく向いてそう
• Webアプリのみ提供する場合 ◦ スマホアプリを提供するなら APIを作って共通利用したほうがいい • 利用者の通信環境がそこそこ良いことが保証される場合 ◦ WebSocketでつなぎっぱなしになるため、通信環境が貧弱だとまともに利用できなくなる
LiveViewがこの先生きのこるには
適材適所とエコシステムの充実 • 何にでも言えるが、LiveViewにも向き不向きがあるため、 技術やチーム、サービスの特性を考慮して技術選定しよう ◦ 当然ながら銀の弾丸ではないが、使える範囲は思っている以上に広いと思う ◦ 採用実績を地道に作っていけば、次第に使われるようになっていくはず ... •
QiitaやZenn等への投稿やライブラリの開発でエコシステムを充実 させ、Elixir界隈を盛り上げよう ◦ 特に、ファイルアップロード系のライブラリは個人的に作ってみたい • そもそもLiveViewはまだバージョン1にも達していない(伸びしろ!)
もっとElixirでお仕事したいよぉ〜〜