1
00:00:00,040 --> 00:00:03,200
Heute sprechen wir über ein 
Protokoll, das vielen Rest AP is

2
00:00:03,200 --> 00:00:07,960
den Rang abläuft. 
Grpc was steckt dahinter, wann 

3
00:00:07,960 --> 00:00:11,280
ist es sinnvoll und wann auch 
vielleicht nicht, darüber 

4
00:00:11,280 --> 00:00:20,480
sprechen wir in dieser Folge. 
Und damit ganz, ganz herzlich 

5
00:00:20,480 --> 00:00:24,080
willkommen zu einer 
nigelnagelneuen Folge vom to do 

6
00:00:24,080 --> 00:00:29,680
Cast, dem Developer Podcast. 
Auf Deutsch mit Malte Lantin und

7
00:00:29,680 --> 00:00:33,320
mit mir Robin, Manuel Thiel. 
Und heute geht es um GRPC. 

8
00:00:33,320 --> 00:00:38,120
Wie schon im Intro erwähnt und 
GRPC ist tatsächlich ein höherer

9
00:00:38,120 --> 00:00:40,720
Wunsch von euch. 
Erik hat sich das gewünscht aus 

10
00:00:40,720 --> 00:00:44,800
unserer Community, Erik, Wenn du
zuhörst ganz liebe Grüße es ist 

11
00:00:44,800 --> 00:00:46,800
mir aber auch letztens noch mal 
über den Weg gelaufen und wir 

12
00:00:46,800 --> 00:00:48,800
hatten schon n bisschen länger 
so auf der Liste und haben 

13
00:00:48,800 --> 00:00:52,320
gesagt komm jetzt ist es mal 
Zeit aber bevor wir einsteigen. 

14
00:00:53,200 --> 00:00:57,200
Malte eine neue Folge, ein neues
Thema und wie geht's dir? 

15
00:00:57,520 --> 00:01:00,640
Mir geht's sehr gut. 
Ein paar ruhigere Tage über 

16
00:01:00,640 --> 00:01:05,840
Ostern und von daher bin ich 
relativ entspannt und freue mich

17
00:01:05,840 --> 00:01:09,600
auf die neueste Folge und in 
dieser Folge bauen wir auch für 

18
00:01:09,600 --> 00:01:14,560
euch wegen Ostern kleines Easter
Egg ein und hört die Folge bis 

19
00:01:14,560 --> 00:01:18,480
zum Ende und dann schreibt uns 
eine E Mail, wenn euch das 

20
00:01:18,480 --> 00:01:21,520
Easter Egg aufgefallen ist. 
Wenn ihr es gefunden habt, gibt 

21
00:01:21,520 --> 00:01:23,520
es auch ein kleines Geschenk. 
Ich bin gespannt. 

22
00:01:23,520 --> 00:01:25,640
Ich bin gespannt, wieviel das 
rausfinden. 

23
00:01:25,640 --> 00:01:30,960
Also GRPC, das ist Googles 
moderner Ansatz für RPC, also 

24
00:01:30,960 --> 00:01:33,920
für Remote Procedure Calls. 
Das genau das ist, besprechen 

25
00:01:33,920 --> 00:01:36,760
wir gleich noch über und kriegt 
hat so ein bisschen so eine 

26
00:01:36,760 --> 00:01:39,760
Renaissance bekommen vor ein 
paar Jahren boomt also so bei 

27
00:01:39,760 --> 00:01:42,400
internen Microservices, vor 
allem wenn es um um High 

28
00:01:42,400 --> 00:01:46,080
Performance APIS geht, hat aber 
auch seine Grenzen, also vor 

29
00:01:46,080 --> 00:01:47,720
allem im Browser und ist 
eigentlich so ein bisschen eine 

30
00:01:47,720 --> 00:01:52,120
Alternative zu Rest. 
Also es geht drum, dass in GRPC 

31
00:01:52,120 --> 00:01:56,080
oder generell in RPC 
verschiedene Services oder 

32
00:01:56,080 --> 00:01:59,560
verschiedene Clients miteinander
kommunizieren, und zwar nicht 

33
00:01:59,560 --> 00:02:02,520
auf diese traditionelle Rest 
Weise, wie wir sie vielleicht 

34
00:02:02,520 --> 00:02:03,880
kennen. 
Also irgendwo gibt es eine API 

35
00:02:03,880 --> 00:02:06,160
und da schicke ich in der Regel 
einen json oder vielleicht aus 

36
00:02:06,160 --> 00:02:08,160
der Älteren wird auch noch 
irgendwie eine XML Datei hin, 

37
00:02:08,160 --> 00:02:13,360
die wird dann verarbeitet, 
sondern es werden ja Funktionen 

38
00:02:13,360 --> 00:02:16,800
auf den anderen Teilnehmern 
dieses Netzwerks aufgerufen, 

39
00:02:16,800 --> 00:02:20,240
also RPC. 
Das steht für Remote Procedure 

40
00:02:20,240 --> 00:02:24,560
Call und ist eigentlich n ja n 
Protokoll oder n Programming 

41
00:02:24,560 --> 00:02:28,480
Model, was mir eben erlaubt, 
dass ich Funktionen direkt 

42
00:02:28,480 --> 00:02:31,600
aufrufe, die auf einem auf ja 
zum Beispiel auf einem Server 

43
00:02:31,600 --> 00:02:33,320
bereitgestellt sind. 
Das sind meistens dann wirklich 

44
00:02:33,320 --> 00:02:37,920
Code, Funktionen und der große 
Benefit davon ist eigentlich. 

45
00:02:38,320 --> 00:02:41,240
Dass sich das dann für die 
Developer so anfühlt, als würden

46
00:02:41,240 --> 00:02:44,400
sie einfach lokale Objekte 
anprogrammieren, das heißt, ich 

47
00:02:44,400 --> 00:02:47,400
kann, aber hab halt irgendwie NN
Objekt, das steht für diesen 

48
00:02:47,400 --> 00:02:50,040
anderen Server oder für 
irgendeinen Microservice in 

49
00:02:50,040 --> 00:02:53,440
meinem Cluster und ich kann dann
da einfach wirklich mit Punkt 

50
00:02:53,440 --> 00:02:55,680
funktionsname Klammer auf 
Klammer zu ne andere Funktion 

51
00:02:55,680 --> 00:02:57,840
anrufen aufrufen. 
Im Hintergrund geht das 

52
00:02:57,840 --> 00:03:00,760
natürlich dann trotzdem 
irgendwie übers Netzwerk, aber 

53
00:03:00,760 --> 00:03:03,280
es fühlt sich für mich eben so 
an, also für mich als Developer 

54
00:03:03,280 --> 00:03:05,240
fühlte sich dann, als würde ich 
einfach ne Funktion aufrufen, 

55
00:03:05,240 --> 00:03:08,320
das heißt diese ganze. 
Netzwerk Stack dahinter wird n 

56
00:03:08,320 --> 00:03:11,200
bisschen für mich weg 
abstrahiert was vor und 

57
00:03:11,200 --> 00:03:13,440
Nachteile hat, auf die gehen wir
gleich mal so n bisschen ein, 

58
00:03:13,840 --> 00:03:17,120
aber das so n bisschen zu Idee 
und diese Idee, dieses RPC, 

59
00:03:17,120 --> 00:03:20,000
dieses Remote procedure Call, 
das ist auch nicht neu, da gibt 

60
00:03:20,280 --> 00:03:23,120
es verschiedene Protokolle, die 
das implementieren, das gab es 

61
00:03:23,120 --> 00:03:26,600
schon mal, json, RPC und XMLRPC 
und sowas und die sind nicht 

62
00:03:26,600 --> 00:03:29,560
alle gleich, aber Google hat 
jetzt irgendwie vor n paar 

