WRP - WebViewとモバイルネイティブ通信のためのProtobufサービスプロトコル
(twitter.com/hrmm_flow)Riiidでは、モバイルアプリを主軸とする多くのスタートアップと同様に、各モバイルプラットフォームで共通して提供される画面をWebで開発し、WebViewの形で組み込む方式を採用しています。
また、WebView開発のイテレーションを高速化するために、WebViewの代わりにiframeを使ってモバイルネイティブを模倣する形で仮想モバイルWebページを作り、Web画面の開発に利用しています。
Webページとして作られた画面は、ネイティブよりライフタイムが短く、利用できるAPI権限も限られているため、必然的にWebViewを載せた外側の殻（ネイティブ、parent window）と通信するコードを書く必要が生じます。
ところが、各外側の殻の側でWebViewと通信するインターフェースには扱いづらい制約（双方向通信ができない、任意のJSコード片を実行する方式しかサポートしない、など）があり、そのうえ各殻ごとにインターフェースが大きく異なるため、通信コードの作成が面倒になるという問題が発生します。
私たちはもともと、Web／モバイルクライアントがAPIサーバーと通信する際にprotobufとgrpcの技術を使っています。protobufはサービスインターフェースを記述するためのスキーマ言語で、grpcはprotobufで定義された抽象的なリクエストを実際のHTTPリクエストへ変換するプロトコルレイヤーです。
すでにバックエンドとの通信にprotobufを使っており、エンジニアにも馴染みがあったため、ワークフローを統一する目的で、従来のWebView通信方式の問題を解決するのにprotobufを使うことを以前から決めていました。
その後、長年にわたって複数のモバイルアプリを開発する中で、すでに殻 <-> WebView通信にprotobufコード生成の開発方式を使ってきましたが、最近新しいアプリを作るにあたり、この技術を改善してオープンソース化することにしました。
wrpはこのような背景の中で生まれた、grpcに似た役割を持ちながらWebView専用のプロトコルレイヤーです。
wrpはtypescript & react / kotlin & compose / swift & tca をサポートし、ストリーム、双方向通信、Webページが再読み込みされた場合に通信コンテキストを復元する機能などを備えています。また、ユーザー側のネイティブアプリのバージョンアップが遅く、WebViewとのプロトコル不一致が発生する状況にもある程度対応しています。
主要機能がようやく実装された段階のため、まだ安定してはいませんが、この技術に興味のある方はぜひ私たちのDiscordサーバーに参加して、一緒に話せるとうれしいです。
Pbkit Discordサーバー: https://discord.gg/PHmV3nhvQq
Web - TypeScript & React
- ライブラリ: https://github.com/pbkit/wrp-ts
- 例: https://github.com/pbkit/pbkit.dev/blob/main/islands/WrpIframeHost.tsx
iOS - Swift & TCA
- ライブラリ: https://github.com/pbkit/wrp-swift
- 例: https://github.com/pbkit/wrp-swift/blob/main/Example/Wrp/WrpExampleServiceProvider.swift
Android - Kotlin & Compose
- ライブラリ: https://github.com/pbkit/wrp-kt
- 例: https://github.com/pbkit/wrp-kt/blob/main/example/src/main/kotlin/dev/pbkit/wrp/example/MainActivity.kt
（Twitterに投稿した内容を少し手直しして転載しました）
https://twitter.com/disjukr/status/1537034296959315968
1件のコメント