Die beliebte Client-Server-Architektur teilt die Kommunikation in zwei Teile auf: einen, der alle schweren Aufgaben übernimmt und Dienste bereitstellt, bekannt als Server, und einen anderen, der diese Dienste genießt, bekannt als Client.
Im Allgemeinen sendet der Client in der Client-Server-Kommunikation einfach eine Anforderung, in der er Ressourcen oder Dienste vom Server anfordert, und der Server antwortet auf diese Anforderung.
Für die Client-Server-Kommunikation müssen sowohl Clients als auch Server Bibliotheken haben, die das Protokoll, in dem sie kommunizieren, verstehen können. Ein Protokoll ist eine Sprache oder eine Reihe von Internet-Kommunikationsregeln. Sie sind Transportmechanismen, die einige Richtlinien zur Datenübertragung über das Internet befolgen.
Der zweitwichtigste Aspekt der Client-Kommunikation ist das Nachrichtenformat, auf dem sowohl der Client als auch der Server einverstanden sind. Dieses Nachrichtenformat basiert auf einigen Schemas, und durch Nichterfüllung dieser Schemas würde keine Kommunikation stattfinden. Nachrichtenformate können ähnlich wie XML sein, das einem Schema folgt, oder eine JSON-Datei, die bestimmte Schlüssel-Wert-Paare enthalten muss.
Ein weiterer wichtiger Aspekt dieser Art von Kommunikation ist, dass sie auf einem Anforderungs- und Antwortmechanismus basiert, was bedeutet, dass der Server nur kommuniziert, wenn der Client die Kommunikation initiiert. Mit REST und GraphQL ist dies größtenteils einseitig. Dies ist ein grundlegendes Problem, das durch Technologien wie gRPC gelöst wird.
Warum Entstand REST?
In den frühen 90er Jahren wurde ein populäres Client-Server-Protokoll namens SOAP verwendet, das XML-Nachrichtenformate mit einem hartcodierten Schema nutzte. Das Schema für das Nachrichtenformat war sehr starr. Mangelnde Flexibilität führte zur Aufgabe von SOAP und zur Entstehung von REST.
REST entstand aufgrund der wachsenden Beliebtheit von JavaScript, was zu einem Anstieg der Popularität von JSON-Dateiformaten führte. Es war einfach zu verstehen und bequem. Es bestand einfach aus einigen Schlüssel-Wert-Paaren in seinem Nachrichtenformat.
In einfachen Worten ist Rest eine Richtlinie für die Übertragung von JSON-Nachrichten über das Internet mit HTTP als Protokoll (Transportmechanismus). Mit Rest muss man sich nicht um die Erstellung eines Schemas kümmern.
Was ist REST?
Wir haben über die Entstehung von REST gesprochen. Nun tauchen wir tiefer in seine Kern Technologie ein. Lassen Sie mich Ihnen sagen, dass REST für Representational State Transfer steht. Rest ist ein standardisiertes Software-Architekturstil, ein API, die in der Industrie häufig verwendet wird.
Gründe für die Beliebtheit und weite Verbreitung von REST
- REST ist einfach und standardisiert für die Kommunikationsarchitektur. Beim Nutzen von R müssen Sie sich nicht um die Formatierung Ihrer Nachricht oder Daten kümmern. Sie müssen sich nicht jedes Mal um das Nachrichtenformat kümmern, da es alles standardisiert und in der Industrie verwendet wird.
- REST ist skalierbar. Wenn Ihre Dienste größer werden und mehr Funktionalität benötigen, können Sie Ihren Server problemlos umgestalten, ohne sich um die Leistung von REST des Servers zu kümmern, und Sie können neue Funktionen in völliger Isolation erstellen, solange sie Ihre Daten nicht durcheinander bringen.
- REST ist zustandslos. Das bedeutet, dass jeder Anfrage Daten enthalten muss, die der Server verstehen muss. Die Architektur des Servers bewirkt, dass der Server sich an diese Anfrage erinnert, aber in der REST-Architektur wird der Sitzungsstatus auf der Clientseite gespeichert, was den Server effizienter macht und dem Server weniger Arbeitslast für eine feinere Funktion gibt.
- Zuletzt aber nicht minder wichtig ist Rest eine hochleistungsfähige Architektur und unterstützt das Caching.
Wann REST Anwenden
Stell dir vor, du erstellst eine Website für ein Restaurant. Alle Menüs sind online, und die Speisen sind in drei Kategorien unterteilt:
- Vorspeisen
- Hauptgerichte
- Getränke
Nehmen wir nun an, du möchtest alle Getränke online sehen. In der Rest-Architektur kannst du deine Ressourcen leicht und konsistent auf API-Endpunkte aufteilen. Natürlich kannst du mehrere Authentifizierungen verwenden, um sie sicher zu machen.
In solchen Fällen senden wir eine GET-Anfrage an den Server an einen Endpunkt, an dem wir Daten der Getränkeressource erhalten können.
Genauso können wir alle CRUD-Operationen (Erstellen, Lesen, Aktualisieren, Löschen) in der Rest-API ausführen, was sie für große Projekte geeignet macht, die keine übermäßige Datenübertragung benötigen und nicht in Echtzeit sein müssen.
Rest funktioniert am besten für Projekte, bei denen die effiziente Datenübertragung ein wichtiger Faktor ist. Das Caching ist eine weitere Funktion von REST, die für Standardanwendungen wie Essensbuchungs-Apps, Hotelbuchungs-Apps, Blog-Websites, Online-Forum-Websites usw. nützlich ist.
Einschränkungen und Probleme mit REST
REST ist großartig, aber es hat auch viele Nachteile, die in einigen Fällen ziemlich entscheidend sind. Lassen Sie uns darüber sprechen.
- Die Notwendigkeit für bidirektionale Kommunikation.
Was ist, wenn der Server Daten an den Client senden muss? Der Server möchte die Kommunikation initiieren. In der REST-Architektur ist dies nicht möglich. Natürlich können Sie einige Tricks anwenden, aber sie sind nicht praktikabel. - Stellen Sie sich eine Live-Ergebnisse-Website vor. Wie können Sie den Server so verwalten, dass er eine Anfrage an den Client sendet, um die Ergebnisdaten zu aktualisieren? Wir können Clients dazu bringen, jede 10 Sekunden Anfragen zu senden, aber es ist überhaupt keine gute Praxis. Es wird den Server überlasten, was zu Geschwindigkeitsproblemen führen könnte.
- Die REST-Architektur ist rein anforderungs- und antwortorientiert und unterstützt kein Datenstreaming (kontinuierliche Ereignisverarbeitung).
- Die Eigenschaft von REST, zustandslos zu sein, kann als Segen und Fluch angesehen werden, da man auf der REST-Architektur den Zustand der Daten nicht bestimmen kann.
Warum wurde gRPC erfunden?
Um das erste Problem mit REST zu beheben, das die Notwendigkeit für bidirektionale Kommunikation ist, wurde WebSocket erfunden, der es dem Server erlaubt, die Kommunikation zu initiieren, aber das Problem dabei ist, dass es keine Formate hat. Es sendet nur Bytes und hat keine Einschränkungen.
Die Websockets hatten keine Probleme an sich, aber das eigentliche Problem ist, dass jede Art von Kommunikation ein Protokoll erfordert, und jedes Protokoll erfordert eine Clientbibliothek, die mit diesem Protokoll kommunizieren kann.
Wenn Sie eine Python-Anwendung erstellen, die auf der REST-Architektur basiert, benötigen Sie einen HTTP-Client, der mit dem Server kommunizieren kann. In vielen Fällen werden Client-Bibliotheken von Drittanbietern, hauptsächlich unabhängigen Entwicklern, erstellt. Die Verwendung von Drittanbieter-Bibliotheken kann Ihre Sicherheit gefährden, und Ihre gesamte Anwendung hängt von einem Drittanbieter für die Kommunikation ab.
Im Fall einer Webanwendung fungiert der Browser als Client-Bibliothek, aber für nicht-webbasierte Projekte benötigen Sie eine Drittanbieter-Client-Bibliothek. Wenn Sie daran denken, eine eigene zu erstellen, denken Sie daran, dass es nicht so einfach ist und Sie sich mit der Pflege einer weiteren Anwendung belasten.
Um einige Probleme mit REST und Probleme mit Client-Bibliotheken zu beheben, hat Google 2015 gRPC erfunden.
Für gRPC wird eine Client-Bibliothek von Google für fast alle beliebten Sprachen gepflegt. Es verwendet das HTTP/2-Protokoll im Hintergrund und das Protokollbuffer (protobuf) als Nachrichtenformat.
Sie müssen sich keine Sorgen um eine Client-Bibliothek machen, da Google sie für Sie und fast jede Programmiersprache pflegt. Eine einzelne und zentrale Client-Bibliothek ist eine der Hauptvorteile von gRPC.
Ein weiterer Vorteil von gRPC ist das verwendete Nachrichtenformat. Das Protokollbuffer ist sprachunabhängig, sodass Sie Clients in Python und Server in Go erstellen und immer noch ohne Umstände kommunizieren können.
gRPC ist im Wesentlichen eine Client-Bibliothek und ein Protokoll, das auf jedem Gerät verwendet werden kann.
Was ist gRPC?
gRPC verwendet Protobuf zur Kommunikation. Es serialisiert Proto-Dateien in binäre Formate und sendet sie an den Server, und auf der Serverseite werden sie wieder in ihre ursprüngliche Form dekodiert. So funktioniert es mit Protobuf.
gRPC verfügt über verschiedene Arten der Kommunikation. Man kann sie sich als Funktionen von gRPC vorstellen.
Funktionen von gRPC
- Einzelanfrage:Es handelt sich um eine einfache Art der Anfrage-Antwort-Kommunikation, bei der der Client eine Proto-Anfrage sendet und der Server, nachdem er sie empfangen hat, eine gewisse Zeit wartet, um einen Prozess auszuführen und dann eine Antwort zurückgibt.
- Server-Streaming:Bei einer einzigen Anfrage kommt eine Flut von Daten als Antwort vom Server. Zum Beispiel, wenn man auf ein Video klickt, fließt eine Menge an videorelateden Daten vom Server.
- Client-Streaming:Es ist das Gegenteil von Server-Streaming. Hier sendet der Client eine große Menge an Daten auf einmal an den Server. Zum Beispiel passiert dies, wenn man eine große Datei im Internet teilt oder ein Bild oder Video hochlädt. Der Client sendet kontinuierlich Daten an die Serverseite.
- Bi-direktionale Streaming-Kommunikation:In dieser Art der Kommunikation senden sowohl der Client als auch der Server mehrere Nachrichten. Chatten ist ein ausgezeichnetes Beispiel dafür.
Dies sind vier beliebte Funktionen von gRPC, die es so mächtig machen.
Wann gRPC verwenden
Bezüglich der Funktionen von gRPC haben wir einige Anwendungsfälle für gRPC gesehen. Stellen Sie sich vor, Sie möchten eine Chat-Anwendung erstellen. Sie werden die Rest-API nicht verwenden, da sie keine schnelle bidirektionale Kommunikation ermöglicht. Dafür werden wir den gRPC-Stream verwenden, der einige weitere Vorteile als nur Geschwindigkeit bietet.
Erstens ist sein sprachneutrales Verhalten unabhängig davon, in welcher Programmiersprache der Server oder andere Clients geschrieben sind. Die Kommunikation kann immer noch aufgebaut werden, solange das Nachrichtenformat akzeptiert wird.
Mit dieser Funktion kann die Android-Version der Chat-App also mit der iOS-Version kommunizieren und umgekehrt.
Probleme mit gRPC
Es gibt Probleme mit allem, einschließlich gRPC.
- Begrenzte Browserunterstützung:gRPC verwendet HTTP 2, daher ist es schwer, den gRPC-Dienst direkt aus dem Browser aufzurufen, was manchmal das Einrichten eines Proxys erfordert.
- Nicht lesbare Form:Wie wir alle wissen, verwendet gRPC ein binäres Format, das für Menschen nicht lesbar ist. In einigen Fällen ist dies ein Nachteil.
- Mangelnde Reife:gRPC wurde 2015 entwickelt, daher ist es im Vergleich zu REST noch etwas unreif und viele Fehler und Probleme müssen gelöst werden.
- Lernprobleme:Rest und GraphQL verwenden JSON, was einfacher zu erlernen ist. Die meisten Leute werden versuchen, bei ihnen zu bleiben, da Protobuf immer noch ein neues und komplexes Thema ist, so dass es schwer sein wird, Experten für gRPC zu finden.
REST vs. gRPC:
Jetzt werden wir den technischen Unterschied zwischen REST und gRPC diskutieren.
Nachrichtenformat:
Das von REST verwendete Nachrichtenformat ist meist JSON (manchmal auch XML-Format), was eine lesbarere Form ist und leichter zu handhaben ist. Sie müssen sich nicht um das Schema in Rest kümmern. Andererseits verwendet gRPC ein Protokollbuffer zum Serialisieren von Daten. Die komprimierte Form ist leichter und schneller zu übertragen. Es ist im binären Format, sodass es Daten zum Übertragen serialisiert und deserialisiert.
HTTP 1.1 vs. HTTP 2:
Die Rest-API verwendet normalerweise HTTP 1.1 als Protokoll, während gRPC HTTP 2 als Protokoll im Hintergrund verwendet. Die Rest-API kann zwar weiterhin HTTP 2 verwenden, ist jedoch aufgrund des Anforderungs-Antwort-Mechanismus begrenzt. gRPC verwendet HTTP 2 und nutzt die Unterstützung von HTTP 2 sowohl für Client-Antwort als auch für bidirektionale Kommunikation. Dies ist ein weiterer Aspekt, der die Leistung von gRPC besser als REST macht. Es kann einseitige Anforderungen wie HTTP 1.1 und bidirektionale Anforderungen gleichzeitig wie HTTP 2 verwalten.
Latenz:
Die geringe Latenz und hohe Geschwindigkeit von gRPC in der Kommunikation machen es für den Zusammenhang mit Systemen nützlich, die aus einer leichtgewichtigen Microservices-Architektur bestehen, was die Effizienz der Nachrichtenübertragung erhöht. In den meisten Fällen des Netzwerks beträgt die Latenz von REST 25 ms, während die Latenz von gRPC weit weniger als REST ist.
Nutzlastgrenze:
Rest hat eine maximale Nutzlastgrenze von 45 MB bei der Übertragung von ausgehenden Nachrichten, während gRPC keine Grenze hat, was bedeutet, dass Ihre ausgehende Nachricht so schwer sein kann, wie Sie möchten.
Sicherheit:
In Bezug auf Sicherheit wird Rest zurückbleiben, da es HTTP 1.1 und das JSON-Format verwendet, die leicht zu entschlüsseln und zugänglich sind. Im Gegensatz dazu verwendet gRPC HTTP 2, was weitaus sicherer ist, und benutzt Protobuf, das im Binärformat vorliegt und schwer zu entschlüsseln ist.
Geschwindigkeit:
Auch hier kommt gRPC als Sieger heraus, da es 10x schneller ist als Rest, und zwar aus dem gleichen Grund, nämlich die Verwendung von HTTP 2 als Protokoll und Protobuf als Nachrichtenformat.
Die Code-Generierungsfunktion
Rest bietet keine integrierten Code-Generierungsfunktionen, was bedeutet, dass der Entwickler Drittanwendungen benötigt, um API-Code zu erzeugen, während gRPC aufgrund seines Protobuf-Compilers native Code-Generierungsfunktionen hat, der mit mehreren Programmiersprachen kompatibel ist. Dies ist ein weiterer Vorteil, insbesondere für Microservice-Architekturen.
Memphis REST Gateway
Um die Nachrichtenproduktion über HTTP-Aufrufe für verschiedene Anwendungsfälle und die Benutzerfreundlichkeit zu ermöglichen, hat Memphis einen HTTP-Gateway hinzugefügt, um REST-basierte Anfragen (also Nachrichten) zu empfangen und diese Nachrichten an die erforderliche Station zu produzieren.
Allgemeine Anwendungsfälle, die vom REST Gateway profitieren, sind:
- Direktes Erzeugen von Ereignissen aus der Frontend-Anwendung
- Verbindung von Debezium über HTTP Server
- ArgoCD Webhooks
- PostHog-Integration
- Empfangen von Daten aus Fivetran/Rivery/Jeder ETL-Plattform über HTTP-Aufrufe
Memphis REST Gateway + ein JSON-Schema kann eine kraftvolle Kombination sein, um die Datenqualität zu erhöhen und eine gesunde Kommunikation zwischen Anwendungen oder Diensten zu gewährleisten.
Memphis wird in Kürze auch gRPC unterstützen.
Zusammenfassung
Letztlich möchte ich sagen, dass REST nach wie vor die am häufigsten verwendete und beliebteste Architektur ist und es unmöglich ist, sie aufzugeben. REST hat viele Nachteile, wie zum Beispiel fehlende Datenströme, keine bidirektionale Kommunikation, langsamer Geschwindigkeit usw., aber es ist am besten für Standardanwendungen, die wir im täglichen Leben sehen.
Auf der anderen Seite bietet gRPC, obwohl jung und schwer zu erlernen, viele Dinge wie hohe Datenströme auf der Client- und Serverseite, gute bidirektionale Datenströme, ist schnell und kompakt und verwendet HTTP 2. Aufgrund seiner schnellen Leistung ist gRPC am besten für Anwendungen mit hoher Arbeitsbelastung wie Videostreaming, Songstreaming, Online-Spiele, Datei-Sharing und Chat-Anwendungen geeignet.