63
00:03:29,560 --> 00:03:33,920
Jahren mit GRPC und ihren 
Protokoll buffern die sehr auf 

64
00:03:33,920 --> 00:03:36,480
Performance getrimmt sind. 
Dieses ganze Thema wieder so n 

65
00:03:36,480 --> 00:03:38,720
bisschen zum Leben erweckt, vor 
allem in der Cubanitas Welt. 

66
00:03:38,960 --> 00:03:41,200
Was du gerade gesagt hast, fand 
ich ganz interessant, dass es ja

67
00:03:41,200 --> 00:03:44,920
schon in der Vergangenheit 
diverse APC Frameworks und 

68
00:03:44,920 --> 00:03:48,160
Technologien gab, aber die dann 
so n bisschen in den Hintergrund

69
00:03:48,160 --> 00:03:51,520
gerückt sind als immer mehr 
webapplikationen und auch 

70
00:03:51,520 --> 00:03:54,360
verteilte Webapplikationen mit 
unterschiedlichen Services 

71
00:03:54,360 --> 00:03:57,440
hochgekommen sind. 
Und man hatte irgendwie dann 

72
00:03:57,440 --> 00:04:00,560
lange Zeit das Gefühl, es gibt 
eigentlich nur noch einen 

73
00:04:00,560 --> 00:04:04,400
Standard, nämlich Rest, den 
irgendwie alle genutzt haben, um

74
00:04:04,560 --> 00:04:08,120
die Kommunikation zwischen 
Komponenten einer Webapplikation

75
00:04:08,120 --> 00:04:10,240
herzustellen. 
Das kann natürlich zwischen 

76
00:04:10,240 --> 00:04:12,800
verschiedenen Webservices sein, 
das kann aber auch zwischen dem 

77
00:04:12,800 --> 00:04:17,800
Client und einem Webservice sein
und da gibt es natürlich immer 

78
00:04:17,800 --> 00:04:22,160
wieder Herausforderungen, gerade
auch weil das Restformat in der 

79
00:04:22,160 --> 00:04:24,640
Regel. 
Große Dokumente hin und her 

80
00:04:24,640 --> 00:04:31,400
schickt und auch dort über den 
Standard HTTP stack geht und von

81
00:04:31,400 --> 00:04:34,000
daher finde ich es ganz 
spannend, dass seit einigen 

82
00:04:34,000 --> 00:04:36,640
Jahren, das ist ja nichts Neues 
mit GAPC, das gibt es ja jetzt 

83
00:04:36,640 --> 00:04:39,600
seit über 10 Jahren, aber es 
wird immer populärer, 

84
00:04:39,760 --> 00:04:42,880
Technologie wieder aufgegriffen 
wird, die es in der 

85
00:04:42,880 --> 00:04:47,200
Vergangenheit schon gab, aber. 
Diese Brücke schlägt in diese 

86
00:04:47,200 --> 00:04:52,560
moderne Micro Service Welt und 
speziell dafür auch von Google 

87
00:04:52,560 --> 00:04:55,680
entwickelt wurde. 
Du hast es gerade gesagt, kam 

88
00:04:55,680 --> 00:04:58,840
von Google, ist jetzt ein 
Projekt innerhalb der Cloud 

89
00:04:58,840 --> 00:05:02,400
Native Computing Foundation, das
heißt es wurde in die Foundation

90
00:05:02,400 --> 00:05:07,440
überführt und wird dort als Open
Source Projekt vorangetrieben, 

91
00:05:07,520 --> 00:05:11,280
vorangetrieben aber ganz 
ursprünglich wie gesagt gab es 

92
00:05:11,280 --> 00:05:15,200
bei Google internen Projekt, Ich
glaube das hieß Stubby wo die. 

93
00:05:15,760 --> 00:05:18,640
Eine interne 
Kommunikationsplattform 

94
00:05:18,640 --> 00:05:21,760
entwickelt wurde, um gerade in 
diesen großen Microsoft 

95
00:05:21,760 --> 00:05:26,000
Architekturen, die Google nutzt,
die Kommunikation zu realisieren

96
00:05:26,000 --> 00:05:28,880
oder zu beschleunigen. 
Und daraus hat sich dieses 

97
00:05:28,880 --> 00:05:31,680
Projekt entwickelt. 
Dementsprechend steht auch das G

98
00:05:31,680 --> 00:05:37,280
in GAPC für Google Fragezeichen.
Nee, nämlich nicht das Denken, 

99
00:05:37,280 --> 00:05:40,320
glaube ich immer alle. 
Das ist eigentlich ein totaler 

100
00:05:40,320 --> 00:05:42,800
Brand, frage, weil laut der GAPC
Webseite. 

101
00:05:43,360 --> 00:05:49,400
Steht das G and GRPC für GRPC, 
das heißt, GRPC heißt eigentlich

102
00:05:49,400 --> 00:05:53,120
GAPCGAPCGAPCGAPC, also ist 
eigentlich unendlicher Loop, 

103
00:05:53,520 --> 00:05:56,880
weil die sagen das G Shi für 
GAPC und das RPC Shi für Remote 

104
00:05:56,880 --> 00:05:59,240
Procedure Call aber. 
Das ist so n bisschen so an, als

105
00:05:59,240 --> 00:06:02,920
hätten sie sich das ausgedacht, 
nachdem Google gesagt hat, GAPC 

106
00:06:02,960 --> 00:06:06,080
für Google APC wird jetzt. 
Ein Community Projekt und 

107
00:06:06,080 --> 00:06:08,400
dementsprechend kann der Name 
Google da nicht mehr drin sein. 

108
00:06:08,560 --> 00:06:11,280
Also alle, weil alles andere in 
diesem Google Cosmos, wo NG 

109
00:06:11,280 --> 00:06:13,480
irgendwie vorkommt. 
Das steht ja immer für Google. 

110
00:06:13,480 --> 00:06:15,480
Also ich finde es auch ein 
bisschen in Hahnenvorwechselung,

111
00:06:15,480 --> 00:06:18,720
aber es ist die offizielle 
Begründung, wie gesagt ist aber 

112
00:06:18,720 --> 00:06:20,720
schon lange nicht mehr nur in 
der Google Welt, sondern ist so 

113
00:06:20,720 --> 00:06:22,880
ein bisschen wie wie Kubernet 
ist halt das irgendwie ist dann 

114
00:06:22,880 --> 00:06:25,400
da entstanden, wahrscheinlich 
auch aus dem Need, dass die das 

115
00:06:25,400 --> 00:06:27,880
brauchten, weil wir hatten es ja
eben schon an an angeteasert, 

116
00:06:27,880 --> 00:06:30,160
ist absolut Performance 
optimiert. 

117
00:06:30,840 --> 00:06:33,360
Das liegt halt daran, dass ich 
halt sonst jedes Mal, wenn ein 

118
00:06:33,360 --> 00:06:36,480
Microservice mit dem anderen 
spricht, ne Netzwerkverbindung 

119
00:06:36,480 --> 00:06:38,160
aufbauen muss. 
N Headshack machen muss. 

120
00:06:38,160 --> 00:06:40,880
Du hast es gerade schon gesagt, 
habe es große Dokumente, also 

121
00:06:40,880 --> 00:06:43,680
einfach im JSON Format hin und 
her, schicke die ja 

122
00:06:43,760 --> 00:06:48,880
menschenlesbar sind, aber ich 
will ja vielleicht irgendwie in 

123
00:06:48,880 --> 00:06:53,320
der Lage sein sehr sehr schnell 
komprimierte Daten hin und her 

124
00:06:53,440 --> 00:06:55,880
zu schicken, jedes Mal dieses 
Netzwerk aufzubauen und dafür 

125
00:06:55,880 --> 00:06:59,760
ist dann eben. 
Gapc optimiert worden und da 

