13 points par disjukr 2022-06-15 | 1 commentaires | Partager sur WhatsApp

Chez Riiid, comme beaucoup d’autres startups dont le produit principal est une application mobile, nous utilisons une approche qui consiste à développer en web les écrans communs à chaque plateforme mobile, puis à les embarquer sous forme de WebView.

Par ailleurs, pour accélérer les itérations de développement des WebView, nous utilisons aussi des iframe à la place des WebView pour simuler le mobile natif, en créant des pages web mobiles virtuelles servant au développement des écrans web.

Les écrans créés comme pages web ont nécessairement une durée de vie plus courte que le natif et disposent de permissions API limitées ; il devient donc inévitable d’écrire du code de communication avec l’enveloppe qui embarque la WebView (le natif, la fenêtre parente).

Mais chaque enveloppe impose à l’interface de communication avec la WebView des contraintes peu pratiques — absence de communication bidirectionnelle, ou prise en charge limitée à l’exécution arbitraire de fragments de code JS, par exemple — et comme les interfaces diffèrent fortement d’une enveloppe à l’autre, écrire ce code de communication devient pénible.

De notre côté, lorsque les clients web/mobile communiquent avec les serveurs d’API, nous utilisons depuis longtemps protobuf et gRPC. Protobuf est un langage de schéma utilisé pour décrire les interfaces de service, et gRPC est une couche de protocole qui transforme des requêtes abstraites définies avec protobuf en véritables requêtes HTTP.

Comme nous utilisions déjà protobuf pour communiquer avec le backend et que les ingénieurs y étaient familiers, nous avons décidé il y a longtemps d’utiliser protobuf pour résoudre les problèmes des méthodes de communication WebView existantes, afin d’unifier le workflow.

Au fil de plusieurs années de développement de différentes applications mobiles, nous avons déjà utilisé une approche de génération de code protobuf pour la communication entre l’enveloppe et la WebView. Récemment, en créant une nouvelle application, nous avons décidé d’améliorer cette technologie et de la publier en open source.
wrp est né dans ce contexte : c’est une couche de protocole dédiée aux WebView, qui joue un rôle similaire à gRPC.

wrp prend en charge TypeScript & React / Kotlin & Compose / Swift & TCA, les streams, la communication bidirectionnelle, la restauration du contexte de communication lorsque la page web est rechargée, etc. Il gère aussi dans une certaine mesure les situations de décalage de protocole entre la WebView et l’application native, lorsque les utilisateurs mettent lentement à jour leur version de l’app native.

Les principales fonctionnalités de wrp viennent tout juste d’être développées, donc le projet n’est pas encore stable. Mais si cette technologie vous intéresse, nous serions ravis de vous voir rejoindre notre serveur Discord pour en discuter ensemble.


Serveur Discord de Pbkit : https://discord.gg/PHmV3nhvQq

Web - TypeScript & React

iOS - Swift & TCA

Android - Kotlin & Compose


(J’ai légèrement retouché puis repris ici ce que j’avais écrit sur Twitter)
https://twitter.com/disjukr/status/1537034296959315968

1 commentaires

 
disjukr 2022-06-15