Bei Riiid, dem Unternehmen hinter Santa TOEIC, werden gRPC/Protobuf sehr intensiv eingesetzt.
Kurz nachdem ich bei Riiid angefangen hatte, wurde uns mitgeteilt, dass künftig alle APIs, die das Backend-Team dem Frontend (Mobile/Web) bereitstellt, einheitlich über gRPC laufen sollen.
Um den gRPC/Protobuf-Stack im Web-Frontend zu nutzen, gab es bisher die Möglichkeit, protoc mit einem JS/TS-Plugin zu verwenden oder Protobuf.js einzusetzen.
Das offizielle JS-Plugin von protoc hatte das Problem, sehr altmodischen Code zu erzeugen, und auch die Plugins aus dem Ökosystem erfüllten nicht alle unsere Anforderungen. Dazu kam die Unbequemlichkeit der Abhängigkeit von einem nativen Binary (protoc). (In letzter Zeit gibt es außerdem das Problem, dass sich protoc auf M1-Geräten nur schwer installieren lässt.)
Wir haben mit Protobuf.js über längere Zeit verschiedene Produkte entwickelt. Als jedoch bei allen im Unternehmen entstehenden Produkten sämtliche plattformübergreifenden Kommunikationsschnittstellen mit Protobuf umgesetzt wurden, stellte sich heraus, dass Protobuf.js nicht den Reifegrad hatte, den wir brauchten.
Wir sind auf verschiedene Probleme gestoßen: Wenn Nachrichtennamen identisch waren, wurden sie manchmal fälschlich als Nachrichten aus einem anderen Namespace interpretiert; wenn im globalen Namespace auf ein enum eine Nachrichtendeklaration folgte, wurde kein Code für den Nachrichtentyp erzeugt; oder die generierten TypeScript-Typdefinitionen wichen vom Verhalten des erzeugten JS ab.
In diesem Prozess haben wir einen Protobuf-Paketmanager namens pollapo entwickelt, um ein System aufzubauen, das nur die für ein bestimmtes Produkt benötigten Protobuf-Schemata herausfiltert und baut.
(Zu dieser Zeit gab es zwar andere Protobuf-Abhängigkeitsmanager, diese hatten jedoch Bugs oder unterstützten keine verschachtelten Abhängigkeiten. Außerdem befand sich die von buf angebotene Paketverwaltung damals laut Blogpost noch in Entwicklung und war selbst bis zum Abschluss unserer internen Migration auf pollapo noch nicht fertig.)
Mit pollapo konnten wir die Anzahl der pro Produkt gebauten Schemata deutlich reduzieren, und Bugs durch identische Nachrichtennamen wurden seltener. Dennoch gab es weiterhin Bugs und Build-Probleme, weshalb wir schließlich selbst einen Protobuf-zu-TypeScript-Compiler entwickelt haben.
Bei Santa TOEIC wurde protobuf.js inzwischen vollständig entfernt und komplett durch pbkit ersetzt.
Die bei Riiid entwickelten Apps, darunter auch Santa TOEIC, verwenden intensiv WebViews.
WebViews kommunizieren mit der nativen Ebene, um Geräte-/Benutzerinformationen oder Informationen über die aktuell angezeigten Inhalte abzurufen. Auch diese Schnittstellen werden mithilfe von Protobuf-Service-Schemata definiert.
pbkit bietet bei der Generierung von Service-Code eine Schnittstelle, über die sich die Netzwerkebene anstelle von gRPC durch ein anderes Protokoll ersetzen lässt.
Web-Frontend-Engineers, die den pbkit-Compiler verwenden, müssen bei der Kommunikation mit Mobile Native nicht wissen, ob Anfragen per gRPC gesendet werden oder über das mit den Mobile-Engineers vereinbarte App-Bridge-Protokoll laufen.
Da wir außerdem auch die Chrome-Erweiterung selbst entwickelt haben, lassen sich Inhalte der Kommunikation mit Mobile in der pbkit-Registerkarte der Chrome-Entwicklertools genauso bequem prüfen wie in einem Network-Tab.
Da wir den Protobuf-Schema-Compiler selbst entwickelt haben, lag es nahe, Funktionen wie Go to Definition im Code-Editor schnell umzusetzen, weshalb wir auch eine VSCode-Erweiterung erstellt haben.
Die bisherigen Protobuf-Erweiterungen speziell für VSCode boten meist nur Funktionen wie Syntax-Highlighting, die pbkit-VSCode-Erweiterung enthält hingegen eine korrekt funktionierende Go-to-Definition-Funktion.
Künftig planen wir Unterstützung für weitere Sprachen wie Swift/Kotlin/Python, Unterstützung für Server-Use-Cases sowie Tools zur Dokumentationsgenerierung und für Linting/Formatting zu entwickeln.
Wir suchen auch Engineers, die diese Tools gemeinsam mit uns entwickeln möchten: https://riiid.com/ko/career/dx-software-engineer
Wir freuen uns über großes Interesse.
pbkit-Repository: https://github.com/pbkit/pbkit
VSCode-Erweiterung: https://marketplace.visualstudio.com/items?itemName=pbkit.vscode-pbkit
Chrome-Erweiterung: https://chrome.google.com/webstore/detail/pbkit-devtools/fjacmiijeihblfhobghceofniolonhca
7 Kommentare
Wir nutzen es bei Karrot Market sehr gut!! ( _ _ )
Wir bemühen uns, es intern für API-Meshes sinnvoll einzusetzen, haha
Oh, das ist beeindruckend!
Übrigens, wenn ihr das in der Firma schon in der Produktion einsetzt, solltet ihr vielleicht aufhören, eine so pre-alpha-mäßige Version wie v0.0.44 zu verwenden.
Ich glaube, es gibt Leute, die es allein wegen der Versionsnummer nicht nutzen würden T_T
Fühlt sich irgendwie wie ein Umweg an https://github.com/trpc/trpc
bichi / Falls die Server-API über das gRPC-Protokoll bereitgestellt wird, ist tRPC dann nicht eher nichts, um das zu unterstützen~?
Beiträge zu gRPC sind immer willkommen :)
Wow, sogar mit VS-/Chrome-Erweiterungen im Code … wirklich großartig!! Ich drücke die Daumen.
Die Vorstellung ist so gut geschrieben, dass Besucher über GeekNews vermutlich mehr Informationen mitnehmen als Leute, die einfach nur direkt ins Repo schauen ^^;
Wenn diejenigen, die Protobuf gerade verwenden, einen Kommentar hinterlassen, wäre das sicher sehr hilfreich.