126
00:06:59,760 --> 00:07:01,360
sieht man es auch heute am 
meisten. 

127
00:07:01,360 --> 00:07:03,240
Also wenn ich es in Projekten 
sehe und ich habe es auch schon 

128
00:07:03,240 --> 00:07:05,720
einmal selber eingebaut, aber es
gibt auch viele so Tools wie 

129
00:07:05,720 --> 00:07:07,840
Depper dies verwenden, dann 
sieht man es vor allem so oft 

130
00:07:07,840 --> 00:07:10,880
der letzten Meile von irgendwie 
einer Ende zu Ende, Architektur 

131
00:07:10,880 --> 00:07:14,040
also oft schon innerhalb, also 
innerhalb des Rechenzentrums 

132
00:07:14,040 --> 00:07:17,920
oder eben innerhalb des 
Clusters, wenn 2 Microservices 

133
00:07:17,920 --> 00:07:20,400
zwischen Servern sehr effizient 
und sehr schnell miteinander 

134
00:07:20,720 --> 00:07:23,440
kommunizieren müssen. 
Aber tatsächlich kann ich die 

135
00:07:23,440 --> 00:07:26,680
Applikation ja auch verteilen 
über verschiedene Rechenzentren,

136
00:07:26,680 --> 00:07:28,640
die. 
Hinweg und kann trotzdem genauso

137
00:07:28,880 --> 00:07:33,360
diese, diese Kommunikations, 
diesen Kommunikationsweg 

138
00:07:33,360 --> 00:07:35,360
verwenden. 
Ich kann es aber theoretisch 

139
00:07:35,360 --> 00:07:39,080
auch verwenden, wenn ich mobile 
Apps baue, um dann zwischen 

140
00:07:39,080 --> 00:07:42,560
meiner mobile App und meinem 
Backend zu kommunizieren. 

141
00:07:42,800 --> 00:07:46,080
Teilweise funktioniert es auch 
auf anderen Geräten, die ich 

142
00:07:46,080 --> 00:07:49,920
anbinden möchte, aber es ist 
durchaus mehr als eine 

143
00:07:49,920 --> 00:07:55,120
Technologie, die nur in diesem. 
Microservice Cosmos stattfindet,

144
00:07:55,120 --> 00:07:58,640
wo ich Service to Service 
Kommunikation implementieren 

145
00:07:58,640 --> 00:08:01,040
möchte, sondern ich kann es 
tatsächlich auch darüber hinaus 

146
00:08:01,200 --> 00:08:04,960
verwenden. 
Technisch ja, man sieht es aber 

147
00:08:04,960 --> 00:08:08,000
fast nie. 
Also man muss dazu sagen, dass 

148
00:08:08,000 --> 00:08:11,200
es vor allem im Webbrowser und 
so auf mobile Apps nur bedingt 

149
00:08:11,200 --> 00:08:13,480
funktioniert. 
GAPC unterstützt auch Streaming,

150
00:08:13,480 --> 00:08:15,600
das gibt zum Beispiel im Browser
nicht. 

151
00:08:16,200 --> 00:08:20,400
Man muss auch dazu sagen, dass 
GRPC auf HTTP 2 aufsetzt, also 

152
00:08:20,400 --> 00:08:22,800
alles andere, was irgendwie 
sonst noch HTTP 1.1 spricht. 

153
00:08:22,800 --> 00:08:25,120
Was glaub ich immer noch, die 
der Großteil des Webs ist. 

154
00:08:25,600 --> 00:08:28,960
Kann mit GAPC dann erstmal 
nichts anfangen und diese ganzen

155
00:08:28,960 --> 00:08:32,640
so Edge Geräte, Endgeräte, 
Clients, die können es 

156
00:08:32,640 --> 00:08:37,559
theoretisch, aber dann sind aber
oft nicht nativ sondern sind oft

157
00:08:37,559 --> 00:08:39,679
irgendwelche Libraries noch 
notwendig die die so n bisschen 

158
00:08:39,679 --> 00:08:41,799
faken oder die irgendwas 
umwandeln also man. 

159
00:08:41,799 --> 00:08:43,960
Man sieht es doch 
klassischerweise eigentlich fast

160
00:08:43,960 --> 00:08:48,960
immer nur, also zwischen 
Services irgendwo im Backend. 

161
00:08:49,040 --> 00:08:52,240
Das Schöne ist, ich kann es in 
fast jeder Programmiersprache 

162
00:08:52,240 --> 00:08:55,040
verwenden. 
Dort gibt es einzelne Community 

163
00:08:55,040 --> 00:08:59,720
Projekte, die dann im Rahmen 
dieses gapc Projektes die 

164
00:08:59,720 --> 00:09:02,640
einzelnen Implementierungen für 
die verschiedenen. 

165
00:09:03,160 --> 00:09:06,640
Programmiersprachen ownen egal 
ob ich jetzt irgendwie in C plus

166
00:09:06,640 --> 00:09:09,760
plus, in Go oder in C, Sharp 
oder in anderen unterwegs bin, 

167
00:09:09,840 --> 00:09:14,240
gibt es da grpc Implementierung 
und ich kann dementsprechend, 

168
00:09:14,320 --> 00:09:17,680
egal mit welcher Technologie, 
immer auf die gleiche Art und 

169
00:09:17,680 --> 00:09:20,800
Weise arbeiten. 
Das heißt, ich habe eine Art von

170
00:09:20,960 --> 00:09:25,760
Client, die Methoden auf einem 
entfernten Server aufrufen kann,

171
00:09:25,920 --> 00:09:30,000
so ähnlich wie ich lokale 
Methoden aufrufe und diese. 

172
00:09:30,320 --> 00:09:32,240
Entfernten Methoden. 
Die werden natürlich 

173
00:09:32,240 --> 00:09:35,120
entsprechend beschrieben, sodass
ich auf der kleinen Seite auch 

174
00:09:35,120 --> 00:09:39,120
weiß, mit welchen Methoden ich 
dort interagieren kann. 

175
00:09:39,120 --> 00:09:43,760
Und ich kann dann als Developer 
tatsächlich ganz traditionell 

176
00:09:43,760 --> 00:09:47,440
arbeiten, wie mit den Methoden 
meiner lokalen Klassen, und 

177
00:09:47,440 --> 00:09:50,320
diese werden dann über das 
Netzwerk ausgeführt, das heißt, 

178
00:09:50,320 --> 00:09:54,240
im Hintergrund werden über diese
entsprechenden Bibliotheken von 

179
00:09:54,280 --> 00:09:57,520
Grpc, die ich habe, meine Daten 
entsprechend. 

180
00:09:58,800 --> 00:10:00,560
Komprimiert. 
Wir gehen gleich noch mal auf 

181
00:10:00,560 --> 00:10:04,160
den auf die Details ein, wie das
Ganze im Hintergrund läuft und 

182
00:10:04,160 --> 00:10:06,960
dann entsprechend über das 
Netzwerk übertragen und dann 

183
00:10:06,960 --> 00:10:09,960
auch die Antworten zurück 
übertragen, die ich dann in 

184
00:10:09,960 --> 00:10:12,440
meiner Applikation verwenden 
kann. 

185
00:10:12,440 --> 00:10:13,560
Genau. 
Jetzt hattest du ja eigentlich 

186
00:10:13,560 --> 00:10:15,280
gerade schon was Spannendes 
angesprochen, nämlich so ein 

187
00:10:15,280 --> 00:10:16,960
bisschen, wie es die Developer 
Experience, die ist nämlich 

188
00:10:16,960 --> 00:10:20,160
eigentlich sehr, sehr gut bei 
Grpcr, weil wie gesagt, es gibt 

189
00:10:20,160 --> 00:10:21,960
eigentlich für jede 
Programmiersprache irgendwie 

