Es ist einfach, eine Protokollpufferdatei zu vergessen und einen Serveraufruf zu stören, wenn die Spezifikation insbesondere bei Microservices nicht übereinstimmt. Wenn Ihr Server-Signatur-Protokoll (Proto) nicht exakt der Definition entspricht, schlägt die Anfrage fehl. Daher ist es wichtig, eine skalierbare Modellpipelinestruktur im gesamten Anwendungsentwicklungszyklus einzurichten.
Je nach Anforderungen kann die Konfiguration von Protokolldefinitionsdateien von Unternehmen zu Unternehmen oder von Anwendung zu Anwendung unterschiedlich sein. Das gRPC-Protokoll wurde so konzipiert, dass es Protokollpuffer- oder .proto-Dateien verwenden kann, um ein Schema zu implementieren, das einen Server und einen Client generieren kann, die Nachrichten im definierten Format senden können. Zunächst können Sie eine .proto-Datei an zwei verschiedenen Orten auf zwei verschiedenen GitHub-Repo oder Ordnern einrichten, die keine gemeinsamen Module teilen, und die Lego-Blöcke zum Verbinden bringen. Irgendwann haben Sie möglicherweise mehrere Dienstdefinitionen und Nachrichten, die in den Repos dupliziert sind. Mit gRPC können Sie Module, die Sie über Dateien benötigen, importieren, um das Duplizieren von Code zu vermeiden. In diesem Zusammenhang kann es hilfreich sein, einen zentralen Ort einzurichten, um die Dateien zu erstellen und an die Abhängigkeitsmanager zu senden, die in Ihrer Anwendung wie npm, Fracht oder Komponist konsumiert werden sollen. Ein Beispiel dafür finden Sie an dieser Stelle und können mit npm (dem Paketverwalter für Node) getestet werden, indem Sie npm i @a11ywatch/protos ausführen. Sie werden die Definitionsdateien innerhalb des node_modules-Ordners sehen.
Wenn Sie semver (Versionskontrolle) mit gRPC verwenden, hilft es dabei eine Kompatibilitätsschicht zu definieren, die auf verschiedenen Ebenen wahr ist. In der Regel ist gRPC nicht anfällig für Brüche bei Updates, mit Ausnahme der folgenden Maßnahmen.
mer auf der Nachricht unter Verwendung des reserved-Schlüsselworts von Protobuf an. Umbenennen einer Nachricht - Nachrichtennamen werden in der Regel nicht über das Netzwerk gesendet, daher handelt es sich nicht um eine störende Änderung am gRPC-Protokoll. Der Client muss jedoch aktualisiert werden, wenn er den neuesten Vertrag verwendet. Eine Situation, in der Nachrichtennamen über das Netzwerk gesendet werden, besteht bei Any-Feldern, wenn der Nachrichtenname verwendet wird, um den Nachrichtentyp zu identifizieren. Verschachteln oder Aufheben der Verschachtelung einer Nachricht - Nachrichtentypen können verschachtelt sein. Das Ein- oder Auspacken einer Nachricht ändert ihren Nachrichtennamen. Eine Änderung daran, wie ein Nachrichtentyp verschachtelt ist, hat den gleichen Einfluss auf die Kompatibilität wie eine Umbenennung. Namespace-Änderung - Eine Namespace-Änderung ändert den Namespace der generierten Sprachtypen. Dies ist keine störende Änderung am gRPC-Protokoll, aber der Client muss aktualisiert werden, wenn er den neuesten Vertrag verwendet.
Jetzt, da wir das Wichtigste wissen, können wir die automatisierten Tools nutzen, die dazu beitragen, die gRPC-Workflows und die Produktivität zu verbessern.
Mein Name ist Jeff und ich bin der Gründer und Schöpfer von A11yWatch.
Beginnen Sie jetzt mit A11yWatch, um schnelles und erschwingliches automatisches Web-Accessibility-Testen und -Überwachen zu erhalten.
