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
10 Kommentare
Unser Unternehmen hatte sich vor einigen Jahren nach Abwägung mit gRPC für Thrift entschieden. Auch bei Thrift war der JS-Generator unvollständig, sodass wir ihn selbst angepasst haben, und dabei haben wir gemerkt, dass man sich das besser nicht antut. Deshalb dachte ich, wir hätten vielleicht doch gRPC wählen sollen, aber dort scheinen die Umstände auch nicht gerade besonders gut zu sein.
Wir haben uns danach für GraphQL entschieden, und ich bin damit zufrieden. Manchmal mache ich mir zwar Sorgen um den Kommunikations-Overhead, aber ein binärbasiertes Protokoll kommt für mich einfach nicht infrage.
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
Wow, Sie haben den Compiler direkt selbst gebaut. Großartig! (Ich war neugierig, wie der Golang-Code erzeugt wird, aber aktuell wird wohl nur Deno und Node.js unterstützt.) Ich nutze oft
protocoderbufzusammen mitts-proto; da würde mich interessieren, worin sich der erzeugte TS-Code vonts-protounterscheidet.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~?
Ich stimme zu, dass die Nutzung des gRPC/Protobuf-Stacks nicht ideal ist. (Ich habe ihn nicht aus eigenem Wunsch verwendet, sondern aufgrund der Situation im Unternehmen.)
Allerdings definiert tRPC die Schnittstellen mit
zod, daher scheint es ideal zu sein, wenn man auf allen Plattformen TypeScript verwendet.In unserer Umgebung, in der wir den Server mit Kotlin schreiben, dürfte es schwer einzusetzen sein, und auch für die Kommunikation mit nativen Mobile-Apps (Swift, Kotlin) scheint es nicht geeignet zu sein.
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.