190
00:10:21,960 --> 00:10:24,960
eine Implementierung, was aber 
spannend ist, ist, dass ich 

191
00:10:24,960 --> 00:10:28,400
Server und Frontend, also 
Backend und Frontend eigentlich.

192
00:10:29,200 --> 00:10:32,880
Etwas teilen nämlich diese 
sogenannte Proto Datei, das ist 

193
00:10:32,880 --> 00:10:37,640
eigentlich der ja häufig so der,
der der Start einer grpc 

194
00:10:37,640 --> 00:10:41,360
Implementierung und auch so ein 
bisschen die Single Source of 

195
00:10:41,360 --> 00:10:44,000
Truth und damit fängt alles an. 
Es ist tatsächlich eine Datei 

196
00:10:44,000 --> 00:10:47,440
mit der mit der Dateiendung 
Punkt Proto, die muss manuell 

197
00:10:47,440 --> 00:10:50,880
erstellt werden von den 
Developern und die definiert, 

198
00:10:50,880 --> 00:10:54,440
die definiert eigentlich alles 
Services die es gibt und alle 

199
00:10:54,440 --> 00:10:56,880
Methoden die man in diesen 
Services aufrufen kann. 

200
00:10:57,280 --> 00:11:00,200
Und dann auch Nachrichten, also 
diese GAPC Welt ist alles ne, 

201
00:11:00,200 --> 00:11:02,560
was vielleicht bei bei bei Rest 
irgendwie n json Dokument das so

202
00:11:02,560 --> 00:11:05,280
hin und her schickt sind 
Nachrichten aber auch dann da 

203
00:11:05,280 --> 00:11:09,440
die Feldtypen und Nummern und 
alles was es irgendwie darin 

204
00:11:09,440 --> 00:11:11,840
gibt werden halt einmalig in 
dieser Datei beschrieben, das 

205
00:11:11,840 --> 00:11:14,280
heißt in der Datei wird 
beschrieben was sind denn diese 

206
00:11:14,280 --> 00:11:19,040
Remote Procedure Calls die ich 
auf einem GAPC Server aufrufen 

207
00:11:19,040 --> 00:11:20,560
kann und das wird einmal manuell
gemacht. 

208
00:11:20,560 --> 00:11:22,800
Das ist aber auch sehr, das 
sieht sehr sehr lesbar aus, das 

209
00:11:22,800 --> 00:11:25,640
sieht ein bisschen wieso ne 
kleine eigene Programmiersprache

210
00:11:25,640 --> 00:11:28,440
aus, aber. 
Ist genau also jeder, der schon 

211
00:11:28,440 --> 00:11:30,160
mal irgendwie programmiert hat, 
wird sich da relativ schnell 

212
00:11:30,160 --> 00:11:33,240
drin zurechtfinden und diese 
Prototatei, die wird irgendwo 

213
00:11:33,240 --> 00:11:38,160
zentral bereitgestellt und auf 
Basis dieser Prototatei kann der

214
00:11:38,160 --> 00:11:41,240
Client hingehen und sich 
eigentlich sowas wie ja man 

215
00:11:41,240 --> 00:11:43,160
nennt das auf den 
Programmiersprachen irgendwie 

216
00:11:43,160 --> 00:11:47,560
ein ein Stab oder in manchen 
Promi auch ein API Client, den 

217
00:11:47,560 --> 00:11:49,000
kann man sich dann eben daraus 
generieren. 

218
00:11:49,000 --> 00:11:50,960
Das heißt ich habe dann 
irgendwas, das liest diese Punkt

219
00:11:50,960 --> 00:11:53,920
prototatei ein. 
Und weiß und stellt mir dann 

220
00:11:53,920 --> 00:11:57,200
diese Methoden eben bereit. 
Und genauso kann der Server 

221
00:11:57,200 --> 00:12:00,240
hingehen und diese putto Datei 
nehmen und einlesen und 

222
00:12:00,240 --> 00:12:04,640
daraufhin die Methoden 
implementieren, die da definiert

223
00:12:04,640 --> 00:12:06,080
werden. 
Das heißt ich hab das ist wie 

224
00:12:06,080 --> 00:12:08,400
sowieso ein Contract zwischen 
meinen Clients und den Servern, 

225
00:12:08,400 --> 00:12:11,200
ich weiß alles was es in dieser 
Datei gibt, das kann ich ja 

226
00:12:11,200 --> 00:12:13,080
wirklich verwenden und das nimmt
auch wirklich genau diese 

227
00:12:13,080 --> 00:12:15,800
Datentypen entgegen. 
Und erstelle mir dann für meine 

228
00:12:15,800 --> 00:12:17,880
Programmiersprache den Client 
und für die Programmiersprache 

229
00:12:17,880 --> 00:12:20,200
meinem Server irgendwie sowas 
wie sowieso n Interface. 

230
00:12:20,200 --> 00:12:21,440
Was ich dann implementieren 
muss. 

231
00:12:21,440 --> 00:12:23,320
Irgendwie so abstrakte Klasse 
oder irgendwas was ich halt 

232
00:12:23,320 --> 00:12:25,520
dadurch implementieren muss. 
Also es heißt ja in jeder 

233
00:12:25,520 --> 00:12:28,000
Programmiersprache so n bisschen
anders und so teilen die sich 

234
00:12:28,000 --> 00:12:30,600
eigentlich diese Single Source 
of Truth, diese API Definition 

235
00:12:30,600 --> 00:12:33,840
und das ist auch so n bisschen 
das was was GAPC so magisch 

236
00:12:33,840 --> 00:12:37,280
macht, weil das dadurch ganz 
ganz stark typisiert, was 

237
00:12:37,280 --> 00:12:39,840
eigentlich ja nicht typisiert 
ist, nämlich so netzwerktraffic 

238
00:12:40,160 --> 00:12:41,920
und ich kann dann gar nicht 
irgendwie. 

239
00:12:42,240 --> 00:12:44,960
In JSON falsch formatiert dahin 
schicken oder groß und 

240
00:12:44,960 --> 00:12:47,680
Kleinschreibung verwechseln oder
irgendwie in diesem json 

241
00:12:47,680 --> 00:12:51,680
irgendwie eine Tippfehler drin 
haben oder eine Datei anders 

242
00:12:51,680 --> 00:12:53,720
schreiben, weil die ich eben 
diesen Vertrag, diesen Punkt 

243
00:12:53,720 --> 00:12:56,800
Toto file einmal habe, an den 
sich sowohl der Client, also der

244
00:12:56,800 --> 00:12:58,800
Server halten. 
Die Idee ist so ein bisschen 

245
00:12:58,800 --> 00:13:03,360
ähnlich zu diesen. 
Web Service Definition, wie ich 

246
00:13:03,360 --> 00:13:06,240
Sie vielleicht von Open API 
kenne, wo ich mir dann auch 

247
00:13:06,480 --> 00:13:10,160
vielleicht einen Client 
generieren kann aus einer Open 

248
00:13:10,320 --> 00:13:15,680
Open API Definition und das ist 
ein bisschen die Idee, dass ich 

249
00:13:15,680 --> 00:13:18,640
durch diesen Stab, den ich ja 
lokal dann auf meiner auf der 

250
00:13:18,640 --> 00:13:23,160
Client Seite habe, dann wie mit 
einer lokalen Klasse oder 

251
00:13:23,160 --> 00:13:26,640
lokalen Methoden interagieren 
kann und der ganze 

252
00:13:26,960 --> 00:13:30,640
Netzwerktraffic, dass ich dort 
eine entfernte Funktion aufrufe,

253
00:13:30,640 --> 00:13:33,680
auf einem anderen Seite. 
System wird dementsprechend für 

