Chez Riiid, qui exploite le service Santa TOEIC, nous utilisons gRPC/Protobuf de manière très active.
Peu de temps après mon arrivée chez Riiid, on nous a annoncé qu’à l’avenir, toutes les API fournies par l’équipe backend au frontend (mobile/web) seraient unifiées autour de gRPC.
Pour utiliser la pile gRPC/Protobuf côté frontend web, il existait auparavant des méthodes comme ajouter un plugin JS/TS à protoc ou utiliser Protobuf.js.
Le plugin JS officiel de protoc générait du code dans un style très ancien, et les plugins de l’écosystème ne couvraient pas non plus tous nos besoins. Il y avait aussi l’inconvénient de dépendre d’un binaire natif (protoc). (Ces derniers temps, il y a même le problème de l’installation de protoc sur des machines M1.)
Nous avons utilisé Protobuf.js pour développer plusieurs produits jusque-là, mais comme tous les produits créés dans l’entreprise utilisent Protobuf pour toutes les interfaces de communication entre plateformes, nous avons constaté que Protobuf.js n’était pas assez mature pour répondre au niveau d’exigence dont nous avions besoin.
Nous avons rencontré divers problèmes, par exemple lorsqu’un nom de message était identique, il était parfois confondu avec un message situé dans un autre namespace ; ou encore, dans le namespace global, si une déclaration de message suivait un enum, le code de type du message n’était pas généré ; ou bien les définitions de types TypeScript différaient du comportement du JS généré.
Au cours de ce processus, nous avons créé pollapo, un gestionnaire de paquets protobuf, afin de mettre en place un système permettant de ne sélectionner et construire que les schémas protobuf nécessaires à un produit donné.
(À l’époque, il existait d’autres gestionnaires de dépendances protobuf, mais ils avaient des bugs ou ne prenaient pas en charge les dépendances imbriquées. De plus, la fonctionnalité de gestion de paquets fournie par buf n’en était alors qu’au stade d’un billet de blog annonçant son développement, et elle n’était toujours pas finalisée au moment où nous avons créé pollapo et terminé notre migration interne.)
Grâce à pollapo, nous avons fortement réduit le nombre de schémas construits par produit, et les bugs liés, par exemple, à des noms de message identiques ont diminué. Mais il restait malgré tout des bugs et des problèmes de build ; pour les résoudre, nous avons fini par créer nous-mêmes un compilateur protobuf vers TypeScript.
Santa TOEIC a désormais complètement retiré Protobuf.js et terminé sa migration vers pbkit.
Les applications développées chez Riiid, y compris Santa TOEIC, utilisent intensivement les WebView.
Les WebView communiquent avec le natif pour récupérer des informations sur l’appareil, l’utilisateur ou le contenu actuellement affiché, et l’interface utilisée à cette fin est elle aussi définie à l’aide de schémas de services Protobuf.
pbkit fournit, lors de la génération du code de service, une interface permettant de remplacer la couche réseau par un autre protocole que gRPC.
Les ingénieurs frontend web qui utilisent le compilateur pbkit n’ont pas besoin de savoir si, lors de la communication avec le natif mobile, la requête passe par gRPC ou par le protocole App Bridge convenu avec les ingénieurs mobiles.
Et comme nous avons aussi développé nous-mêmes une extension Chrome, il est possible d’inspecter très facilement les échanges avec le mobile dans l’onglet pbkit des outils de développement Chrome, comme on le ferait dans l’onglet Réseau.
Comme nous avons créé nous-mêmes le compilateur de schémas protobuf, nous nous sommes dit qu’il serait rapide d’ajouter dans l’éditeur des fonctionnalités comme Go to Definition, et nous avons donc aussi créé une extension VSCode.
Jusqu’à présent, les extensions protobuf dédiées à VSCode se limitaient surtout à des fonctions comme la coloration syntaxique, mais l’extension pbkit pour VSCode inclut une véritable fonctionnalité Go to Definition qui fonctionne correctement.
À l’avenir, nous prévoyons de développer la prise en charge d’autres langages comme swift/kotlin/python, la prise en charge de cas d’usage serveur, des outils de génération de documentation, ainsi que des outils de linting/formatage.
Nous recrutons également des ingénieurs pour développer ces outils avec nous : https://riiid.com/ko/career/dx-software-engineer
Nous espérons susciter votre intérêt.
Dépôt pbkit : https://github.com/pbkit/pbkit
Extension vscode : https://marketplace.visualstudio.com/items?itemName=pbkit.vscode-pbkit
Extension Chrome : https://chrome.google.com/webstore/detail/pbkit-devtools/fjacmiijeihblfhobghceofniolonhca
8 commentaires
Dans notre entreprise, nous avions hésité entre gRPC et Thrift il y a quelques années, et nous avions finalement choisi Thrift. Le générateur JS de Thrift étant lui aussi incomplet, nous l’avons modifié nous-mêmes, et nous avons compris que c’était une vraie galère. Du coup, je me suis demandé si nous aurions dû choisir gRPC, mais apparemment la situation n’est pas franchement meilleure de ce côté-là.
Nous avons ensuite choisi GraphQL, et j’en suis satisfait. Je m’inquiète parfois de la surcharge liée aux échanges, mais je n’arrive vraiment pas à utiliser des protocoles binaires.
Nous l’utilisons très bien chez Karrot Market !! ( _ _ )
Nous essayons d’en tirer pleinement parti pour le maillage de nos API internes haha
Oh, c'est impressionnant !
Cela dit, si c’est déjà utilisé en production dans l’entreprise, vous pouvez sans doute arrêter d’utiliser une version qui fait pré-alpha comme la v0.0.44.
J’imagine que certaines personnes risquent de ne pas l’utiliser juste en voyant le numéro de version :(
Waouh, vous avez carrément créé le compilateur vous-même. C’est impressionnant ! (Je me demandais comment le code golang était généré, mais on dirait qu’à l’heure actuelle seuls deno et node.js sont pris en charge.) J’utilise souvent protoc ou buf avec ts-proto, et je me demande quelle est la différence entre le code TS généré par rapport à ts-proto.
J’ai l’impression que ça prend un détour https://github.com/trpc/trpc
Je suis d’accord sur le fait qu’utiliser une stack gRPC/Protobuf n’est pas idéal. (Ce n’est pas moi qui ai choisi de l’utiliser, mais c’était dû aux contraintes de l’entreprise.)
En revanche, comme trpc définit les interfaces à l’aide de zod, cela semble idéal quand on utilise TypeScript sur toutes les plateformes.
Dans notre environnement, où nous écrivons le serveur en Kotlin, cela me paraît difficile à utiliser, et cela ne semble pas non plus adapté lorsqu’il faut communiquer avec du natif mobile (Swift, Kotlin).
Waouh, jusqu’aux extensions VS/Chrome dans le code... c’est génial !! Je vous soutiens.
La présentation est tellement bien rédigée que les personnes qui découvrent le projet via GeekNews auront sans doute plus d’informations que celles qui visitent simplement le repo ^^;
Si des personnes utilisent actuellement Protobuf, ce serait vraiment utile qu’elles laissent un commentaire.