Heute sprechen wir über ein Protokoll, das vielen Rest AP is
den Rang abläuft. Grpc was steckt dahinter, wann
ist es sinnvoll und wann auch vielleicht nicht, darüber
sprechen wir in dieser Folge. Und damit ganz, ganz herzlich
willkommen zu einer nigelnagelneuen Folge vom to do
Cast, dem Developer Podcast. Auf Deutsch mit Malte Lantin und
mit mir Robin, Manuel Thiel. Und heute geht es um GRPC.
Wie schon im Intro erwähnt und GRPC ist tatsächlich ein höherer
Wunsch von euch. Erik hat sich das gewünscht aus
unserer Community, Erik, Wenn du zuhörst ganz liebe Grüße es ist
mir aber auch letztens noch mal über den Weg gelaufen und wir
hatten schon n bisschen länger so auf der Liste und haben
gesagt komm jetzt ist es mal Zeit aber bevor wir einsteigen.
Malte eine neue Folge, ein neues Thema und wie geht's dir?
Mir geht's sehr gut. Ein paar ruhigere Tage über
Ostern und von daher bin ich relativ entspannt und freue mich
auf die neueste Folge und in dieser Folge bauen wir auch für
euch wegen Ostern kleines Easter Egg ein und hört die Folge bis
zum Ende und dann schreibt uns eine E Mail, wenn euch das
Easter Egg aufgefallen ist. Wenn ihr es gefunden habt, gibt
es auch ein kleines Geschenk. Ich bin gespannt.
Ich bin gespannt, wieviel das rausfinden.
Also GRPC, das ist Googles moderner Ansatz für RPC, also
für Remote Procedure Calls. Das genau das ist, besprechen
wir gleich noch über und kriegt hat so ein bisschen so eine
Renaissance bekommen vor ein paar Jahren boomt also so bei
internen Microservices, vor allem wenn es um um High
Performance APIS geht, hat aber auch seine Grenzen, also vor
allem im Browser und ist eigentlich so ein bisschen eine
Alternative zu Rest. Also es geht drum, dass in GRPC
oder generell in RPC verschiedene Services oder
verschiedene Clients miteinander kommunizieren, und zwar nicht
auf diese traditionelle Rest Weise, wie wir sie vielleicht
kennen. Also irgendwo gibt es eine API
und da schicke ich in der Regel einen json oder vielleicht aus
der Älteren wird auch noch irgendwie eine XML Datei hin,
die wird dann verarbeitet, sondern es werden ja Funktionen
auf den anderen Teilnehmern dieses Netzwerks aufgerufen,
also RPC. Das steht für Remote Procedure
Call und ist eigentlich n ja n Protokoll oder n Programming
Model, was mir eben erlaubt, dass ich Funktionen direkt
aufrufe, die auf einem auf ja zum Beispiel auf einem Server
bereitgestellt sind. Das sind meistens dann wirklich
Code, Funktionen und der große Benefit davon ist eigentlich.
Dass sich das dann für die Developer so anfühlt, als würden
sie einfach lokale Objekte anprogrammieren, das heißt, ich
kann, aber hab halt irgendwie NN Objekt, das steht für diesen
anderen Server oder für irgendeinen Microservice in
meinem Cluster und ich kann dann da einfach wirklich mit Punkt
funktionsname Klammer auf Klammer zu ne andere Funktion
anrufen aufrufen. Im Hintergrund geht das
natürlich dann trotzdem irgendwie übers Netzwerk, aber
es fühlt sich für mich eben so an, also für mich als Developer
fühlte sich dann, als würde ich einfach ne Funktion aufrufen,
das heißt diese ganze. Netzwerk Stack dahinter wird n
bisschen für mich weg abstrahiert was vor und
Nachteile hat, auf die gehen wir gleich mal so n bisschen ein,
aber das so n bisschen zu Idee und diese Idee, dieses RPC,
dieses Remote procedure Call, das ist auch nicht neu, da gibt
es verschiedene Protokolle, die das implementieren, das gab es
schon mal, json, RPC und XMLRPC und sowas und die sind nicht
alle gleich, aber Google hat jetzt irgendwie vor n paar
Jahren mit GRPC und ihren Protokoll buffern die sehr auf
Performance getrimmt sind. Dieses ganze Thema wieder so n
bisschen zum Leben erweckt, vor allem in der Cubanitas Welt.
Was du gerade gesagt hast, fand ich ganz interessant, dass es ja
schon in der Vergangenheit diverse APC Frameworks und
Technologien gab, aber die dann so n bisschen in den Hintergrund
gerückt sind als immer mehr webapplikationen und auch
verteilte Webapplikationen mit unterschiedlichen Services
hochgekommen sind. Und man hatte irgendwie dann
lange Zeit das Gefühl, es gibt eigentlich nur noch einen
Standard, nämlich Rest, den irgendwie alle genutzt haben, um
die Kommunikation zwischen Komponenten einer Webapplikation
herzustellen. Das kann natürlich zwischen
verschiedenen Webservices sein, das kann aber auch zwischen dem
Client und einem Webservice sein und da gibt es natürlich immer
wieder Herausforderungen, gerade auch weil das Restformat in der
Regel. Große Dokumente hin und her
schickt und auch dort über den Standard HTTP stack geht und von
daher finde ich es ganz spannend, dass seit einigen
Jahren, das ist ja nichts Neues mit GAPC, das gibt es ja jetzt
seit über 10 Jahren, aber es wird immer populärer,
Technologie wieder aufgegriffen wird, die es in der
Vergangenheit schon gab, aber. Diese Brücke schlägt in diese
moderne Micro Service Welt und speziell dafür auch von Google
entwickelt wurde. Du hast es gerade gesagt, kam
von Google, ist jetzt ein Projekt innerhalb der Cloud
Native Computing Foundation, das heißt es wurde in die Foundation
überführt und wird dort als Open Source Projekt vorangetrieben,
vorangetrieben aber ganz ursprünglich wie gesagt gab es
bei Google internen Projekt, Ich glaube das hieß Stubby wo die.
Eine interne Kommunikationsplattform
entwickelt wurde, um gerade in diesen großen Microsoft
Architekturen, die Google nutzt, die Kommunikation zu realisieren
oder zu beschleunigen. Und daraus hat sich dieses
Projekt entwickelt. Dementsprechend steht auch das G
in GAPC für Google Fragezeichen. Nee, nämlich nicht das Denken,
glaube ich immer alle. Das ist eigentlich ein totaler
Brand, frage, weil laut der GAPC Webseite.
Steht das G and GRPC für GRPC, das heißt, GRPC heißt eigentlich
GAPCGAPCGAPCGAPC, also ist eigentlich unendlicher Loop,
weil die sagen das G Shi für GAPC und das RPC Shi für Remote
Procedure Call aber. Das ist so n bisschen so an, als
hätten sie sich das ausgedacht, nachdem Google gesagt hat, GAPC
für Google APC wird jetzt. Ein Community Projekt und
dementsprechend kann der Name Google da nicht mehr drin sein.
Also alle, weil alles andere in diesem Google Cosmos, wo NG
irgendwie vorkommt. Das steht ja immer für Google.
Also ich finde es auch ein bisschen in Hahnenvorwechselung,
aber es ist die offizielle Begründung, wie gesagt ist aber
schon lange nicht mehr nur in der Google Welt, sondern ist so
ein bisschen wie wie Kubernet ist halt das irgendwie ist dann
da entstanden, wahrscheinlich auch aus dem Need, dass die das
brauchten, weil wir hatten es ja eben schon an an angeteasert,
ist absolut Performance optimiert.
Das liegt halt daran, dass ich halt sonst jedes Mal, wenn ein
Microservice mit dem anderen spricht, ne Netzwerkverbindung
aufbauen muss. N Headshack machen muss.
Du hast es gerade schon gesagt, habe es große Dokumente, also
einfach im JSON Format hin und her, schicke die ja
menschenlesbar sind, aber ich will ja vielleicht irgendwie in
der Lage sein sehr sehr schnell komprimierte Daten hin und her
zu schicken, jedes Mal dieses Netzwerk aufzubauen und dafür
ist dann eben. Gapc optimiert worden und da
sieht man es auch heute am meisten.
Also wenn ich es in Projekten sehe und ich habe es auch schon
einmal selber eingebaut, aber es gibt auch viele so Tools wie
Depper dies verwenden, dann sieht man es vor allem so oft
der letzten Meile von irgendwie einer Ende zu Ende, Architektur
also oft schon innerhalb, also innerhalb des Rechenzentrums
oder eben innerhalb des Clusters, wenn 2 Microservices
zwischen Servern sehr effizient und sehr schnell miteinander
kommunizieren müssen. Aber tatsächlich kann ich die
Applikation ja auch verteilen über verschiedene Rechenzentren,
die. Hinweg und kann trotzdem genauso
diese, diese Kommunikations, diesen Kommunikationsweg
verwenden. Ich kann es aber theoretisch
auch verwenden, wenn ich mobile Apps baue, um dann zwischen
meiner mobile App und meinem Backend zu kommunizieren.
Teilweise funktioniert es auch auf anderen Geräten, die ich
anbinden möchte, aber es ist durchaus mehr als eine
Technologie, die nur in diesem. Microservice Cosmos stattfindet,
wo ich Service to Service Kommunikation implementieren
möchte, sondern ich kann es tatsächlich auch darüber hinaus
verwenden. Technisch ja, man sieht es aber
fast nie. Also man muss dazu sagen, dass
es vor allem im Webbrowser und so auf mobile Apps nur bedingt
funktioniert. GAPC unterstützt auch Streaming,
das gibt zum Beispiel im Browser nicht.
Man muss auch dazu sagen, dass GRPC auf HTTP 2 aufsetzt, also
alles andere, was irgendwie sonst noch HTTP 1.1 spricht.
Was glaub ich immer noch, die der Großteil des Webs ist.
Kann mit GAPC dann erstmal nichts anfangen und diese ganzen
so Edge Geräte, Endgeräte, Clients, die können es
theoretisch, aber dann sind aber oft nicht nativ sondern sind oft
irgendwelche Libraries noch notwendig die die so n bisschen
faken oder die irgendwas umwandeln also man.
Man sieht es doch klassischerweise eigentlich fast
immer nur, also zwischen Services irgendwo im Backend.
Das Schöne ist, ich kann es in fast jeder Programmiersprache
verwenden. Dort gibt es einzelne Community
Projekte, die dann im Rahmen dieses gapc Projektes die
einzelnen Implementierungen für die verschiedenen.
Programmiersprachen ownen egal ob ich jetzt irgendwie in C plus
plus, in Go oder in C, Sharp oder in anderen unterwegs bin,
gibt es da grpc Implementierung und ich kann dementsprechend,
egal mit welcher Technologie, immer auf die gleiche Art und
Weise arbeiten. Das heißt, ich habe eine Art von
Client, die Methoden auf einem entfernten Server aufrufen kann,
so ähnlich wie ich lokale Methoden aufrufe und diese.
Entfernten Methoden. Die werden natürlich
entsprechend beschrieben, sodass ich auf der kleinen Seite auch
weiß, mit welchen Methoden ich dort interagieren kann.
Und ich kann dann als Developer tatsächlich ganz traditionell
arbeiten, wie mit den Methoden meiner lokalen Klassen, und
diese werden dann über das Netzwerk ausgeführt, das heißt,
im Hintergrund werden über diese entsprechenden Bibliotheken von
Grpc, die ich habe, meine Daten entsprechend.
Komprimiert. Wir gehen gleich noch mal auf
den auf die Details ein, wie das Ganze im Hintergrund läuft und
dann entsprechend über das Netzwerk übertragen und dann
auch die Antworten zurück übertragen, die ich dann in
meiner Applikation verwenden kann.
Genau. Jetzt hattest du ja eigentlich
gerade schon was Spannendes angesprochen, nämlich so ein
bisschen, wie es die Developer Experience, die ist nämlich
eigentlich sehr, sehr gut bei Grpcr, weil wie gesagt, es gibt
eigentlich für jede Programmiersprache irgendwie
eine Implementierung, was aber spannend ist, ist, dass ich
Server und Frontend, also Backend und Frontend eigentlich.
Etwas teilen nämlich diese sogenannte Proto Datei, das ist
eigentlich der ja häufig so der, der der Start einer grpc
Implementierung und auch so ein bisschen die Single Source of
Truth und damit fängt alles an. Es ist tatsächlich eine Datei
mit der mit der Dateiendung Punkt Proto, die muss manuell
erstellt werden von den Developern und die definiert,
die definiert eigentlich alles Services die es gibt und alle
Methoden die man in diesen Services aufrufen kann.
Und dann auch Nachrichten, also diese GAPC Welt ist alles ne,
was vielleicht bei bei bei Rest irgendwie n json Dokument das so
hin und her schickt sind Nachrichten aber auch dann da
die Feldtypen und Nummern und alles was es irgendwie darin
gibt werden halt einmalig in dieser Datei beschrieben, das
heißt in der Datei wird beschrieben was sind denn diese
Remote Procedure Calls die ich auf einem GAPC Server aufrufen
kann und das wird einmal manuell gemacht.
Das ist aber auch sehr, das sieht sehr sehr lesbar aus, das
sieht ein bisschen wieso ne kleine eigene Programmiersprache
aus, aber. Ist genau also jeder, der schon
mal irgendwie programmiert hat, wird sich da relativ schnell
drin zurechtfinden und diese Prototatei, die wird irgendwo
zentral bereitgestellt und auf Basis dieser Prototatei kann der
Client hingehen und sich eigentlich sowas wie ja man
nennt das auf den Programmiersprachen irgendwie
ein ein Stab oder in manchen Promi auch ein API Client, den
kann man sich dann eben daraus generieren.
Das heißt ich habe dann irgendwas, das liest diese Punkt
prototatei ein. Und weiß und stellt mir dann
diese Methoden eben bereit. Und genauso kann der Server
hingehen und diese putto Datei nehmen und einlesen und
daraufhin die Methoden implementieren, die da definiert
werden. Das heißt ich hab das ist wie
sowieso ein Contract zwischen meinen Clients und den Servern,
ich weiß alles was es in dieser Datei gibt, das kann ich ja
wirklich verwenden und das nimmt auch wirklich genau diese
Datentypen entgegen. Und erstelle mir dann für meine
Programmiersprache den Client und für die Programmiersprache
meinem Server irgendwie sowas wie sowieso n Interface.
Was ich dann implementieren muss.
Irgendwie so abstrakte Klasse oder irgendwas was ich halt
dadurch implementieren muss. Also es heißt ja in jeder
Programmiersprache so n bisschen anders und so teilen die sich
eigentlich diese Single Source of Truth, diese API Definition
und das ist auch so n bisschen das was was GAPC so magisch
macht, weil das dadurch ganz ganz stark typisiert, was
eigentlich ja nicht typisiert ist, nämlich so netzwerktraffic
und ich kann dann gar nicht irgendwie.
In JSON falsch formatiert dahin schicken oder groß und
Kleinschreibung verwechseln oder irgendwie in diesem json
irgendwie eine Tippfehler drin haben oder eine Datei anders
schreiben, weil die ich eben diesen Vertrag, diesen Punkt
Toto file einmal habe, an den sich sowohl der Client, also der
Server halten. Die Idee ist so ein bisschen
ähnlich zu diesen. Web Service Definition, wie ich
Sie vielleicht von Open API kenne, wo ich mir dann auch
vielleicht einen Client generieren kann aus einer Open
Open API Definition und das ist ein bisschen die Idee, dass ich
durch diesen Stab, den ich ja lokal dann auf meiner auf der
Client Seite habe, dann wie mit einer lokalen Klasse oder
lokalen Methoden interagieren kann und der ganze
Netzwerktraffic, dass ich dort eine entfernte Funktion aufrufe,
auf einem anderen Seite. System wird dementsprechend für
mich weg abstrahiert, aber das ist tatsächlich in Grpc der
Standardfall und bei Rest bauen wir tatsächlich unsere Queries
häufig entweder selber zusammen oder wir haben irgendwie eine
Client Library, die wir runterladen und der Fall, dass
man sich standardisiert solche Clients generiert auf einer
Definition ist ja nichts, was per se in der.
In einer bestimmten Spezifikation für die Nutzung
von West Schnittstellen vorgesehen ist.
Genau. Und ich muss mir dann ja auch
selber diesen diesen Stop oder diesen API Client generieren und
es sagt ja auch keiner garantiert mir auch keiner, dass
der Server dann wirklich das alles auch so implementiert hat.
Also es ist halt irgendwie ja, es ist eine sehr starke
Typisierung und es ist mehr als nur das, also das ist erstmal
die Art und Weise wie ich als Developer damit arbeite, der
Grund warum ich als developer damit arbeite ist aber
wahrscheinlich weniger, dass es diesen Contract gibt, das ist
eher was Angenehmes. Sondern eben, weil Gapc ja auf
auf einer technischen Perspektive besonders ist.
Und die hat eben schon gesagt, es baut auf HTP 2 auf.
Das heißt es, es unterstützt sogenanntes Multiplexing, was
vor allem bedeutet, dass ich weniger TCP Verbindungen
brauche. Es ist auch ein binäres
Protokoll, ist also deutlich kleiner, ich kann die ich kann
Kompression bei bei den Headern machen, aber auch bei dem Inhalt
der Sachen die ich hin und her schicke, das heißt das ist schon
deutlich. Klein und vor allem deutlich
schneller. Es hat n also ich Krieg vor
allem so in so Low latency Szenarien, wenn ich n höheren
Trueput brauche wenn ich irgendwas high Performance
optimieren möchte im auf der letzten Mail oder zwischen
Microservices, da bietet sie sich an, vor allem weil es auf
einem eigenen, ja eigenen Protokoll von in dem Fall auch
von Google aufbaut, das nennt sich Proto Buff und das ist
eigentlich n. Ja, n Binäres
Serialisierungsformat, also deutlich kleiner und deutlich
schneller als Jason. Und mit dieser starken
Typisierung, die wir eben schon angesprochen haben, also
unterstützt dann quasi einfach Int und float und und string und
und sowas und wird dann quasi komplett ja komprimiert und
dadurch deutlich schneller durch die Leitung gepresst.
Das heißt? Eben Default File nutze ich dort
dieses Realisierungsformat. Die Dateien werden entsprechend
für mich Serialisiert in dieses Binärformat werden in diesem
übertragen, was natürlich bedeutet, wenn ich mir den.
Entsprechenden Traffic anschaue, kann ich den als Mensch nicht
mehr lesen, weil keine json Dateien oder xml Dateien etc.
Übertragen werden, sondern es wird dieses Binärformat
übertragen. Aber du hattest gesagt, man kann
auch von diesem Standard abweichen und JSON verwenden.
Hast du das selber schon mal gemacht?
Ja ne, gemacht habe ich es nicht, aber ich weiß man muss
keinen Proto Buff verwenden. Man kann einfach auch durch eine
Konfiguration auf json umschalten, das hilft dann
zumindest so ein bisschen beim beim Debugging das.
Sieht man dann wahrscheinlich in in Production nicht mehr, aber
der Standard ist eben dieses Protobof und du hast ja gerade
schon ganz richtig gesagt, einer der größten Nachteile ist, dass
es eben nicht mehr menschenlesbar ist und deswegen
ja ist es auch nicht für alles geeignet und oft wenn man es
dann irgendwie, also man kann das dann doch irgendwie
natürlich wieder auslesen, aber dafür braucht es dann wieder
andere Tools, ist also nicht so ganz einfach.
GRPC kommt auch noch mit so 23 anderen kleinen coolen Tools,
die schon eingebaut sind, also die die sehr schlauen Köpfe
dahinter haben sich auch so ein paar Gedanken gemacht, wofür
wird das denn eigentlich verwendet?
Also a es kann eigentlich alles was wir so aus dieser normalen
Restwelt kennen, also es das unterstützt wie gesagt ist auch
Streaming von Nachrichten, das brauche ich auch, vor allem oft
in so einem highperformance Szenario, unterstützt aber auch
TLS nativ authentifizierungstokens also
dieses ganze anmelden an einem anderen Server.
Hat aber auch schon so Konzepte wie Load Balancing mit drin.
Also zumindest so kleinseitig. Ich kann dann, wenn man ne auf
da steht man besteht man Microservices aus mehreren
Instanzen und die kann ich dann auch über GAPC miteinander
verbinden, sodass die untereinander mit sich ausmachen
können, wer jetzt diese Nachricht, die reinkommt, gerade
geradeaus führt. Also da sind schon so n paar
ganz coole Sachen für genau diese Microservices
Anwendungsfälle mit in das Protokoll eingebaut und die
machen dann tatsächlich auch ja die die Nutzung vielleicht von
so einem externen Globalancer zumindest für diese GAPC
Szenarien überflüssig oder einfacher.
Und das ist tatsächlich auch der Grund, dass da einfach mehr
Logik gerade noch in dieses Netzwerkprotokoll mit
aufgenommen wird. Warum es auch so viele Fans um
GRPC gibt? Weil es eben mehr ist als nur
dieses Protokoll und nur diese super performante Geschichte,
sondern eben auch weil diese Convenience Tools drumherum hat,
wie dieses Load Balancing, wie eben diese Punkt photodatei, wo
ich mich dann mit auf starke Typisierung verlassen kann und
so weiter. Wir haben jetzt ganz viel über
die Vorteile gesprochen und das ist ja für Developer sehr
komfortabel. Ist das Ganze einzusetzen, weil
es die entsprechenden Bibliotheken für alle möglichen
Sprachen gibt. Wir haben die großen Vorteile
rund um weniger Netzwerktraffic wirklich?
Können schneller kommunizieren zwischen den einzelnen Services.
Und wir haben halt auch strenge Typisierung über die Definition
der einzelnen Services beziehungsweise Methoden, die
wir dort über die Protodatei dokumentieren.
Wann sollte ich denn jetzt grpc nicht einsetzen oder was sind
die Nachteile jenseits dessen, was wir gerade schon
angesprochen haben, dass wir halt den Netzwerk Traffic jetzt
nicht mehr. Menschen lesbar haben, sondern
in einem Binärformat. Was sind da weiter weitere
Punkte, wo ich jetzt weiterhin vielleicht auf Rest setzen
sollte? Ich würde sagen, so die neben
neben diesen typischen Schwächen ist Rest einfach auch so offen
und so verbreitet und so jetzt mal einsteigerfreundlich, dass
ich würde sagen würde so alles was json und Rest passiert.
Es gewinnt eigentlich in allen Situationen wo.
Ja, Offenheit und Flexibilität vielleicht.
Wichtiger ist als Performance einfach.
Ich hab ne ne API die ich von der ich möchte, dass sie von
externen verwendet wird. Ne es ist GAPC natürlich
deutlich nischiger und also natürlich n bisschen höheren
Initialaufwand im Vergleich zu zu zu rests.
Also alles wenn ich irgendwie so Sir Party Systeme anbinden
möchte, wenn ich selber vielleicht n Sir Party System
für andere. Bereitstelle, wenn es halt
irgendwie darum geht, dass ich vielleicht n Open Source Produkt
baue oder ne. Also dann wenn ich sage wenn ich
sage ich muss das hier nicht Performance optimieren, dann
glaube ich ist es Jason halt auch immer noch offener,
flexibler und lesbarer und ich würde auch gar nicht sagen, dass
die RPC irgendwie jetzt n Rest Ersatz ist, sondern es ist eher
halt n spezialisiertes Tool was seinen bestimmten Einsatz Fälle
hat. Dann lass uns noch mal ein paar
Szenarien durchsprechen und schauen, welche Technologie dort
vielleicht am besten geeignet ist und ob man Gapc in Erwägung
ziehen sollte, ja oder nein. Ein Thema, was wir am Anfang
schon angesprochen hatten und wo Gapc natürlich auch so ein
bisschen herkommt, ist das Thema Micro Services und.
Da kann man, glaube ich sagen, ganz klare Empfehlung, sich Grpc
anzuschauen. Man hat die entsprechende
Performance, man kann auf Typsicherheit setzen und man
kann über verschiedene Technologien hinweg diese
Kommunikation aufbauen, sicherstellen und kann
dementsprechend sehr schnell und sicher kommunizieren zwischen
den eigenen Diensten. Dann das Thema Streaming.
Echtzeit Kommunikation kann auch Chats, Telemetriedaten würde ich
auch sagen, ja ganz klar Duapc empfehlen.
Gerade für diese native Unterstützung, auch für
bidirektionale Kommunikation und Streaming, also alles was
Echtzeit ist, kann man sich gpc auch mal anschauen.
Und innerhalb dieser beiden Szenarien, die wir gerade schon
besprochen haben, haben wir natürlich auch noch die
Variante, wo wir unterschiedliche Technologien
verwenden. Das heißt, wir haben vielleicht
auf der einen Seite haben wir irgendwie einen Java Service,
der kommuniziert mit einem anderen Service des in Go
geschrieben und wenn wir da natürlich einen einheitlichen
Standard haben mit einem gleichen Format zur Beschreibung
der. Der entsprechenden Methoden ist
das ein großer Vorteil und dementsprechend gerade auch in
solchen Szenarien gapc eine Empfehlung wo?
Ich es nicht empfehlen würde. Ganz klar ist sowas wie
öffentliche AP is, das haben wir eben schon gesagt, alles was
irgendwie der öffentliche ist oder vielleicht auch die
Kommunikation zwischen einem Backend und einem Browser ist
würde ich sagen nee, aber der Browser Support einfach sehr
begrenzt ist und b jeweils sehr schwer zu debuggen ist.
Von daher würde ich da wahrscheinlich kein Gapc
empfehlen. Vielleicht aber auch ganz
allgemein. Immer wenn man externe Systeme
anbindet. Ist es durchaus sinnvoll, einen
sehr interoperablen Standard wie zum Beispiel JSON in der
Kommunikation zu verwenden und sich mit Grpc eher auf die
interne Kommunikation zwischen den einzelnen Komponenten der
eigenen Anwendung zu konzentrieren?
Genau. Wenn ich mir dann sowas angucke
wie Sachen so die theoretisch gehen.
Also ja, ich kann ja irgendwie schon auch von einer mobile App
mit einem Backend über Grpc kommunizieren, da gibt es
Libraries, die das so ein bisschen umwandeln.
Nicht auch ganz theoretisch gibt es auch Sachen für im Web, die
das in dem Browser dann doch irgendwie wieder ermöglichen.
Aber nicht alle Features machen würde ich sagen.
Vielleicht also muss muss man sich glaube ich angucken, das
kann sehr effizient sein, also wenn man wirklich auf
Performance trimmen muss, weil man irgendwie Streaming braucht,
dann dann dann vielleicht aber würde ich mir wirklich
überlegen, weil es halt eben noch mal noch mal ein ganz
anderes Setup und dieses Tooling erfordert.
Da vielleicht so n bisschen die Empfehlung.
Es gibt n ganz cooles Tool, das heißt GRPC Gateway und das kann
man so n bisschen in sein API Gateway einbauen, das ist n Tool
was eigentlich so ne Brücke zwischen Rest und GRPT spannend,
das heißt das akzeptiert dann bis zum API Gateway hin die
normalen Rest Calls wandelt die dann aber in GRPC Aufrufe um und
leitet das an GRPC Server weiter.
Ich weiß nicht ob das auch mit Streaming funktioniert, aber das
ist auch so n bisschen so n so n so n zwischentool ich finde das
ganz ganz cool, weil das auch unter anderem das Thema ist
warum ich jetzt wieder auf GRPC gestoßen wurde.
Das würden wir einfach mal mal verlinken, falls das irgendwie
spannend ist. Damit kann man so n bisschen so
ne Zwischenbrücke gehen, aber ich würd generell so n sagen
doch eher für Inter microservice Kommunikation.
Ich glaub da glänzt es und alle anderen Sachen so.
Muss man sich eben anschauen. Zusammenfassend lässt sich
glaube ich sagen, dass Grpc nicht besser ist als eine
Kommunikation über Rest, sondern es ist einfach eine andere Art
der Implementierung, die ganz eigene Trade Offs mit sich
bringt. Das heißt, ich habe eine ideale
Technologie für Performance, kritische Kommunikation,
vielleicht über verschiedene Technologien hinweg,
insbesondere mit einer Stärke im Microservice, im Streaming etc.
Aber ich habe an auf. Auf der anderen Seite
Herausforderungen, wenn es darum geht, wie debugge ich das ganze,
wie offen ist das auch, wie Menschenlesbar dementsprechend
muss ich mich in jedem Fall weiterhin entscheiden, welche
Technologie ich einsetze und ich glaube, wir hatten es gerade
gesagt für das Thema so Web, Frontend oder APIS die Party
Zugriffe erlauben, sollte man durchaus weiter Rest oder Graph
QL. Schnittstellen anbieten, da
diese einfach auch von Menschen einfacher genutzt werden können.
Genau. Also ich würde sagen Gapc
zusammenfassend, es ist cool wegen dieser protodatei Contract
First, super stark typisiert, sehr effizient und Rest ist halt
dann die offene Alternative, viel flexibler, viel einfacher
zu debuggen. Also ich habe für mich so ein
bisschen diese Faustregel, interne Services oder
Performance ist wichtig gapc. Offene AP is Web oder
drittanbieterintegration dann halt Rest.
Oder wie du gerade sagst Graph Quell.
Was auch eigentlich ein super spannendes Thema ist, für das
wir aber will einfach mal eine eigene Folge machen.
Ich glaube Graph Quell hat man noch gar nicht irgendwie, aber
das ist so ein bisschen meine Faustregel und ich glaube damit
fährt man ganz gut. Wir hoffen, das Thema war für
euch genauso spannend wie für uns, da noch mal tiefer
einzusteigen. Und wie immer, wenn euch diese
Folge gefallen hat, lasst uns gerne eine positive Bewertung.
Da das könnt ihr machen auf Apple Podcast oder Spotify.
Und wie immer freuen wir uns natürlich auch sehr, wenn ihr
uns den einen oder anderen Kaffee ausgebt.
Das könnt ihr machen über die Webseite bei mir Coffee, den
Link findet ihr in den Show Notes.
Wenn ihr glaubt, dass ihr unser kleines Easter Egg gefunden
habt, also wenn ihr sagt, Hey, ich glaube, ich weiß, was in
dieser Folge anders war als bei vielen Folgen zuvor, dann
schreibt uns auch gerne eine E Mail und mal gucken, ob ihr es
findet. Da gibt es wie gesagt ein
kleines Ostergeschenk, schreibt uns einfach eine Mail, die
findet ihr auch unten in der Beschreibung von der Podcast
Folge und auch da findet ihr einen Link, wenn ihr uns quasi
einen Kaffee ausgeben wollt, da freuen wir uns immer sehr oder
wenn ihr zu eurem eigenen Kaffee die passende Nerd Tasse haben
wollt, haben wir so einen kleinen Fanshop, schaut also
gerne vorbei und ansonsten. Bleibt uns nicht mehr viel zu
sagen, als habt eine gute Zeit. Hört auch in 2 Wochen wieder zu,
denn der To do Developer Podcast erscheint alle 2 Wochen und
schreibt ganz viel Code. Und natürlich kommuniziert
effizient. Wie mit Gfpc macht's gut.