254
00:13:33,680 --> 00:13:38,080
mich weg abstrahiert, aber das 
ist tatsächlich in Grpc der 

255
00:13:38,080 --> 00:13:42,720
Standardfall und bei Rest bauen 
wir tatsächlich unsere Queries 

256
00:13:42,720 --> 00:13:45,240
häufig entweder selber zusammen 
oder wir haben irgendwie eine 

257
00:13:45,240 --> 00:13:49,040
Client Library, die wir 
runterladen und der Fall, dass 

258
00:13:49,040 --> 00:13:53,680
man sich standardisiert solche 
Clients generiert auf einer 

259
00:13:53,680 --> 00:13:58,320
Definition ist ja nichts, was 
per se in der. 

260
00:13:59,240 --> 00:14:01,680
In einer bestimmten 
Spezifikation für die Nutzung 

261
00:14:01,680 --> 00:14:03,600
von West Schnittstellen 
vorgesehen ist. 

262
00:14:03,920 --> 00:14:04,800
Genau. 
Und ich muss mir dann ja auch 

263
00:14:04,800 --> 00:14:07,240
selber diesen diesen Stop oder 
diesen API Client generieren und

264
00:14:07,240 --> 00:14:09,200
es sagt ja auch keiner 
garantiert mir auch keiner, dass

265
00:14:09,200 --> 00:14:11,840
der Server dann wirklich das 
alles auch so implementiert hat.

266
00:14:12,320 --> 00:14:15,040
Also es ist halt irgendwie ja, 
es ist eine sehr starke 

267
00:14:15,040 --> 00:14:18,680
Typisierung und es ist mehr als 
nur das, also das ist erstmal 

268
00:14:18,680 --> 00:14:21,480
die Art und Weise wie ich als 
Developer damit arbeite, der 

269
00:14:21,480 --> 00:14:23,520
Grund warum ich als developer 
damit arbeite ist aber 

270
00:14:23,520 --> 00:14:25,640
wahrscheinlich weniger, dass es 
diesen Contract gibt, das ist 

271
00:14:25,640 --> 00:14:30,640
eher was Angenehmes. 
Sondern eben, weil Gapc ja auf 

272
00:14:30,640 --> 00:14:32,920
auf einer technischen 
Perspektive besonders ist. 

273
00:14:32,920 --> 00:14:35,600
Und die hat eben schon gesagt, 
es baut auf HTP 2 auf. 

274
00:14:35,600 --> 00:14:39,640
Das heißt es, es unterstützt 
sogenanntes Multiplexing, was 

275
00:14:39,640 --> 00:14:41,640
vor allem bedeutet, dass ich 
weniger TCP Verbindungen 

276
00:14:41,640 --> 00:14:43,040
brauche. 
Es ist auch ein binäres 

277
00:14:43,040 --> 00:14:46,560
Protokoll, ist also deutlich 
kleiner, ich kann die ich kann 

278
00:14:46,560 --> 00:14:49,640
Kompression bei bei den Headern 
machen, aber auch bei dem Inhalt

279
00:14:49,640 --> 00:14:53,200
der Sachen die ich hin und her 
schicke, das heißt das ist schon

280
00:14:53,440 --> 00:14:55,840
deutlich. 
Klein und vor allem deutlich 

281
00:14:55,840 --> 00:14:57,520
schneller. 
Es hat n also ich Krieg vor 

282
00:14:57,520 --> 00:15:00,160
allem so in so Low latency 
Szenarien, wenn ich n höheren 

283
00:15:00,160 --> 00:15:03,040
Trueput brauche wenn ich 
irgendwas high Performance 

284
00:15:03,040 --> 00:15:05,920
optimieren möchte im auf der 
letzten Mail oder zwischen 

285
00:15:05,920 --> 00:15:09,600
Microservices, da bietet sie 
sich an, vor allem weil es auf 

286
00:15:09,600 --> 00:15:12,960
einem eigenen, ja eigenen 
Protokoll von in dem Fall auch 

287
00:15:12,960 --> 00:15:15,840
von Google aufbaut, das nennt 
sich Proto Buff und das ist 

288
00:15:15,840 --> 00:15:17,600
eigentlich n. 
Ja, n Binäres 

289
00:15:17,600 --> 00:15:21,480
Serialisierungsformat, also 
deutlich kleiner und deutlich 

290
00:15:21,480 --> 00:15:24,320
schneller als Jason. 
Und mit dieser starken 

291
00:15:24,320 --> 00:15:26,880
Typisierung, die wir eben schon 
angesprochen haben, also 

292
00:15:26,880 --> 00:15:29,560
unterstützt dann quasi einfach 
Int und float und und string und

293
00:15:29,560 --> 00:15:34,200
und sowas und wird dann quasi 
komplett ja komprimiert und 

294
00:15:34,200 --> 00:15:36,160
dadurch deutlich schneller durch
die Leitung gepresst. 

295
00:15:36,160 --> 00:15:39,680
Das heißt? 
Eben Default File nutze ich dort

296
00:15:39,680 --> 00:15:43,600
dieses Realisierungsformat. 
Die Dateien werden entsprechend 

297
00:15:43,600 --> 00:15:47,440
für mich Serialisiert in dieses 
Binärformat werden in diesem 

298
00:15:47,440 --> 00:15:50,880
übertragen, was natürlich 
bedeutet, wenn ich mir den. 

299
00:15:51,560 --> 00:15:54,680
Entsprechenden Traffic anschaue,
kann ich den als Mensch nicht 

300
00:15:54,680 --> 00:15:58,560
mehr lesen, weil keine json 
Dateien oder xml Dateien etc. 

301
00:15:58,560 --> 00:16:01,520
Übertragen werden, sondern es 
wird dieses Binärformat 

302
00:16:01,520 --> 00:16:04,800
übertragen. 
Aber du hattest gesagt, man kann

303
00:16:04,800 --> 00:16:09,160
auch von diesem Standard 
abweichen und JSON verwenden. 

304
00:16:09,160 --> 00:16:10,400
Hast du das selber schon mal 
gemacht? 

305
00:16:10,480 --> 00:16:12,640
Ja ne, gemacht habe ich es 
nicht, aber ich weiß man muss 

306
00:16:12,640 --> 00:16:15,040
keinen Proto Buff verwenden. 
Man kann einfach auch durch eine

307
00:16:15,040 --> 00:16:17,520
Konfiguration auf json 
umschalten, das hilft dann 

308
00:16:17,520 --> 00:16:19,840
zumindest so ein bisschen beim 
beim Debugging das. 

309
00:16:20,240 --> 00:16:22,640
Sieht man dann wahrscheinlich in
in Production nicht mehr, aber 

310
00:16:22,640 --> 00:16:24,520
der Standard ist eben dieses 
Protobof und du hast ja gerade 

311
00:16:24,520 --> 00:16:27,560
schon ganz richtig gesagt, einer
der größten Nachteile ist, dass 

312
00:16:27,560 --> 00:16:30,400
es eben nicht mehr 
menschenlesbar ist und deswegen 

313
00:16:30,400 --> 00:16:33,160
ja ist es auch nicht für alles 
geeignet und oft wenn man es 

314
00:16:33,160 --> 00:16:35,200
dann irgendwie, also man kann 
das dann doch irgendwie 

315
00:16:35,200 --> 00:16:37,680
natürlich wieder auslesen, aber 
dafür braucht es dann wieder 

316
00:16:37,680 --> 00:16:40,800
andere Tools, ist also nicht so 
ganz einfach. 

317
00:16:41,160 --> 00:16:44,040
GRPC kommt auch noch mit so 23 
anderen kleinen coolen Tools, 

318
00:16:44,040 --> 00:16:46,640
die schon eingebaut sind, also 
die die sehr schlauen Köpfe 

