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
660
Phoenix LiveViewをプロダクション利用してみた所感
mokichi
May 18, 2022
Tweet
Share
More Decks by mokichi
See All by mokichi
Rubyistから見たElixir
mokichi
1
300
動的画像変換サービス「imagepix」のご紹介
mokichi
1
210
Phoenix1.6で標準搭載されたLiveViewに入門してみよう
mokichi
0
150
Ractorが出たからRubyの並列処理をおさらいする
mokichi
0
500
WebエンジニアのためのKubernetesサクッと入門
mokichi
1
76
未来予知できない凡人の生存戦略
mokichi
0
36
Other Decks in Programming
See All in Programming
デフォルトにして至高、RubyMineの大好きな所
ruzia
0
190
はてなにおける CSS Modules、及び CSS Modules に足りないもの / CSS Modules in Hatena, and CSS Modules missing parts
mizdra
6
890
Front-end application development, Symfony-style(s)
dunglas
2
2k
[技育CAMPアカデミア]アイディアを形に!【超入門】スマホアプリ開発〜リリースまでの流れをご紹介
teamlab
PRO
0
350
TYPO3 v13 – The road to LTS: What's new and new APIs
luisasofie_xoxo
0
190
Folding Cheat Sheet #3
philipschwarz
PRO
0
120
GitHub Actionsで泣かないためにやっておきたい設定 / Recommended GHA settings to avoid crying
pinkumohikan
3
520
Ruby Function Composition
bkuhlmann
1
330
雑に思考を整理する技術と効能
konifar
58
28k
PHPはいつから死んでいるかの調査
chiroruxx
1
360
Amazon SQSコンシューマー疎結合への旅 - 出張! #DevelopersIO IT技術ブログの中の人が語る勉強会 #3
quiver
0
220
GraphQLサーバの構成要素を整理する #ハッカー鮨 #tsukijigraphql / graphql server technology selection
izumin5210
4
810
Featured
See All Featured
The Invisible Customer
myddelton
114
12k
The Invisible Side of Design
smashingmag
294
49k
Fantastic passwords and where to find them - at NoRuKo
philnash
36
2.5k
Creatively Recalculating Your Daily Design Routine
revolveconf
209
11k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
5
1.5k
Git: the NoSQL Database
bkeepers
PRO
422
63k
For a Future-Friendly Web
brad_frost
171
8.9k
Building a Scalable Design System with Sketch
lauravandoore
455
32k
Imperfection Machines: The Place of Print at Facebook
scottboms
259
12k
Music & Morning Musume
bryan
41
5.6k
A designer walks into a library…
pauljervisheath
199
23k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
13
1.5k
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でお仕事したいよぉ〜〜