Webuilder240

Server-Driven UIとHotwire

2021-09-25 15:09:09 +0900

Hotwire HTML WebView ServerDriven-UI Rails

筆者について

  • 基本サーバサイドを主戦場にして働いているエンジニアで、どちらかといえばRails信者寄りの立場。
  • あまりリソースに余裕がない会社でエンジニアとして働いている。
  • ガワアプリとちょっとだけネイティブiOSアプリも書いたことある。

本当にポジショントークであり、ただの所感だと思ってみてもらえると嬉しいです。
下記URL、Airbnbが採用するServer-Driven UIについての記事を見た感想をつらつらと。

https://www.infoq.com/jp/news/2021/08/airbnb-server-driven-ui/

https://note.com/hikikomororinn/n/n329864ded9ae


特に気になったところは下記の部分。


例えば、コンポーネント間の並び順や細かい位置を変更したいとなったときにアプリやウェブフロントのリリースをしないでもサーバー側のレスポンスを変更するだけで細かいUIを調整することができます。

つまり、プロダクトの改善スピードが爆速になるということです。

https://note.com/hikikomororinn/n/n329864ded9ae#SKfuC

「んー、問題意識としてそのあたりはわかるし、いいアプローチ?」
「あれ?? Railsというか、Hotwireはそれできちゃってる... しかもサーバーサイドエンジニアから見たら、シンプルで簡単でこっちのほうが、どうしてもWebViewだとダメな理由がなければこっちでよくね??」

と思ったのが正直な感想でした。
先に書いておくと、「HTMLでできることは問題の解決になっていない」「RailsはUXの向上にコミットしていない」というのは百も承知なのでそのうえで落ち着いて読んでほしい。

Hotwireとは

Hotwire is an alternative approach to building modern web applications without using much JavaScript by sending HTML instead of JSON over the wire. 
とあるように、HTMLをメインの通信手段として利用することで、あまりJavaScriptを利用しないで、インタラクティブなWebアプリケーションを作るための仕組みということをうたってるフレームワーク、ライブラリ群です。

https://hotwired.dev/

Hotwireについての詳しいことはこの記事に書いてあるので参考にしてみてください。

https://zenn.dev/en30/articles/2e8e0c55c128e0

Server-Driven UIをすでにHotwireはできている、おまけにネイティブコードを書くのはごくわずか

よくよく考えれば、HotwireはサーバーサイドでHTMLを返して、JavaScriptはわずかなものであるという思想であり、HTMLをレンダリングするロジックとわずかなJavaScriptを修正してDeployするだけである。
ネイティブでやらなければこの問題自体はあまり発生することがないということである。

Webはこれで問題ないし、iOSやAndroidのネイティブアプリについてもWebViewなりを使えば、これだけでUIをコントロールできるし、機能開発やA/Bテスト実施のスピードは上げられそうではある。

もちろん、サーバーサイドがレンダリングしたHTMLがベースになるため、WebViewをベースにしたアプリになるので制約はありつつも、ほとんどは基本的にHTMLを書くだけで、ひとまず新しいスタックをそこまで入れなくとも、クロスプラットフォームを始められる礎が築けるのは大きいのではないだろうか。

Server-Driven UIの場合、自前でServer-Driven UIの仕組みを構築する必要があり、現状は小規模でカスタマイズ要件がないネイティブアプリではない限りはほとんどはオーバーエンジニアリングだと思う。

Server-Driven UIについて批判をしたいのではなく、
部分的に1週回ってサーバーサイドにレンダリングのロジックを持たせる風潮がやってきており、
これが巨大な企業で採用されるのはネイティブのUX表現の高さと、サーバサイドにViewのロジックを持たせたときの自由度とのいいところを両立したいんだろうなという狙いがあるのは承知しています。

もちろんHotwireも完全ではないですし、デメリットやできないこともこのあと書いています。

hey.comのメールアプリくらいにはできる

「WebViewで期待されるようなUXを実現するようなアプリ書けるんですか??」というのが気になるところだと思う。

DHHやRailsの人たちは「hey.com」で実装されていることくらいできるし、俺たちも作ってるよ!ということが主張したいことだと思う。

しかし分業体制をとれるリソースがあるチームの場合は、手馴れのクライアントサイドエンジニアとサーバーサイドエンジニアが分業できれば「もっと早く、細やかな部分のクオリティ高く」同じものを実装できると思うのが正直な感想ではある。

もちろんWebViewには限界はある。結構ある。

とはいえ、自分も仕事でWebViewアプリを作ったりしているけど、ネイティブアプリとWebViewアプリの混在しているし、最初からそのつもりで作っているわけでもないので、結構つらい部分があったりする。

また、キーボード入力の制御だったりとWebViewだとどうしてもできない「細かいところ」があったりがするので、やっぱりWebViewには限界を感じていて実装していてストレスに感じる部分は「結構ある」のが正直な感想。

WebViewとネイティブ部分をつなぎこむみたいなライブラリがHotwiredからリリースされているものもあるにはあるのですが、それでも限界はあると思っています。

だからこそ、AirbnbはWebViewではなくネイティブアプリを本当の意味で作り上げたいので、大げさな仕組みを導入しないといけないわけですが、あまりカジュアルに試せるものでもないと思うので、導入に当たっては、ServerDriven-UIが本当に自分たちのチームでフィットするのか?というのを真剣に考える必要があると思っています。

Strada

Hotwireが公開されてしばらくたつが、この記事を書いている今日現在でも、Stradaについてはまだ発表されていない。

https://logmi.jp/tech/articles/324219#s3

Stradaというコンポーネントに関しては、現時点でこういうものがあるよと公式ページに情報があるだけで、実際のフレームワークはまだ使えないので今回は話しませんが、説明を読む限りでは、カメラなどiOSやAndroidなどのネイティブで必要な機能とHTMLをシームレスにつなぐライブラリらしいです。

すでにHey.comのネイティブアプリでも使われているだろうし、
既存のWebViewアプリの限界を突破できるソリューションであることを期待したい。

まとめ

  • 一週回ってサーバーサイドにレンダリングロジックを持たせる機運がメインストリームではないものの一部で見られる。
    • Hotwireは「小規模のチーム」がよりカジュアルにこの機運に乗っていくための提案ではないだろうか?
  • WebView、ガワアプリにも結構できないことはあり、Server-Driven UIの採用事例は増えていくと思う。伏兵Stradaに期待。

関連しそうなブログ