319
00:16:46,640 --> 00:16:48,480
dahinter haben sich auch so ein 
paar Gedanken gemacht, wofür 

320
00:16:48,480 --> 00:16:50,160
wird das denn eigentlich 
verwendet? 

321
00:16:50,720 --> 00:16:54,040
Also a es kann eigentlich alles 
was wir so aus dieser normalen 

322
00:16:54,040 --> 00:16:57,120
Restwelt kennen, also es das 
unterstützt wie gesagt ist auch 

323
00:16:57,360 --> 00:16:59,440
Streaming von Nachrichten, das 
brauche ich auch, vor allem oft 

324
00:16:59,440 --> 00:17:01,440
in so einem highperformance 
Szenario, unterstützt aber auch 

325
00:17:01,440 --> 00:17:04,880
TLS nativ 
authentifizierungstokens also 

326
00:17:04,880 --> 00:17:07,119
dieses ganze anmelden an einem 
anderen Server. 

327
00:17:07,640 --> 00:17:10,560
Hat aber auch schon so Konzepte 
wie Load Balancing mit drin. 

328
00:17:10,560 --> 00:17:13,280
Also zumindest so kleinseitig. 
Ich kann dann, wenn man ne auf 

329
00:17:13,280 --> 00:17:15,240
da steht man besteht man 
Microservices aus mehreren 

330
00:17:15,240 --> 00:17:17,839
Instanzen und die kann ich dann 
auch über GAPC miteinander 

331
00:17:17,839 --> 00:17:19,760
verbinden, sodass die 
untereinander mit sich ausmachen

332
00:17:19,760 --> 00:17:22,000
können, wer jetzt diese 
Nachricht, die reinkommt, gerade

333
00:17:22,000 --> 00:17:24,160
geradeaus führt. 
Also da sind schon so n paar 

334
00:17:24,160 --> 00:17:27,359
ganz coole Sachen für genau 
diese Microservices 

335
00:17:27,359 --> 00:17:30,760
Anwendungsfälle mit in das 
Protokoll eingebaut und die 

336
00:17:30,760 --> 00:17:33,880
machen dann tatsächlich auch ja 
die die Nutzung vielleicht von 

337
00:17:33,880 --> 00:17:36,480
so einem externen Globalancer 
zumindest für diese GAPC 

338
00:17:36,480 --> 00:17:38,480
Szenarien überflüssig oder 
einfacher. 

339
00:17:38,720 --> 00:17:41,040
Und das ist tatsächlich auch der
Grund, dass da einfach mehr 

340
00:17:41,040 --> 00:17:43,360
Logik gerade noch in dieses 
Netzwerkprotokoll mit 

341
00:17:43,360 --> 00:17:46,240
aufgenommen wird. 
Warum es auch so viele Fans um 

342
00:17:46,240 --> 00:17:48,040
GRPC gibt? 
Weil es eben mehr ist als nur 

343
00:17:48,040 --> 00:17:51,680
dieses Protokoll und nur diese 
super performante Geschichte, 

344
00:17:51,680 --> 00:17:54,440
sondern eben auch weil diese 
Convenience Tools drumherum hat,

345
00:17:54,440 --> 00:17:57,880
wie dieses Load Balancing, wie 
eben diese Punkt photodatei, wo 

346
00:17:57,880 --> 00:18:00,600
ich mich dann mit auf starke 
Typisierung verlassen kann und 

347
00:18:00,600 --> 00:18:01,920
so weiter. 
Wir haben jetzt ganz viel über 

348
00:18:01,920 --> 00:18:05,200
die Vorteile gesprochen und das 
ist ja für Developer sehr 

349
00:18:05,200 --> 00:18:07,320
komfortabel. 
Ist das Ganze einzusetzen, weil 

350
00:18:07,320 --> 00:18:09,200
es die entsprechenden 
Bibliotheken für alle möglichen 

351
00:18:09,200 --> 00:18:11,920
Sprachen gibt. 
Wir haben die großen Vorteile 

352
00:18:11,920 --> 00:18:14,600
rund um weniger Netzwerktraffic 
wirklich? 

353
00:18:14,680 --> 00:18:18,800
Können schneller kommunizieren 
zwischen den einzelnen Services.

354
00:18:18,800 --> 00:18:22,760
Und wir haben halt auch strenge 
Typisierung über die Definition 

355
00:18:22,760 --> 00:18:26,680
der einzelnen Services 
beziehungsweise Methoden, die 

356
00:18:26,680 --> 00:18:30,480
wir dort über die Protodatei 
dokumentieren. 

357
00:18:31,120 --> 00:18:35,240
Wann sollte ich denn jetzt grpc 
nicht einsetzen oder was sind 

358
00:18:35,240 --> 00:18:38,480
die Nachteile jenseits dessen, 
was wir gerade schon 

359
00:18:38,480 --> 00:18:41,480
angesprochen haben, dass wir 
halt den Netzwerk Traffic jetzt 

360
00:18:41,480 --> 00:18:44,160
nicht mehr. 
Menschen lesbar haben, sondern 

361
00:18:44,160 --> 00:18:49,240
in einem Binärformat. 
Was sind da weiter weitere 

362
00:18:49,240 --> 00:18:52,560
Punkte, wo ich jetzt weiterhin 
vielleicht auf Rest setzen 

363
00:18:52,560 --> 00:18:54,520
sollte? 
Ich würde sagen, so die neben 

364
00:18:54,520 --> 00:19:01,120
neben diesen typischen Schwächen
ist Rest einfach auch so offen 

365
00:19:01,120 --> 00:19:04,840
und so verbreitet und so jetzt 
mal einsteigerfreundlich, dass 

366
00:19:04,840 --> 00:19:07,360
ich würde sagen würde so alles 
was json und Rest passiert. 

367
00:19:07,360 --> 00:19:09,760
Es gewinnt eigentlich in allen 
Situationen wo. 

368
00:19:10,400 --> 00:19:12,400
Ja, Offenheit und Flexibilität 
vielleicht. 

369
00:19:12,400 --> 00:19:15,440
Wichtiger ist als Performance 
einfach. 

370
00:19:15,440 --> 00:19:19,120
Ich hab ne ne API die ich von 
der ich möchte, dass sie von 

371
00:19:19,120 --> 00:19:21,920
externen verwendet wird. 
Ne es ist GAPC natürlich 

372
00:19:21,920 --> 00:19:24,880
deutlich nischiger und also 
natürlich n bisschen höheren 

373
00:19:24,960 --> 00:19:28,640
Initialaufwand im Vergleich zu 
zu zu rests. 

374
00:19:28,640 --> 00:19:31,480
Also alles wenn ich irgendwie so
Sir Party Systeme anbinden 

375
00:19:31,480 --> 00:19:33,440
möchte, wenn ich selber 
vielleicht n Sir Party System 

376
00:19:33,440 --> 00:19:35,960
für andere. 
Bereitstelle, wenn es halt 

377
00:19:35,960 --> 00:19:38,000
irgendwie darum geht, dass ich 
vielleicht n Open Source Produkt

378
00:19:38,000 --> 00:19:40,520
baue oder ne. 
Also dann wenn ich sage wenn ich

379
00:19:40,520 --> 00:19:43,680
sage ich muss das hier nicht 
Performance optimieren, dann 

380
00:19:43,680 --> 00:19:46,240
glaube ich ist es Jason halt 
auch immer noch offener, 

381
00:19:46,240 --> 00:19:49,000
flexibler und lesbarer und ich 
würde auch gar nicht sagen, dass

382
00:19:49,000 --> 00:19:52,240
die RPC irgendwie jetzt n Rest 
Ersatz ist, sondern es ist eher 

383
00:19:52,240 --> 00:19:57,040
halt n spezialisiertes Tool was 
seinen bestimmten Einsatz Fälle 

