Die meisten Softwareanwendungen müssen aus verschiedenen Gründen in der Lage sein, sich mit anderem Code zu verbinden. Dies kann von der Integration bis hin zum Hinzufügen neuer Funktionen reichen. Um sicherzustellen, dass Software mit anderen Anwendungen verbunden werden kann und um ihre Integration in andere Programme zu gewährleisten, verwenden Entwickler APIs. Aus diesem Grund ist eine Anwendungsprogrammierschnittstelle für die meiste Software notwendig. Durch ihre Rolle als Brücke zwischen den Systemen ermöglichen APIs den Zugriff auf eine Vielzahl von Webdiensten. Deshalb ist es wichtig, die richtige Technologie zu wählen, um eine API für Ihr Projekt anzubieten.
Jede Organisation, die ihre Anwendung oder Plattform mit ihren Nutzern teilen möchte, muss APIs verwenden. Es gibt viele Möglichkeiten zur Entwicklung und Feinabstimmung von APIs, damit sie perfekt zu Ihrer Anwendung passen. Eine der neuesten Methoden, die Programmierer zur Entwicklung von APIs verwenden, ist gRPC. Sehen wir uns an, was gRPC ist und welche Vor- und Nachteile es hat.
Was ist gRPC?
gRPC steht für Google Remote Procedure Call. gRPC ist ein Open-Source-RPC-Framework, das für die Erstellung skalierbarer und schneller APIs verwendet wird. Es ermöglicht die Entwicklung vernetzter Systeme und eine offene Kommunikation zwischen gRPC-Client- und -Serveranwendungen. gRPC wurde von mehreren führenden Technologieunternehmen wie Google, IBM und Netflix übernommen. Das gRPC-Framework basiert auf hochmodernen technischen Stacks wie HTTP/2, Protokollpuffern und mehr für optimalen API-Schutz, leistungsstarke Remote Procedure Calls und Skalierbarkeit.
Was sind RPCs?
RPC und REST - Representational State Transfer- sind seit jeher zwei unterschiedliche Ansätze für die Erstellung von APIs. Darüber hinaus werden auch Protokolle wie SOAP und GraphQL für diesen Zweck verwendet. Mit Remote Procedure Calls können Sie Software so schreiben, als würde sie lokal laufen, obwohl sie auf einem anderen Gerät ausgeführt werden könnte.
Sie sind das am häufigsten verwendete Framework für die Entwicklung von APIs. Im Gegensatz zu einem typischen HTTP-Protokollaufruf verwendet ein RPC einen Funktionsaufruf als primäre Methode der Client-Server-Interaktion. RPC ist eine produktive Technik zur Erstellung von APIs, da die Austauschvorgänge einfach und die Inhalte leichtgewichtig sind. gRPC-Dienste ahmen diese Kommunikationsarchitektur ebenfalls nach. RPC verwendet IDL - Interface Definition Language, um den Datentyp und die Methoden, die aufgerufen werden, zu kontrahieren. In den letzten Jahren sind gRPC-Dienste, die von RPCs übernommen wurden, sehr beliebt geworden.
Warum wurden gRPC-Dienste entwickelt?
Da immer mehr Unternehmen Kanäle für die Integration öffnen, wird es immer schwieriger, solche Software zu verknüpfen. RPC APIs sind schwierig zu integrieren und riskant zu verbreiten, da sie interne Besonderheiten offenlegen können. Sie werden in vielen Programmiersprachen entwickelt und sind eng mit dem zugrunde liegenden Framework verbunden.
Mit der Einführung der REST-API im Jahr 2000 wurde dieses Problem angegangen und die Zugänglichkeit von APIs verbessert. Sie bot den Benutzern eine konsistente Möglichkeit, Informationen indirekt über Assets mit Hilfe von Standard-HTTP-Techniken wie GET, PUT, POST und anderen abzurufen. Der Hauptunterschied zwischen RPC und REST API besteht darin, dass mit RPC Prozesse angesprochen werden, aber es ist nicht einfach, vorherzusagen, wie die Prozesse in verschiedenen Systemen aussehen könnten.
REST API konnte das einfache und leichtgewichtige RPC nicht vollständig ersetzen, da es eine große Menge an Metadaten produzierte, obwohl es ein verbessertes Format für den Umgang mit vielen Anwendungen bot. Dies führte schließlich zum Aufkommen der Dienste GraphQL von Facebook und gRPC von Google.
Google entwickelte gRPC im Jahr 2015 als Ergänzung zum RPC-Framework, um zahlreiche Microservices-Architekturen zu verbinden, die mit verschiedenen Techniken erstellt wurden. gRPC war ursprünglich eng mit der Kerninfrastruktur von Google verbunden, wurde aber schließlich quelloffen gemacht und für die Nutzung durch die Allgemeinheit standardisiert.
Überblick über die gRPC-Konzepte
Die Verwendung von Spitzentechnologien, die im Vergleich zu JSON und XML eine hohe Leistung aufweisen und eine größere API-Integrität bieten, ist für die Entstehung und Popularität von gRPC verantwortlich. Einige der gRPC-Konzepte, die Sie kennen sollten, sind:
Protokollpuffer
Protokollpuffer, auch bekannt als Protobuf, sind Serialisierungs- oder Deserialisierungsstandards, die die Definition von Anwendungen und die automatische Codegenerierung von Client-Bibliotheken vereinfachen. Die neueste Version, proto3, ist einfacher zu benutzen und bietet die neuesten Möglichkeiten für gRPC.
.Proto Die Dateien ermöglichen die gRPC-Dienste und die Kommunikation zwischen gRPC-Clients und Server-Nachrichten. Die Datei .proto wird bei der Ausführung durch den Compiler Protobuf - protoc- in den Speicher geladen. Dieser Compiler erstellt gRPC-Client- und gRPC-Server-Anwendungen, die die In-Memory-Struktur zur Serialisierung und Deserialisierung der Binärdaten verwenden. Jede Kommunikation wird nach der Codegenerierung in gRPC zwischen dem Benutzer und dem Remote-Dienst gesendet und empfangen.
CPU Da die Daten in eine binäre Form übersetzt werden und die verschlüsselten Signale kleiner sind, verbraucht das Parsen mit Protobuf weniger Leistung für gRPC. Daher werden Nachrichten mit gRPC auch auf Computern mit einer schwächeren CPU, wie z. B. Mobiltelefonen, schneller gesendet.
HTTP/2
Der gRPC-Dienst basiert auf HTTP/2, der Version von HTTP/1.1, die weniger Einschränkungen aufweist. Obwohl es mit dem älteren HTTP-Protokoll funktioniert, verfügt HTTP/2 über mehrere hochentwickelte Funktionen für gRPC. Dazu gehört eine binäre Framing-Schicht, die jede HTTP/2-Anfrage und -Antwort in kleinere Nachrichten aufteilt und diese in ein binäres Format einrahmt, um die Nachrichtenübermittlung zu verbessern. Außerdem unterstützt gRPC mehrere Anfragen und Antworten von Client und gRPC-Server im bidirektionalen Vollduplex-Streaming.
HTTP/2 verfügt über eine Flusssteuerungsmethode, die eine präzise Steuerung der RAM ermöglicht, die für die Pufferung von Paketen während des Fluges erforderlich ist. Außerdem bietet es Header-Kompression für gRPC-Dienste. Alles in HTTP/2 wird vor der Übertragung verschlüsselt, sogar die Header, die leistungsstarke Remote Procedure Calls ermöglichen. gRPC bietet mit HTTP/2 sowohl asynchrone als auch synchrone Verarbeitung und ermöglicht die Ausführung verschiedener interaktiver und gestreamter RPC-Typen.
Mit Hilfe all dieser Eigenschaften von HTTP/2 können gRPC-Dienste weniger Ressourcen verbrauchen, was zu schnelleren Antwortzeiten zwischen Cloud-basierten Anwendungen und gRPC-Diensten und zu einer längeren Akkulaufzeit für gRPC-Clients auf mobilen Geräten führt.
Streaming
Eine wichtige Idee, die gRPC unterstützt, ist das Streaming, das die Ausführung mehrerer Prozesse innerhalb einer einzigen Anfrage ermöglicht. gRPC macht dies durch die HTTP/2-Multiplexing-Funktion möglich, mit der mehrere Antworten oder Anfragen gleichzeitig über eine TCP - Transmission Control Protocol - Verbindung gesendet oder empfangen werden können. Die wichtigsten Streaming-Formate sind Server-Streaming-RPCs, Client-Streaming RPCs und bidirektionales Streaming RPCs.
Kanäle
Im Gegensatz zu HTTP/2-Streams, die zahlreiche gleichzeitige Streams auf einer einzigen Anfrageverbindung erlauben, unterstützt ein Kanal mit gRPC mehrere kontinuierliche Streams über mehrere Anfragen hinweg. Sie werden verwendet, um einen Client-Stub zu erstellen und bieten einen Mechanismus zur Verbindung mit einem gRPC-Server auf einer bestimmten IP und einem bestimmten Port.
gRPC-Architektur
Die gRPC-Architektur besteht sowohl aus einem gRPC-Client als auch aus einem gRPC-Server. Jeder gRPC-Clientdienst enthält einen Stub oder eine automatisch generierte Datei, die einer Schnittstelle ähnelt, die die aktiven entfernten Prozesse enthält. Der gRPC-Client initiiert einen lokalen Prozeduraufruf an einen Stub mit Argumenten, die an die gRPC-Server-Nachrichten weitergeleitet werden. Der gRPC-Client-Stub sendet dann die Anfrage an die lokale Client-Zeiteinheit auf dem lokalen Computer, nachdem er die Argumente mithilfe des Protobuf -Marshaling-Verfahrens serialisiert hat.
Das Betriebssystem verwendet das HTTP/2-Protokoll zur Kommunikation mit dem entfernten Server-Computer. Das Betriebssystem des Servers nimmt die Nachrichten entgegen und ruft den Server-Stub-Prozess auf, der Protobuf verwendet, um nach der Dekodierung der eingehenden Parameter die entsprechende Operation aufzurufen. Die Client-Transportschicht empfängt dann die verschlüsselte Antwort vom Server-Stub. Die Ausführung geht an den Aufrufer zurück, nachdem der gRPC-Client-Stub die Antwortnachrichten erhalten und die bereitgestellten Argumente entschlüsselt hat.
Vorteile von gRPC
gRPC hat mehrere Vorteile gegenüber anderen API-Design-Mechanismen. gRPC verbessert auch die Struktur von RPC. Hier sind die wichtigsten Vorteile der gRPC-Dienste:
- Leistungsstarke Remote Procedure Calls
Durch die Verwendung von Protobuf und HTTP/2 bieten gRPC-Dienste eine bis zu 10-mal höhere Leistung und API-Schutz als REST+JSON-Interaktionen. Durch die Verwendung von Server-Pushes, Multiplexing und Header-Komprimierung bietet HTTP/2 Hochleistungs-Rankings für gRPC-Dienste. Während Multiplexing die Head-of-Line-Verzögerung beseitigt, ermöglicht HTTP/2 durch Server-Push, Material vom Server zum Client zu schieben, bevor es benötigt wird. Die Nachrichten werden mit HTTP/2 effektiver komprimiert, was zu einem schnelleren Laden von gRPC-Diensten führt.
- Streaming
Die Dienstbeschreibung für streaming gRPC-Dienste beinhaltet bereits client- oder serverseitige Streaming-Prinzipien. Die Erstellung von gRPC-Clients und Streaming-Diensten wird dadurch erheblich vereinfacht.
- Code-Generierung
Die Codegenerierung für gRPC-Client- und gRPC-Server-Programme ist die Schlüsselkomponente des gRPC-Web-Ansatzes. Für die Codegenerierung aus der Datei .proto verwenden gRPC-Module den Compiler .protoc. Das Format Protobuf wird durch die Codegenerierung in gRPC gesteuert, die zur Definition von Datenformaten und Anwendungsendpunkten verwendet wird. Es können clientseitige Netzwerk-Stubs und serverseitige Skeletons erstellt werden, was den Zeitaufwand für die Entwicklung von Programmen mit einer Vielzahl von Diensten in gRPC-Diensten reduziert.
- Interoperabilität
Zahlreiche Systeme und Programmiersprachen, wie Java, Ruby, Go, C# und andere, werden von den gRPC-Ressourcen und -Bibliotheken unterstützt. Mit diesen Programmiersprachen können Entwickler leistungsfähige Anwendungen erstellen und dabei die vollständige plattformübergreifende Kompatibilität mit gRPC nutzen. Dies ist dank der Protobuf Binärverdrahtungsform und der effektiven Codegenerierung für fast alle Systeme möglich.
- Sicherheit
Die API-Sicherheit wird in gRPC durch HTTP/2 über eine TLS-verschlüsselte End-to-End-Sitzung gewährleistet. gRPC fördert den Einsatz von SSL/TLS zur Datenverschlüsselung und Authentifizierung zwischen dem Server und dem gRPC-Client.
- Produktivität und Benutzerfreundlichkeit
Da gRPC eine vollständige Alternative zu RPC ist, funktioniert es problemlos auf einer Vielzahl von Systemen und Sprachen. gRPC verfügt außerdem über großartige Werkzeuge, wobei ein Großteil des erforderlichen Boilerplate-Codes manuell generiert wird. Durch die erhebliche Zeitersparnis mit gRPC können sich die Ingenieure nun mehr auf die Kernfunktionen konzentrieren.
Nachteile von gRPC
Obwohl wir hoffen können, dass die Nachteile von gRPC irgendwann behoben werden, stellen sie derzeit noch einige Probleme für die Nutzung dar. Einige Nachteile von gRPC, die Sie kennen sollten, sind:
- Mangelnde Reife
Die Entwicklung einer Technologie kann ein erhebliches Hindernis für die Akzeptanz sein. Das wird auch bei der Verwendung von gRPC deutlich. GraphQL Die Datenbank von gRPC, einer der Konkurrenten von gRPC, hat mehr als 14k Abfragen auf StackOverflow, während gRPC im Moment nur etwas weniger als 4k hat. Der gRPC-Gemeinschaft fehlt es an Wissen über Best Practices, Lösungen und Erfolge, da es außerhalb von Google nicht viel Unterstützung für Programmierer von HTTP/2 und Protokollpuffern gibt. Da die gRPC-Gemeinschaft jedoch wächst und neue Entwickler anzieht, wird sich dies mit der Zeit ändern.
- Begrenzte Browserunterstützung
Da kein aktueller gRPC-Webbrowser HTTP/2-Frames verarbeiten kann, können Sie einen gRPC-Dienst nicht effektiv von einem Browser aus aufrufen, da gRPC Web hauptsächlich von HTTP/2 abhängt. Infolgedessen müssen Sie einen Proxy mit gRPC verwenden, was einige Nachteile mit sich bringt.
- Unlesbar für Menschen
Im Gegensatz zu XML und JSON sind Protobuf Dateien nicht für Menschen lesbar, da die Daten in ein binäres Format komprimiert werden. Entwickler müssen zusätzliche Tools wie das Server-Reflection-Protokoll und die gRPC-Eingabeaufforderung verwenden, um Nutzdaten zu bewerten, Fehler zu beheben und manuelle Abfragen zu erstellen.
- Steile Lernkurve
Es wird eine Weile dauern, bis man sich mit Protokollpuffern vertraut gemacht hat und Methoden zur Bewältigung von HTTP/2-Reibungen entdeckt hat, im Gegensatz zu REST und GraphQL, die beide hauptsächlich JSON verwenden.
Wie kann AppMaster helfen?
DieNo-Code-Generierung verändert die Art und Weise, wie die Menschen das Programmieren sehen. Die No-Code-Generierung ermöglicht es den Menschen, Software schneller zu erlernen und zu erstellen, indem sie Code generiert. Die Codegenerierung für Ihre Anwendung ist mit No-Code-Generierungsplattformen wie AppMaster einfacher. Es gibt auch keine Eigentumsfragen, denn die Codegenerierung ist geschützt, und der von Ihnen erstellte Code gehört nur Ihnen. Mit AppMaster können Sie Client- und Serveranwendungen schneller und einfacher erstellen.
Die AppMaster-Plattform ohne Codegenerierung ermöglicht es Entwicklern, das gRPC-Protokoll für Anfragen zwischen Backend-Microservices-Architekturen zu verwenden. Nächstes Jahr werden wir die gRPC-Unterstützung erweitern, indem wir die API sowohl für gRPC Web- als auch für gRPC Mobile-Anwendungen integrieren.
Schlussfolgerung
Obwohl gRPC-Dienste mehrere Vorteile haben, die sie für Unternehmen und Entwickler attraktiv machen, hängt die Entscheidung, gRPC-Dienste gegenüber anderen wie REST oder SOAP zu verwenden, letztendlich von Ihrer Anwendung ab. Während manche Software mit gRPC leistungsstarke Vorteile hat, sind andere möglicherweise besser für ihre Alternativen geeignet. Sie sollten die Nachteile und Vorteile von gRPC-Diensten kennen und entscheiden, ob sie für Sie geeignet sind.