384
00:19:57,040 --> 00:19:58,960
hat. 
Dann lass uns noch mal ein paar 

385
00:19:58,960 --> 00:20:03,440
Szenarien durchsprechen und 
schauen, welche Technologie dort

386
00:20:03,440 --> 00:20:08,240
vielleicht am besten geeignet 
ist und ob man Gapc in Erwägung 

387
00:20:08,240 --> 00:20:13,040
ziehen sollte, ja oder nein. 
Ein Thema, was wir am Anfang 

388
00:20:13,040 --> 00:20:16,760
schon angesprochen hatten und wo
Gapc natürlich auch so ein 

389
00:20:16,760 --> 00:20:20,640
bisschen herkommt, ist das Thema
Micro Services und. 

390
00:20:21,040 --> 00:20:24,640
Da kann man, glaube ich sagen, 
ganz klare Empfehlung, sich Grpc

391
00:20:24,640 --> 00:20:26,800
anzuschauen. 
Man hat die entsprechende 

392
00:20:26,800 --> 00:20:29,680
Performance, man kann auf 
Typsicherheit setzen und man 

393
00:20:29,680 --> 00:20:32,520
kann über verschiedene 
Technologien hinweg diese 

394
00:20:32,520 --> 00:20:37,880
Kommunikation aufbauen, 
sicherstellen und kann 

395
00:20:37,880 --> 00:20:41,520
dementsprechend sehr schnell und
sicher kommunizieren zwischen 

396
00:20:41,520 --> 00:20:43,920
den eigenen Diensten. 
Dann das Thema Streaming. 

397
00:20:43,920 --> 00:20:47,360
Echtzeit Kommunikation kann auch
Chats, Telemetriedaten würde ich

398
00:20:47,360 --> 00:20:50,240
auch sagen, ja ganz klar Duapc 
empfehlen. 

399
00:20:50,760 --> 00:20:52,800
Gerade für diese native 
Unterstützung, auch für 

400
00:20:52,800 --> 00:20:56,720
bidirektionale Kommunikation und
Streaming, also alles was 

401
00:20:56,720 --> 00:20:58,960
Echtzeit ist, kann man sich gpc 
auch mal anschauen. 

402
00:20:58,960 --> 00:21:01,360
Und innerhalb dieser beiden 
Szenarien, die wir gerade schon 

403
00:21:01,360 --> 00:21:03,360
besprochen haben, haben wir 
natürlich auch noch die 

404
00:21:03,360 --> 00:21:06,000
Variante, wo wir 
unterschiedliche Technologien 

405
00:21:06,000 --> 00:21:07,840
verwenden. 
Das heißt, wir haben vielleicht 

406
00:21:08,000 --> 00:21:10,880
auf der einen Seite haben wir 
irgendwie einen Java Service, 

407
00:21:10,880 --> 00:21:13,360
der kommuniziert mit einem 
anderen Service des in Go 

408
00:21:13,360 --> 00:21:16,400
geschrieben und wenn wir da 
natürlich einen einheitlichen 

409
00:21:16,400 --> 00:21:20,080
Standard haben mit einem 
gleichen Format zur Beschreibung

410
00:21:20,080 --> 00:21:22,320
der. 
Der entsprechenden Methoden ist 

411
00:21:22,320 --> 00:21:25,360
das ein großer Vorteil und 
dementsprechend gerade auch in 

412
00:21:25,360 --> 00:21:28,800
solchen Szenarien gapc eine 
Empfehlung wo? 

413
00:21:28,840 --> 00:21:30,560
Ich es nicht empfehlen würde. 
Ganz klar ist sowas wie 

414
00:21:30,560 --> 00:21:32,720
öffentliche AP is, das haben wir
eben schon gesagt, alles was 

415
00:21:32,720 --> 00:21:34,680
irgendwie der öffentliche ist 
oder vielleicht auch die 

416
00:21:34,680 --> 00:21:37,160
Kommunikation zwischen einem 
Backend und einem Browser ist 

417
00:21:37,160 --> 00:21:39,920
würde ich sagen nee, aber der 
Browser Support einfach sehr 

418
00:21:39,920 --> 00:21:42,720
begrenzt ist und b jeweils sehr 
schwer zu debuggen ist. 

419
00:21:43,040 --> 00:21:44,840
Von daher würde ich da 
wahrscheinlich kein Gapc 

420
00:21:44,840 --> 00:21:46,400
empfehlen. 
Vielleicht aber auch ganz 

421
00:21:46,400 --> 00:21:48,840
allgemein. 
Immer wenn man externe Systeme 

422
00:21:48,840 --> 00:21:52,400
anbindet. 
Ist es durchaus sinnvoll, einen 

423
00:21:52,480 --> 00:21:55,840
sehr interoperablen Standard wie
zum Beispiel JSON in der 

424
00:21:55,840 --> 00:22:00,440
Kommunikation zu verwenden und 
sich mit Grpc eher auf die 

425
00:22:00,440 --> 00:22:03,920
interne Kommunikation zwischen 
den einzelnen Komponenten der 

426
00:22:03,920 --> 00:22:05,520
eigenen Anwendung zu 
konzentrieren? 

427
00:22:05,600 --> 00:22:06,960
Genau. 
Wenn ich mir dann sowas angucke 

428
00:22:06,960 --> 00:22:08,720
wie Sachen so die theoretisch 
gehen. 

429
00:22:08,720 --> 00:22:11,880
Also ja, ich kann ja irgendwie 
schon auch von einer mobile App 

430
00:22:11,880 --> 00:22:14,000
mit einem Backend über Grpc 
kommunizieren, da gibt es 

431
00:22:14,000 --> 00:22:15,680
Libraries, die das so ein 
bisschen umwandeln. 

432
00:22:16,240 --> 00:22:18,080
Nicht auch ganz theoretisch gibt
es auch Sachen für im Web, die 

433
00:22:18,080 --> 00:22:19,920
das in dem Browser dann doch 
irgendwie wieder ermöglichen. 

434
00:22:19,920 --> 00:22:22,560
Aber nicht alle Features machen 
würde ich sagen. 

435
00:22:23,200 --> 00:22:26,160
Vielleicht also muss muss man 
sich glaube ich angucken, das 

436
00:22:26,160 --> 00:22:28,320
kann sehr effizient sein, also 
wenn man wirklich auf 

437
00:22:28,320 --> 00:22:31,440
Performance trimmen muss, weil 
man irgendwie Streaming braucht,

438
00:22:31,440 --> 00:22:33,760
dann dann dann vielleicht aber 
würde ich mir wirklich 

439
00:22:33,760 --> 00:22:35,600
überlegen, weil es halt eben 
noch mal noch mal ein ganz 

440
00:22:35,600 --> 00:22:38,320
anderes Setup und dieses Tooling
erfordert. 

441
00:22:38,840 --> 00:22:39,920
Da vielleicht so n bisschen die 
Empfehlung. 

442
00:22:39,920 --> 00:22:43,760
Es gibt n ganz cooles Tool, das 
heißt GRPC Gateway und das kann 

443
00:22:43,760 --> 00:22:46,480
man so n bisschen in sein API 
Gateway einbauen, das ist n Tool

444
00:22:46,480 --> 00:22:49,920
was eigentlich so ne Brücke 
zwischen Rest und GRPT spannend,

445
00:22:49,920 --> 00:22:52,840
das heißt das akzeptiert dann 
bis zum API Gateway hin die 

446
00:22:52,840 --> 00:22:56,840
normalen Rest Calls wandelt die 
dann aber in GRPC Aufrufe um und

447
00:22:56,840 --> 00:22:58,440
leitet das an GRPC Server 
weiter. 

448
00:22:58,440 --> 00:23:01,280
Ich weiß nicht ob das auch mit 
Streaming funktioniert, aber das

449
00:23:01,280 --> 00:23:03,640
ist auch so n bisschen so n so n
so n zwischentool ich finde das 

450
00:23:03,640 --> 00:23:05,680
ganz ganz cool, weil das auch 
unter anderem das Thema ist 

451
00:23:05,680 --> 00:23:08,000
warum ich jetzt wieder auf GRPC 
gestoßen wurde. 

452
00:23:08,800 --> 00:23:10,600
Das würden wir einfach mal mal 
verlinken, falls das irgendwie 

453
00:23:10,600 --> 00:23:12,160
spannend ist. 
Damit kann man so n bisschen so 

454
00:23:12,160 --> 00:23:14,920
ne Zwischenbrücke gehen, aber 
ich würd generell so n sagen 

455
00:23:15,440 --> 00:23:18,160
doch eher für Inter microservice
Kommunikation. 

456
00:23:18,160 --> 00:23:20,640
Ich glaub da glänzt es und alle 
anderen Sachen so. 

457
00:23:21,080 --> 00:23:23,280
Muss man sich eben anschauen. 
Zusammenfassend lässt sich 

458
00:23:23,280 --> 00:23:26,720
glaube ich sagen, dass Grpc 
nicht besser ist als eine 

459
00:23:26,720 --> 00:23:30,480
Kommunikation über Rest, sondern
es ist einfach eine andere Art 

460
00:23:30,480 --> 00:23:34,000
der Implementierung, die ganz 
eigene Trade Offs mit sich 

461
00:23:34,000 --> 00:23:36,160
bringt. 
Das heißt, ich habe eine ideale 

462
00:23:36,160 --> 00:23:39,520
Technologie für Performance, 
kritische Kommunikation, 

463
00:23:39,520 --> 00:23:42,560
vielleicht über verschiedene 
Technologien hinweg, 

464
00:23:42,720 --> 00:23:48,080
insbesondere mit einer Stärke im
Microservice, im Streaming etc. 

465
00:23:48,320 --> 00:23:50,840
Aber ich habe an auf. 
Auf der anderen Seite 

466
00:23:50,840 --> 00:23:54,640
Herausforderungen, wenn es darum
geht, wie debugge ich das ganze,

467
00:23:54,640 --> 00:23:59,840
wie offen ist das auch, wie 
Menschenlesbar dementsprechend 

468
00:24:00,000 --> 00:24:04,320
muss ich mich in jedem Fall 
weiterhin entscheiden, welche 

469
00:24:04,320 --> 00:24:07,080
Technologie ich einsetze und ich
glaube, wir hatten es gerade 

470
00:24:07,080 --> 00:24:11,760
gesagt für das Thema so Web, 
Frontend oder APIS die Party 

471
00:24:11,760 --> 00:24:15,120
Zugriffe erlauben, sollte man 
durchaus weiter Rest oder Graph 

472
00:24:15,120 --> 00:24:18,320
QL. 
Schnittstellen anbieten, da 

473
00:24:18,320 --> 00:24:22,000
diese einfach auch von Menschen 
einfacher genutzt werden können.

474
00:24:22,240 --> 00:24:23,480
Genau. 
Also ich würde sagen Gapc 

475
00:24:24,960 --> 00:24:28,160
zusammenfassend, es ist cool 
wegen dieser protodatei Contract

476
00:24:28,160 --> 00:24:32,480
First, super stark typisiert, 
sehr effizient und Rest ist halt

477
00:24:32,480 --> 00:24:36,160
dann die offene Alternative, 
viel flexibler, viel einfacher 

478
00:24:36,160 --> 00:24:37,520
zu debuggen. 
Also ich habe für mich so ein 

479
00:24:37,520 --> 00:24:40,080
bisschen diese Faustregel, 
interne Services oder 

480
00:24:40,080 --> 00:24:44,640
Performance ist wichtig gapc. 
Offene AP is Web oder 

481
00:24:44,640 --> 00:24:47,040
drittanbieterintegration dann 
halt Rest. 

482
00:24:47,040 --> 00:24:48,240
Oder wie du gerade sagst Graph 
Quell. 

483
00:24:48,240 --> 00:24:50,560
Was auch eigentlich ein super 
spannendes Thema ist, für das 

484
00:24:50,560 --> 00:24:52,760
wir aber will einfach mal eine 
eigene Folge machen. 

485
00:24:52,760 --> 00:24:55,120
Ich glaube Graph Quell hat man 
noch gar nicht irgendwie, aber 

486
00:24:55,120 --> 00:24:56,880
das ist so ein bisschen meine 
Faustregel und ich glaube damit 

487
00:24:56,880 --> 00:24:59,520
fährt man ganz gut. 
Wir hoffen, das Thema war für 

488
00:24:59,520 --> 00:25:02,240
euch genauso spannend wie für 
uns, da noch mal tiefer 

489
00:25:02,240 --> 00:25:05,360
einzusteigen. 
Und wie immer, wenn euch diese 

490
00:25:05,360 --> 00:25:08,720
Folge gefallen hat, lasst uns 
gerne eine positive Bewertung. 

491
00:25:09,120 --> 00:25:13,280
Da das könnt ihr machen auf 
Apple Podcast oder Spotify. 

492
00:25:13,360 --> 00:25:16,000
Und wie immer freuen wir uns 
natürlich auch sehr, wenn ihr 

493
00:25:16,000 --> 00:25:19,040
uns den einen oder anderen 
Kaffee ausgebt. 

494
00:25:19,200 --> 00:25:22,120
Das könnt ihr machen über die 
Webseite bei mir Coffee, den 

495
00:25:22,120 --> 00:25:23,600
Link findet ihr in den Show 
Notes. 

496
00:25:24,200 --> 00:25:26,400
Wenn ihr glaubt, dass ihr unser 
kleines Easter Egg gefunden 

497
00:25:26,400 --> 00:25:28,720
habt, also wenn ihr sagt, Hey, 
ich glaube, ich weiß, was in 

498
00:25:28,720 --> 00:25:32,880
dieser Folge anders war als bei 
vielen Folgen zuvor, dann 

499
00:25:32,880 --> 00:25:35,200
schreibt uns auch gerne eine E 
Mail und mal gucken, ob ihr es 

500
00:25:35,200 --> 00:25:36,240
findet. 
Da gibt es wie gesagt ein 

501
00:25:36,240 --> 00:25:38,360
kleines Ostergeschenk, schreibt 
uns einfach eine Mail, die 

502
00:25:38,360 --> 00:25:41,240
findet ihr auch unten in der 
Beschreibung von der Podcast 

503
00:25:41,240 --> 00:25:43,240
Folge und auch da findet ihr 
einen Link, wenn ihr uns quasi 

504
00:25:43,240 --> 00:25:45,760
einen Kaffee ausgeben wollt, da 
freuen wir uns immer sehr oder 

505
00:25:45,760 --> 00:25:48,000
wenn ihr zu eurem eigenen Kaffee
die passende Nerd Tasse haben 

506
00:25:48,000 --> 00:25:50,080
wollt, haben wir so einen 
kleinen Fanshop, schaut also 

507
00:25:50,080 --> 00:25:53,760
gerne vorbei und ansonsten. 
Bleibt uns nicht mehr viel zu 

508
00:25:53,760 --> 00:25:57,760
sagen, als habt eine gute Zeit. 
Hört auch in 2 Wochen wieder zu,

509
00:25:57,760 --> 00:26:01,440
denn der To do Developer Podcast
erscheint alle 2 Wochen und 

510
00:26:01,440 --> 00:26:04,160
schreibt ganz viel Code. 
Und natürlich kommuniziert 

511
00:26:04,160 --> 00:26:07,840
effizient. 
Wie mit Gfpc macht's gut.