Moin zu einfach komplex. Folge 84 hier aus dem Podcast
Studio in Hamburg am Freitagnachmittag hier spricht
Garrett Hallo, Hallo. Hallo Hallo, hier spricht
Burkhard aus dem Podcast Studio in Barmbek Süd.
Schön, dass ihr wieder alle da seid und entscheidet.
Ich glaube, wir haben Clown gefrühstückt heute morgen, aber
gut, egal es. Geht ja, wir haben Gute.
Dass Sie das Wort Wir haben gute Laune, ja, stimmt ja.
Wir haben gute Laune, wir hatten eine coole Woche.
Bookert war in Meppen auf der Hostmesse von Adelius haben wir
ja Magazisert im Podcast. Ich war in Barcelona auf der.it
Konferenz, da hab ich n bisschen Inspiration bekommen, sagen wir
es mal so für n neues Thema welches da ist.
Web Books, das habt ihr schon gelesen und warum Leute kamen
bei uns an stand wir hatten auch n kleinen Stand von der
Heisenware haben unsere loco Plattform vorgestellt, haben da
Dashboards zusammengebaut und so und das war auch alles ziemlich
cool hat gut geklappt und immer wieder kam die Frage habt ihr
auch n Web Book oder? Wie können wir Daten bei euch
reinbringen? Und natürlich haben wir da ne
Integration zu als also nen HTTP connector letzten Endes, aber
ich war doch blank muss ich zugeben wenn es drum ging Web
books richtig zu beantworten und da uns zu positionieren und ich
hab mich aber dran erinnert Burkhard, dass wir da mal drüber
gesprochen haben in der Rest Abi Folge ja da war das glaub ich n
ein Unterthema da sagst. Du.
Wo? In unseren, ja 83 Folgen war das
auf jeden Fall schon mal n. Thema ja, aber nicht viel mehr
als glaub ich n längerer Nebensatz oder Irgendsowas so
richtig so richtig drüber gesprochen haben wir wirklich
noch nicht glaub ich. OK, deshalb dachte ich heute
morgen, als es hieß, OK, was machen wir jetzt für n Thema
Dienstag steht mir wieder ne Folge an, lass uns doch mal über
Webbox sprechen und ich möchte es erfahren wie es funktioniert
und von daher hier sind wir jetzt und reden wir über Webbox
Burkhard. So machen wir das jetzt hast du
uns aber schwer geoutet, gerettet, dass wir gerade jetzt
die Folge erstmal für nächsten Dienstag, aber ist ja gut,
Justin Time ne, so läuft das Halt da keine 4 mal ein und
action ja. Ist so schwer.
Ja, wir sind doch noch, es sind doch noch 4 Tage bis Dienstag,
oder nicht? Stimmt, und wir haben ja noch n
ganz schönes Wochenende, aber da kann man ja auch mal was machen,
ne? Wir haben auch schon am
Montagabend ne Folge aufgenommen.
Das ist so. Ja, das ist so.
Ja, ja, na ja, ja, n paar in Zeit sich ja heute aus dem
Aufnahmestudio ne genau so, jetzt machen wir auch nicht mehr
so lange schnacken, jetzt gehen wir mal aufs Thema.
Ich, ich geb mal kleine Intro zu Web books und zwar bevor wir das
Web Programms anfangen müssen wir noch mal und ich hab es
schon so oft gesagt noch mal Server und klein verstehen ne
weil das gehört dazu und aber noch mal n bisschen anders
verstehen als Server und klein. Ich will es noch mal ganz ganz
ganz scharf aufdröseln wenn wir das wenn wir das nicht ganz
genau verstanden haben dann dann bleiben wir schwammig was Web
books sind. Ja also insofern gibt mir die
vielleicht siebeneinhalb Minuten die ich jetzt brauche um das
noch mal aufzudröseln bevor wir wirklich an an die Web books
rangehen, ja. Ja, total gerne, klar.
Es ist nämlich so. Also wir haben ja den Server und
den Client, ich fang einfach mal an mit dem Server.
Ja das Wort Server, das kennt ja jeder und jeder hat irgendwie ne
Vorstellung im Kopf, ja ich auch, aber es gibt ich glaube
ich, also ich verstehe so nen Server aus 2 Perspektiven ja das
will ich mal ganz klar machen, es gibt eine eine
netzwerktechnische softwaretechnische Perspektive
wenn man sagt irgendwas ist n Server ja was ist das dann
technisch? Dann ist das einfach ein
anrufentgegennehmer, sage ich mal.
Ja, also unser Internet besteht ja als Protokoll auf dem TCP
Stack, da liegt noch das HTTP drüber und so weiter das haben
wir alles schon durch, aber was ist ein Server?
Ist jemand der horcht auf einen Anruf?
Ja, es ist wie ein Telefon was man anrufen kann und dann
klingelt ja und man nennt halt auch also was der Server macht
ganz fundamental. Er macht ein sogenanntes
Listener Socket auf. Im TCP Stack?
Ja, das ist mal technisch gesprochen, was das jetzt ganz
genau heißt ist egal, aber es geht halt um die
Netzwerktechnologie. Ein Server ist ja auch
erreichbar im Internet und so weiter und der horcht quasi auf
einem bestimmten Port, der wird adressiert über eine IP Adresse
und kann quasi eingehende Connections entgegennehmen.
Ja so das ist die technische Sicht, das nennt man Server.
Und der Server ist tatsächlich immer der, der entgegennimmt.
Das ist immer der Angerufene. Ja, ist immer der andere.
Es ist also auch quasi die zweite, die zweite Person beim
Aufbau einer Verbindung. Ja, der Klient aus technischer
Sicht baut die Verbindung auf, der ruft an und der Server nimmt
entgegen. Ja, jetzt bleiben wir kurz beim
Server Klient machen wir gleich, ich will nochmal der Server
sagen jetzt gibt es man kann jetzt aber es gibt jetzt noch so
ne so ne Sicht so n bisschen so ne ich hab es jetzt mal
Infrastruktur Sicht oder Kasten Sicht oder Hardware Sicht oder
wie auch immer genannt. Wenn man so sagte, ja, das sind
die Server ja, oder? Amazon hat so Servers oder sowas
oder in der Cloud stehen die ganzen Server oder Irgendsowas,
dann meint man noch n bisschen was anderes glaube ich ja und es
ist auch gerechtfertigt, dann ist es das das Ding in der Cloud
ja und wenn man manchmal sieht man das ja so im Fernsehen dann
so so ne so n Teil der Tagesschau irgendwie da kommt
mal wieder irgendwas Hackerangriff und dann kommen
immer diese Bilder von diesen datencentern Gerrit wo das sind
die LEDS blinken und so weiter und so n Server tatsächlich als
Stück Hardware wenn man es mal so begreift da sieht das aus
wieso ne fette Pizzabox. Die in so riesigen Regalen
stehen. Ja, und vorne sind die Kabel
dran und und dann blinken die Dinger.
Ja, das ist auch richtig, ja, dazu kann man also, dazu sagt
man auch im normalen Sprachgebrauch, dass das ein
Server sei, ja und der hat aber auch so ne Eigenschaft, der ist
nämlich immer an und der hat immer Strom und der sollte nicht
ausfallen und so weiter weil sonst fällt da das Internet aus
und sofort und so weiter ja also ich meine damit dann.
Spezieller Computer oder nicht? Ja, im Prinzip ist das ein sehr
hochwertiger Computer, der dazu gebaut wurde. 24 7.
Durchzulaufen und halt diese Netzwerktechnisch, diese Anrufe
annehmen zu können, ja, ist nämlich blöd, wenn derjenige,
der die Anrufe annimmt und die Daten dann zurückschickt, nicht
da ist. Ob ich die nicht anrufen kann,
dann 404 Feierabend. Ja, da hab ich halt kein
Netzwerk, ja. Also würdest doch das jetzt
zusammenbringen. Ich hab jetzt wirklich gedacht,
das kann man tatsächlich trennen.
Ja, ja, also. Aber ich bringe das erstmal so
zusammen. Gleich kommt das aha Erlebnis
noch. Ja also also ich will einmal
sagen es gibt eine netzwerktechnische Sicht was ein
Server ist. Der netzwerktechnischen Sicht
nimmt der ja nen TCP Call entgegen und es gibt so ne Art
Hardwaresicht. Da ist es halt einfach ne Box.
Im Rechenzentrum steht normalerweise nicht bei dir im
Haus, sondern halt irgendwo bei bei Amazon irgendwie in so
großen Rechenzentren oder auch gibt es natürlich auch in
Deutschland hör ich da sagt das mal wir Hetzner zum Beispiel,
die haben in Nürnberg und in Falkenstein Standort, da stehen
die Halt alle ja. Aber auch dann noch mal n Ökonom
hat doch jede Firma, die n Rechenzentrum betreibt und das
sind ja die allermeisten oder n haben doch auch Server oder
nicht? Also es muss ja nicht zwingend
bei einem anderen Nein. Es muss nicht zwingend in der
Cloud stehen, das stimmt. Aber aber wenn du ne als Firma n
Rechenzentrum hast, dann dann kannst du.
Dann kannst du nur aus intern anrufen ne also ich mein jetzt
die internetserver sag ich mal. Ja du kannst ja jetzt nicht wenn
was weiß ich wenn irgendein Schuhladen der groß ist oder
Irgendsowas in der Stadt steht die hier eigenen Server haben um
ihre was weiß ich Sachen zu betreuen, da kannst du dann ja
nicht anrufen aus dem als vom Browser her oder irgendsowas.
Ja OK, aber grundsätzlich hat ja jede Firma auch Server im Keller
stehen oder irgendwo oder eine Produktion sogar.
Richtig, genau und. Und wenn du jetzt über die
Hardware sprichst, über den Kasten, dann ist das genau das
gleiche Bild. Ja genau dann ist das halt
irgendwie im Prinzip nichts anderes als n ziemlich potenter.
Computer, der dafür gemacht ist, 24 7 Durchzulaufen, um angerufen
zu werden. Ja so, das haben wir jetzt und
dann gibt es auch noch so eine dritte Eigenschaft, das habe ich
jetzt schon gesagt, die Lebenszeit, ja, also es ist die
Lebenszeit ist lang, ja, der Server ist gekommen um zu
bleiben und der ist immer erreichbar, damit ich anrufen
kann so, ja so, jetzt kommt das aha Erlebnis jetzt relativiere
ich was, das ist ja denn der der Kasten als Server, der kann auch
technisch gesehen also in der ersten Perspektive auch Client
sein. Ja, weil es ist ja n Computer.
Ja, und jetzt gehen wir kurz über.
Was ist denn noch mal n Client und dann sag ich das noch mal
und das ist glaub ich ganz klar ja, also der Client ist aus
netzwerktechnischer Sicht also wieder diese Netzwerkperspektive
zuerst ist der Anrufende ja der baut die initiale TCP Verbindung
auf, der wählt also quasi mit Hilfe von unserem DNS
Adressbuch. Ja das hat mir auch mal ne
Folge. Findet er quasi die richtige IP
Adresse raus. Die IP Adresse ist quasi die
Telefonnummer des Servers. Ja auf die der horcht ja und
dann wählt er raus und ruft den Server an und was heißt das
Anrufen er baut eine TCP eine Internet TCP Verbindung auf, der
Server antwortet ihm auf die Anfrage und dann hängt
normalerweise der Client einfach wieder den Löffel auf die Gabel
wie man so sagt am Telefon und Feierabend er hat angerufen hat
Informationen gehalten aufgelegt so ja das ist der Client aus
netzwerktechnischer Sicht ja Client ja.
Und aus Infrastruktur Sicht jetzt mal die zweite
Perspektive, kennen wir ihn, den Client, typischerweise in Form
von unserem Browser, zum Beispiel im Laptop?
Ja, das ist der Client ja, also und und und und da kann ich dann
natürlich mit ganz vielen Servern gleichzeitig sprechen.
Ja, ich mach n Tab auf, ich geh zu Google, ich mach n Tab auf,
ich geh zu Spotify und so weiter dann bin ich im Browser der
Client, ja und aus Infrastruktur Sicht könnte man sagen der
Browser ist halt quasi der Client.
Ja bisschen vereinfacht gesprochen oder die ganze App
ja. Ist n Client ja, weil die die
modernen Apps, die telefonieren ja heute auch alle mit Servern.
Ja, du kannst aber auch sagen irgendwie sogar ne commandline
Interface ja gibt es ja auch für die Leute die das machen so auf
der Commandline sind meistens auch Clients die dann mit einer
Server sprechen oder alles normalerweise auf dieser
modernen clientserver Architektur basiert ja und
Lebenszeit von einem Client ist kurz ja du du machst den Browser
aus, guckst schnell was Google Maps ja wie komme ich von A nach
b. Jo alles klar hab ich
verstanden. Browser aus tot ja, Client weg
ja, gibt es vielleicht auch nie wieder den mit der gleichen
Session ID oder irgend so was. Ja also der Client ist von der
Lebenszeit der kurze, der Anrufende, der will ne
Information haben und der Server der lebt lang ja so und jetzt
wenn wir jetzt Web books verstehen wollen müssen wir
müssen wir nicht nur 2 Komponenten betrachten wie wir
es sonst immer tun, Client und Server so also quasi in der
Entsprech von Browser und Webserver, sondern wir müssen
jetzt. 3 Spieler ins ins Game bringen, ansonsten fängt das
Macht das normalerweise keinen Sinn.
Ja also wir, wir denken uns jetzt mal ich das Bild hin, wir
denken uns jetzt Server, Server und Clients ja also wir haben
jetzt hier 2 Server ne das hab ich hab ja ganz viele Server
normalerweise gehört ja n Server zu irgendeiner Firma ja also wir
haben natürlich auch unsere Server zu heisenware ja und dann
ich nehme jetzt gleich schon mal das Beispiel vielleicht später
auch noch mal hoch nehmen Stripe ist ein Internet
bezahldienstleister. Wir haben auch ihre Servers.
Stripe ja, Mhm. OK, also es geht, dass ich um 2
Webserver jetzt im netzwerktechnischen Sinne und
irgendwelche Clients, was zum Beispiel Browser wären oder Apps
oder sowas. Genau diese 3 Parteien haben wir
und jetzt will ich mal. Jetzt kommen wir auf die Web
Books. Ja und die Web Books
funktionieren typischerweise zwischen Servern, also der der
der der Infrastruktur Client, also wir jetzt als Menschen, als
Form Browser oder an der App oder Irgendsowas wir haben mit
den Web books erstmal nichts zu tun, ne?
Wir sind weder die Auslöser noch die Empfänger der Webbooks,
sondern es sind 2 Server und jetzt und 2 Server im im im
Sprachsinne des der des Hardwarekastens.
Ja also stell dir vor du hast bei Stripe in der die haben
irgendwie ihren ihre Pizzabox ihren Kasten irgendwo hängender
Server und bei Eisenwer in Nürnberg bei Hetzner ist auch so
n Kasten wo unser Server ist. Ja wo unsere Programme drauf
laufen. So und jetzt jetzt muss zum
Beispiel aus bestimmten Use Case gründen auf die wir gleich noch
kommen der Stripe Server. Eine Nachricht schicken an
unseren heisenware Server, das heißt, da ist also im typischen
Web Sinne gar kein Client wirklich dazwischen.
Es unterhält sich quasi Cloud mit Cloud.
Ja, die Cloud Stripe mit dem Cloud Heisenware jetzt ist es
aber im netzwerktechnischen Sinne trotzdem so, dass wieder
eine Internetverbindung hergestellt wird, das heißt
obwohl der Stripe Server im Hardwaresprech ein Server ist,
wird der aber netzwerktechnisch gesehen auf einmal ein Client.
Und ruft bei unserem Server der Netzwerktechnisch wirklich n
Server ist, einen Web Hook auf der Web Hook ist nichts anderes
als ein Rest API Endpunkt der öffentlich da ist und angerufen
werden kann, aber der wird der Web hook wird typischerweise
eben nicht von einem Browser Klienten angerufen, sondern von
einem anderen Server der. In im der Wolfs im Schafpelz ist
also der quasi in diesem Moment, wenn er jemanden, wenn er einem
anderen Server Nachricht schicken will als Client
auftritt und zum Beispiel sagt, Oh, der Kunde, der bei
Heisenware jetzt gerade die Lizenz irgendwie abgeschlossen
hat, der hat gezahlt und das sag ich jetzt dem heisenware Server
per Bepuk ja so das einmal. Das ist so das Große, das große
Bild. Und ich kann gleich auch noch n
Beispiel machen. Aber du hast noch was auf der
Zunge gerillt was dann grad was? Ja, ich, ich wollt was fragen.
Du hast jetzt gesagt, OK webbook in Webbook ist eigentlich NN,
rest Endpunkt quasi so von einer Rest Appi der von einem Server
aufgerufen wird, aber werden also von einem Server der aber
als Client auftritt tritt in dem Fall werden jetzt nicht Rest
appis immer für Server zu Server also.
Kommunikation benutzt, die jetzt nicht über Menschen vor Browsern
passiert, sondern automatisiert irgendwo passieren.
Das ist das. Du hast gerade so gesagt, das
könnte man auch vom Browser an der Rest AP aufrufen, doch das
würde man vielleicht auch machen.
Klar wenn man sich Informationen in der App zieht oder sowas, ja
logisch OK. Also alle jetzt ist mal kurz n
kurzer Technical deepdives so aber also die modernen
Webanwendungen, die funktionieren ja als Single Page
Application, was heißt das, du bekommst deinen wenn du mit dem
Browser irgendwo hinklickst bekommst du deine.
Oberfläche deine UI geliefert als Bundle Java Script zum
Beispiel. Sagen wir mal, du nimmst jetzt
hier die Spotify für Laptop Oberfläche, sagen wir mal ja,
kannst du ja machen und dann kriegst du das alles schön
hingerendert und wenn du jetzt sagst Spiel mir ein Lied XY dann
führt quasi dein Browser UI unter dem Namen Gerrit Meyer
einen Rest API Client Call aus gegen den Server von Spotify.
Und so n typischer und die Rest APIS in minus Web Books sind
eigentlich immer so gedacht, dass du, dass der
internetbasierte Server Client Calls entgegennimmt, von von
einem Client, der quasi der kann auch programmatisch sein.
Das ist schon richtig, ja, aber typischerweise ist der quasi
jemand der der Halt n kommandozeilen dings ist.
Ne App ist ja oder halt ne runtergeladene Webseite oder
Irgendsowas, dafür ist das eigentlich klar.
Aha, OK, also das ist ja jetzt n natürlich dann.
Endlich mal so n aha, Moment für mich ja, also n webbook ist
wirklich für ne automatische Interaktion zwischen 2 Servern,
wo der eine aber ein Client ist quasi.
Und. Und nichts für mich als
menschlicher Benutzer an einem an einem Browser, ja.
Ja schön, wenn du das aha Erlebnis hast.
Ich mach das dann noch mal an einem alten Beispiel.
Klar, ich find immer so so so, Bilder und Geschichten sind
helfen mir auch das zu verstehen.
Ja ich also. Ihr kennt ja noch vielleicht und
du auch. Ja, diese diese Bilder von den
Telefondamen ganz früher, ja wo wo die ich?
Ich hab das immer so vorm Kopf, die rutschen da irgendwie so vor
so riesigen Schaltflächen Rum und stöpseln diese Kabel
zusammen ja, also früher ganz früh als die Telefonie erfunden
wurde hast du ja irgendwo angerufen an der zentrale
Telefonzentrale ja und dann dann war da ne nette Dame oder auch
ein netter Herr aber ich glaub es waren tatsächlich
hauptsächlich Damen früher, die haben dann gesagt ja mit wem
möchtest du sprechen und dann haben die irgendwie so Kabel
gestöpselt so ja. Wenn wir jetzt, da die Webbox
ins Spiel bringen, da könnten wir sagen, es gibt 2
Telefonzentralen, so alt, ja, nämlich die zentrale Heisenbär
mit unseren Frauen, 10 Frauen, ja, und die zentrale Stripe mit
5700 Frauen, weil die bisschen größer sind als wir, ja, die
sitzen da und machen die Steckerchen so weiter.
Ja, so, und jetzt gibt es einen Anrufer, der Anrufer ist jetzt
der, der Anrufer ist das analoge zu unserem Client, der vorm
Browser sitzt, ja, und das ist zum Beispiel, das ist n toller
Mensch und der will bei uns was bestellen, zum Beispiel
Heisenbär unser Produkt zum Beispiel ja mixe gerade alt und
alt und neu, so als analog, ja. So, dann wählt der Anrufer die
die Nummer für unsere zentrale Heisenwehrzentrale.
Da geht die nette Frau dran, sagt und und dann sagt der
Anrufer ja, ich will aber die tolle Heisenware Software haben.
Ja bitte ja so und dann dann macht was macht die
Heisenwehrzentrale die die leitet natürlich erst mal diesen
Anruf den Request weiter steckt die Kabel für unser eigenes
System datenbankeintrag der will das haben und so weiter ja was
für n was für n Tarif und so ja erst mal 30 Tage frei und so
kostenlos blablabla so und da jetzt kommt aber der Tag an den
der es zahlen soll ja und der ist da dann n Telefon.
Und jetzt sagt die jetzt sagt, die, sagt die Heisenware
Zentrale zum Anrufer hier, Pass auf, jetzt musst du mal bitte
bei Stripe anrufen und bezahlen, damit du hier dauerhaft unsere
App haben darfst. Ja und jetzt hält die zentrale
Heisenware die Verbindung mit dem Anrufer und das ist das
andere und jetzt kriegst du dann quasi eigentlich über unsere
Webseite heute modern bekommst du zum Beispiel so n Stripe
Interface, wo du dann ne Kreditkarte durchziehen kannst.
Weißt du Gerrit, aber das ist im Prinzip eigentlich nicht mehr
Heisenware, sondern. Dieses Pop up, auch wenn das
vielleicht bei uns irgendwie in den Prozess mit Einintegriert
ist, kommt in deinem Browser hoch und gehört technisch aber
eigentlich schon zur zentrale Stripe, während du noch mit der
zentrale Heisenware in Verbindung bist.
So ja so, das heißt, der Anrufer, der ruft jetzt bei
Stripe an und die bei Stripe sagen ja, ja, Zahl mal bitte und
zahlt und jetzt jetzt ist es wichtig, jetzt kommt der Webhook
ja, jetzt muss ja der Anrufer hat ja bei Stripe angerufen,
nicht mehr bei der Heisenware Zentrale, jetzt muss aber die
heisenware zentrale wissen, also wie er, dass der Kollege gezahlt
hat. Damit wir ihn freibuchen können
und er die Software benutzen darf.
Ja und was jetzt passiert und es passiert in echt auch ist das
Stripe Zentrale die Hotline die extra dafür gedacht ist und zwar
nur zwischen Stripe und Heisenware anruft und sagt hier
der nette Mensch der wird jetzt euer Kunde der hat gerade was
weiß ich 1€ bezahlt ja den könnt ihr frei machen ja und das Macht
das passiert indem Stripe die Nachricht pusht anruft quasi.
Tatsächlich bei heisen wir Zentrale und sagt ist bezahlt.
Ja dann sagt die nette Dame, die sieht da quasi die Lampe ist
bezahlt. Ja vielen Dank der Herr ja ist
bezahlt super wir schalten jetzt frei, hier ist ihr Account ja
fertig ja das ist das ist quasi das fundamentale Problem was
typischerweise über Webhooks gelöst wird.
Ja ich ich hoffe, dass dieses Bild hat das noch mal n bisschen
klarer gemacht und der Webhook in diesem ganzen Bild ist die
Kommunikation zwischen Stripe Zentrale und heisen wir.
Zentrale gleich Server, Server, Server, Kommunikation.
Ja, ja, OK, also bei uns ist wirklich jetzt in dem Beispiel
der Web Hook, der einfach nur dafür da ist um Bescheid gesagt
zu bekommen, da hat der wurde bezahlt.
Also bei Stripe ist die Aktion durchgelaufen, erfolgreich
durchgelaufen und und jetzt wird Bescheid gesagt, aber andersrum
ist es kein Web Hook oder wie wenn wir bei Stripe Bescheid
sagen, hier ist n jemand der neu bezahlen möchte.
Doch doch, also den du kannst Web Hook in beide Richtungen
aufbauen, ja, aber typischerweise typischerweise
weiß ja Stripe schon. Über das, über die, über das
Bezahldatum. Ja, also der Anrufer, der ruft
ja bei Stripe an und sagt, ich will bei der Heisen, wer das
denn das Buchen, dann wissen die eigentlich schon alles was sie
brauchen, ja es geht, es geht, technisch geht es natürlich in
beide Richtungen, ja, es ist je nachdem was man so braucht
könnte auch könnten wir auch bei Stripe anrufen oder Irgendsowas
ja genau gibt es alles. Ja cool, OK, das hab ich
verstanden. Dann aber wär ganz cool glaub
ich, wenn wir jetzt noch mal das andere Beispiel machen wo sie wo
sie wonach sie mich auf der Messe gefragt haben, weil die
haben ja folgendes vor, die haben ja.
In irgendeinem in irgendeiner Datenbank sag ich mal Daten, so
was weiß ich, die Sie von Sensoren gesammelt haben.
Also es sind zum Beispiel Firmen, die Sensoren irgendwo im
Feld verteilt haben und dort Zeitreihen letzten Endes
aufnehmen, vielleicht schon aggregieren und dann bei sich
speichern und haben die dann in irgendwelchen Servern oder auf
irgendwelchen Servern in Datenbanken liegen und die
wollen sie jetzt gerne visualisieren und dann haben die
gedacht auf der Messe Mensch, das geht ja ziemlich flott bei
Heiseware, weil ich denen das gezeigt habe.
Und dann haben die gefragt, habt ihr denn Webbook?
Was meinten die damit? Ja, die meinen damit.
Also wenn wir nen Webbook haben, dann meinen die damit, dass
unser Server und zwar der Server, der jetzt für den
bestimmten Account des Nutzers zuständig ist, in der Lage ist
über ne öffentlichen Endpunkt sowas wie ne publizierte Hotline
Nummer ja Daten zu empfangen von irgendjemandem der das senden
will. Ja und das heißt wenn wir nen
Webbook haben. Wollten das wir heute noch nicht
haben, tatsächlich, weil der ja pro Account erstellt werden
müsste, dann bräuchten wir einen auf dem Server, der dem Account
zugeordnet ist, dem heisenware Account die Möglichkeit eine URL
herzustellen, zum Beispiel https, doppelpunkt, doppelslash
my account Punkt, Heisenware, dot Cloud Webbook und diese
Adresse müsste man dann. Der Software, die die Datenbank
hat mitteilen Webbooks, müssen nämlich vorher kommuniziert
werden. Ja, beide Parteien sind
benötigt, ja, es heißt wir müssten sagen, das ist der
Webbook, den könnt ihr jetzt bei euch einsetzen in eure Plattform
und wenn jetzt zum Beispiel ein Datenupdate in der Datenbank
passiert ist, das ist ja ein Event, ja was wir nicht kennen
können erstmal ja, die haben jetzt zum Beispiel ein Bad
Import gemacht vom Telefonbuch was weiß ich und wollen jetzt
quasi. Das uns Rüberschicken, das ist
ja wichtig. Wir wollen ja die Daten haben,
dann machen die einen Post Request mit einem Client, der
die Daten rüberschickt aber dieser Post request, dieser
Client, das wird ja quasi bei denen auch in der
Serverarchitektur sein, denn die Datenbank liegt ja auch im
Serverbereich im Backender, also wird quasi deren Backend API
Server bei uns über den vorher kommunizierten Webbook.
Als Client auftreten und einen Post Request Post heißt
Schickdaten ja mit und dann sind da vielleicht dicke Daten
drinne. Ja als Jason formatiert,
typischerweise ist das so Rüberschicken unser Web Book
kriegt das checkt das das Mal sprechen wir gleich, das ist
nämlich n Security Thema, checkt dass das wirklich auch n legaler
Anruf ist von dieser Firma und dass die Nachrichten valide
sind, ja. Und sagt dann cool, das ist
nämlich ein Event, was wir kriegen, wir kriegen ja ein Post
Event, in dem Moment können wir darauf reagieren, da sind ja
auch Eventgetrieben und Daten getrieben und sagen klack, da
sind Daten da, wir updaten unsere UI, das Datagrid wird neu
angezeigt und hingerendert und fertig ist der Lack.
Ja, das ist was, die meinten ja. Verstanden, das ist also
sozusagen für die. Ne Möglichkeit also,
automatisiert in ihre Prozesse, die sie sowieso schon haben,
also durch durch die Software da in sie haben durch die
Datenbanken also Daten einfach an, zum Beispiel in dem Fall
jetzt das Frontend by, also ne heiseware App quasi zu liefern
und aktuell wäre es jetzt bisschen intern, aber wäre es
so, wir müssten quasi NN, Pull oder n Get request auf deren
Daten machen, was vielleicht nicht gewünscht ist oder nicht
geht oder was auch immer ne also so rum ist es eigentlich
eleganter, ja. Jetzt sprichst du mir noch mal
was aus der Seele herausgerillt es ist nämlich genau wichtig.
Also was ist nämlich der Web, der Web Hook, der das ist?
N schiebe ein Pusher, ja es erlaubt quasi Daten zu pushen,
wenn das Event beim Sender losgeht, der Sender in diesem
Fall ist halt die Firma mit ihren Datenbank, ja die wissen
ja jetzt hab ich ne Änderung, jetzt schieb ich das rüber, das
nennt man Push notification ja. Das ist quasi ne Server Server
Push notification. So kannst du es auch
aussprechen. Ja und du hast genau recht, wenn
das nicht hätten, sondern die haben nur ne API wo die quasi
abgefragt werden können. Wie sind denn die Daten, wie
sind denn die Daten dann müssten wir ne Kommunikation zwischen
denen aufbauen wo wir tatsächlich genau wie du es
gesagt hast als Client hingehen, die geben uns quasi die Adresse,
wo kannst du die aktuellen Daten nachlesen?
Wir wissen ja aber nicht wann die sich upgedatet haben.
Also bleibt nichts anderes übrig, als alle 5 Sekunden oder
irgend so was zu fragen. Gib mir mal die Daten, gib mir
mal die Daten, gib mir mal die Daten und wie beschissen Polling
ist im Internet, das haben wir ja schon n paar mal besprochen.
Ja das führt dazu, dass du keinen realtime hast, weil wenn
wenn ich gerade gefragt hab, gib mir mal die Daten, hab nichts
und direkt danach kommt kommen aber die Daten rein.
Dann hab ich quasi das Totfenster.
Das Polling Intervall ist halt quasi mein Totfenster.
Dann hab ich halt frühestens nach 5 Sekunden die Daten, was
jetzt schon fast Echtzeit ist. Ja aber also wir können ja aber
auch nicht, wenn wir ganz viele Leute haben, alle in 5 Sekunden
poll ja also ich meine irgendwann ist ja der ist ja das
das Netzwerkdicht ja und so sind webbooks halt schick, weil das
dreht quasi die die Kausalität um, also beziehungsweise das
Eventing um ja wir fragen nicht mehr, sondern die sagen uns wenn
sie was haben ja. Es ist in das es ist immer alles
das gleiche. In der Software gibt es sowas
auch, da heißt es dann halt callback ja du registrierst halt
n callback ja wenn wenn da was passiert, dann ruf ich halt
jemanden auf den ich vorher registriert hab ja ich.
Glaub dann brauchen wir das bald.
Ja, es ist auch nicht so schwer, das kriegen wir, das haben wir
bald ja o. K.
Ja, es gibt viele coole Dinge, die man haben könnte.
Ja, ja, ja, es ist vor allem halt also na jetzt dann dann
hören wir auf mit mit Heisenberg Krempel, aber.
Es ist ja vor allem dann also auf diese IOT Konferenz mal
natürlich viele Firmen, die IOT machen, ja, und die haben
natürlich schon viele große Mengen an an Daten ihrer Kunden
wiederum ja, wo die Sensoren einsetzen, dann letzten Endes in
Datenbanken, in der Cloud und da geht es dann einfach drum, die
dann schnell zu visualisieren, individuell zu visualisieren,
und da sind wir dann eben stark, oder das haben die dann eben so
empfunden, dass das mit uns ganz gut ginge, und da fehlt halt
noch der Webproof. Stimmt, hast du recht, irre, das
ist das ist auch n typisches Prozedere, aber ich sag noch mal
kurz was anderes MQTT deswegen gibt es zum Beispiel MQTT ja
weil weil also dieses diesen Bedarf was neues
Weiterzuschicken, das hast du ja immer, wenn Sensoren zum
Beispiel aus wenn Sensor was Neues gemessen hat, ja dann hat
er schon wieder n Event ja die werden halt auch nicht gepolt,
deswegen wurde überhaupt dieses ganze Internet of Things MQTT
Protokoll erfunden, weil das funktioniert Intrinsisch schon
mit schieben ja Push Push Subscribe und das haben wir
natürlich heute schon. Und somit lösen wir ja damit
auch schon sehr viele genau diese Cases quasi ab, dass der
der Web der Web hook ist, quasi der versucht das quasi zu zu
mimiken, also das das bringt quasi dieses Eventing in die
normale Web Rest API Welt mit rein ja und ist vom weil weil
das halt irgendwie registriert werden muss und so weiter und
sofort ist im Prinzip n bisschen altmodischerer, also kann man
schon haben, aber ich würde jetzt sagen wenn es gerade um
Sensorsachen geht und so weiter. Kann man auch einfach überlegen,
ob man das nicht vielleicht per OPCOA oder MQTT macht oder
irgend sowas. Deswegen gibt es die
Abprotokolle. Also absolut und hier und da war
das dann auch tatsächlich die Lösung.
Ja, wir können auch MQTT, ach ja, auch wunderbar, dann ist ja
alles geregelt schon, aber es geht jetzt ja nicht um den
Sensor zur heisenware Kommunikation, es geht ja, die
haben ja. Die ja diese, mit denen ich
gesprochen habe, die haben ja schon Clouds und und treiber hab
ich. Verstanden genau, und dafür ist
es richtig. Also von für Plattform zu
Plattform Kommunikation ja ja Cloud Service zu Cloud Service,
da ist das auch schon richtig und wird auch stand.
Wenn da auf der anderen Seite noch kein MQTT da ist, so dann.
Genau genau, hast schon recht, OK.
Gut, cool, dann verstanden, total verstanden was was
webbooks sind. Jetzt gibt es wahrscheinlich
noch n paar Details die wir da durchschnacken müssen, ne?
Ja, genau. Aber wir, wir werden es mal
nicht zu weit ausdehnen, aber ich wollte noch n paar
Eigenschaften nennen, die zu diesen Web books also einen
hatten wir ja schon, dass es, dass es quasi kein Polling ist
und quasi in Echtzeit agiert. Ja, das ist auch erstmal das
wichtigste, ja, die zweite hatten wir im Prinzip schon im
Vorbeigehen auch gesagt, also der Empfänger der Empfänger muss
sich beim Sender registrieren und dann erreichbar bleiben,
weil der Empfänger im netzwerktechnischen Sinn des
Server ist, muss er lange leben ja, also wenn ich einmal sage
ich, du kannst mich hier anrufen, ja, das ist meine
Hotline. Ja, dann sollte ich besser auch
da sein. Ja und und und und dann halt
quasi auch die Daten empfangen. Ja und wenn man jetzt so genau
drüber nachdenkt, dann dann ist das alles gar nicht so trivial,
weil diese jetzt kommt, nämlich das zweite Problem, dieser
Endpunkt den ich zur Verfügung stelle um Nachrichten zu
bekommen als Server, der muss natürlich öffentlich wieso n
Rest API Endpunkt im Internet stehen.
Ja und jetzt hab ich aber jetzt hab ich aber und und das ist n
Sicherheitsproblem ja. Weil stell dir mal vor, du hast
einfach nur einen öffentlichen Endpunkt im Internet stehen und
jemand kriegt den raus wie die URL ist und fängt an mit einem
kleinen Programm einfach im For Loop wie wild richtig fett Daten
da drauf zu schieben, 100 Hertz ja dann geht dann wir sind ja
Server an der Stelle, dann gehen wir voll in die Knie.
Ja das heißt wenn du den Webbook Etablierst hast du sofort alle
Probleme am an der Backe die du auch hast.
Wenn du normalen Webserver quasi aufstellst.
Ja du musst dich davor schützen. Dass dich jemand in die Knie
zwingt, einfach durch Kriminelle Anfragen.
Ja, du musst dich auch davor schützen, dass das, dass du
nicht gespooft wirst. Also jetzt, ich hab ja gerade am
Anfang gesagt, hier zahlungsbeispiel ja, du musst
der Hölle aufpassen, dass dir nicht irgendjemand was
unterjubelt und sagt, ja, hab ich gezahlt, ja, aber zum
Beispiel der Nutzer spart sich das ab irgendwo und es geht
vielleicht irgendwie was ganz anderes, ja, und um teure
Zahlung und so weiter und kennt irgendwie diesen Web Book und
sagt quasi selber sogar ne mit seinem mit seinem eigenen Ding,
tut so als ob ja hab ich schon gezahlt.
Du musst also authentifizieren. Ja, du musst die Integrität des
Senders verifizieren, ja, damit es halt auch weil du erwartest,
genau, also du hast als Empfänger ja auch genau den
Sender registriert, ja, du willst nicht von irgendjemand
irgendeinen Scheiß kriegen, ja, das, weil das hakst du in deiner
Datenbank ab hat bezahlt ja und hat vielleicht 3 Jahre lang n
Account, ja das sollte lieber auch stimmen.
Ja, insofern ist Sicherheit n riesiges Thema und ich geh da
nicht so ganz hart drauf ein, aber ich Tee da das mal kurz an
wie das ganz. Konzeptionell funktioniert ist
das, das macht man mit so genannt.
Ich weiß immer nicht, wie man es ausspricht, ich nenn es immer
Hedge Mac, Hedge Mac oder Irgendsowas ja, also es wird
auch ausgeschrieben HMAC ja und es heißt hedge based message
Authentication Code ja und und das ist im Prinzip so ne Art
symmetrische Verschlüsselung sagt man dazu, das heißt
derjenige der empfängt also jetzt noch mal an dem Beispiel,
dass wir zum Beispiel mit Stripe integrieren oder Irgendsowas,
der denkt sich quasi so ne Art Secret aus.
Langes Token wieso ne Art Passwort?
Ja, und das teilt er dem Sender mit, also demjenigen, der den
der und den Webbook von uns registriert, ja um uns
aufzurufen und und und mit diesem, mit diesem geheimen
Schlüssel werden quasi wird sofort die Nachricht
verschlüsselt, ja, und da kommt noch noch n timestamp rein,
typischerweise, damit ich weiß, wann die Nachricht gepackt wurde
und abgeschickt wurde, ja und ich?
Überprüfe typischerweise auch noch man man.
Man tauscht sich normalerweise auf die IP Adressen aus,
wenigstens die Range von den IP Adressen.
Ja weil Server werden ja identifiziert durch IP Adressen
ganz unten ja und dann dann kann ich zum Beispiel bin ich ja auch
schon n ganzes Stück sicher wenn ich weiß Tribe sendet sendet
seine Anfragen an unsere Webhooks typischerweise auf den
IP Adressen von Diss. Ja und wenn ich alles andere
schon mal ignoriere wenn irgendeine IP Adresse komisch ja
nehm ich gar nicht hin nehm ich gar schmeiß ich sofort weg ja
also. Das sind alles so also quasi so
Verschlüsselung, das Überprüfen von Zeitstempeln, weil das auch
wirklich gerade passiert, ne, weil ich weiß ja genau, ich weiß
ja genau, jetzt müsste da halt n Webbook kommen, weil weil
irgendeine Aktion passiert ist und so und auch die IP
adressenfilterung das sind alles so Dinge, die für die Sicherheit
sorgen. Ja und das muss ich wie immer
mit Sicherheit Zwiebelmäßig aufbauen, ne im besten Fall hab
ich das alles und die Wahrheit ist aber auch, dass wenn wenn
man heute Webbooks registriert und so weiter sind das schon
wieder. Gibt es schon wieder
Bibliotheken? So bei den großen Github, Stripe
und so weiter da kann man dann quasi in seinen Code ne Library
einbauen, die ist dann von Stripe und die lösen diese ganze
Sicherheit in sich selbst. Ja, das ist das Sicherste was
man dann da machen kann, ne? Ja, wenn das so n sehr
spezifischer webbook dann quasi ist, was es ja ganz
offensichtlich immer ist, oder ne ja, und der ist ja, der ist
ja, der ist ja zweckgebunden so so n webbook, da kann man.
Das gleich so machen, richtig. So und dann dann ist es noch n
paar Eigenschaften zu sagen, also Sicherheit die wird, das
wird meistens so abgehandelt, hatte ich gesagt, dann wird die
Datenübertragung ist sehr ähnlich, also man kann sich
wirklich vorstellen wie n Rest API Endpunkt, die Regeln gelten
dann auch und typisch modern ist halt quasi die die Dateninhalte
per json zu übertragen und derjenige der Server, der gibt
ja auch, das hatten wir auch schon mal in anderen Folge, du
musst als Server natürlich auch ne Nachricht zurückgeben dem
Sender in diesem Falle, dass du es empfangen hast.
Das machst du in denen du n 2 hunderter Code zurückschickst.
Je nachdem 2. Und es gibt 201 hab ich also es
gibt verschiedene Bedeutungen. In den 200 müssen wir jetzt
nicht durchkauen und was auch noch wichtig ist, du solltest
ziemlich schnell sagen, dass du es erreicht hast.
Ja und das ist n bisschen ne ne Komplexität, das muss man gut
kodieren sag ich mal. Wenn man eine einen Webbook
bekommt, also ein eine Nachricht bekommt mit Daten, dann sollte
man die asynchron weiter verhandeln und nicht vergessen
möglichst zeitnah dem Sender zu sagen Piep alles klar hab ich
gekriegt ja kannst weitermachen, ansonsten muss ja.
Musst dir ja vorstellen, das sind ja alles, das sind ja alles
viele Daten und viele ne groß vernetzt, ansonsten muss ja der
der Sender, also in dem Fall Stripe sehr lange warten bis die
ne und das noch vorhalten alles bis die wissen dass wir das OK
bekommen haben. Ja also die wollen ziemlich
schnell NOK bekommen haben. Ja und manchmal klappt es aber
auch nicht ne weil Internet ist ja das Internet, manchmal hast
du irgendwie ne Störung oder Irgendsowas und da musst du auch
drauf vorbereitet sein, dann wird irgendwie so n Ding halt
einfach noch mal geresendet ja das heißt dein Webbook.
Also derjenige, der den Webbook entgegennimmt, der quasi den die
Server Site übernimmt von dem Webbook, der muss den so
schreiben, dass der sogenannt Idempotent ist ja idempotent das
Wort hatten wir glaub ich auch schon mal bei den Rest APIS, das
heißt der muss dagegen sicher sein, dass dass, wenn der noch
mal aufgerufen wird, wenn der Sender einfach zweimal das
Gleiche schickt, da keine wilden Dinge passieren bei dir ja
typisches Beispiel hat gezahlt 1000€ ja.
Und, und das kam irgendwie nicht durch, oder der Sender hat
gedacht, es kommt nicht durch oder aus irgendeinem Grund, ja
kriegst du das das zweite Mal, musst zur Hölle aufpassen, dass
du nicht zweimal sagst, ja, der hat, der hat 1000 verbucht, ja
und dann hat er noch mal 1000 bezahlt hat er schon 2000
bezahlt bei deiner Datenbank, dabei war das die gleiche
Nachricht nur noch mal geschickt ja also das muss alles gut
geregelt sein so das sind so die das sind so die
Kerneigenschaften die ich beachten muss wenn ich quasi das
wirklich implementierenden webbroker das wollte er
eigentlich nur mal loswerden jetzt hab ich das Thema
abgefräst, ja. Diese Eigenschaften oder worauf
drauf wo drauf sagten ist quasi ja genau ne genau ja und wenn
wir wollen, dann können wir ja noch mal so n Paar als Beispiele
einfach noch mal irgendwie n bisschen auflisten, wo
typischerweise zum Beispiel Web Books eingesetzt werden und
warum hab ich n bisschen was mitgebracht, aber da sind wir
quasi schon inhaltlich sind wir, wenn du keine Fragen hast,
Gerrit und unsere Zuschauer keine Fragen mehr haben, aber
ich hör nichts, dann sind wir eigentlich durch, ja.
Hast du mal kurz reingelauscht? Hab ich schon mal Reingelauscht
ist relativ ruhig. Nee nee, alles gut.
Ja, ich bin eigentlich happy. Ich kann jetzt sagen, ja,
webbook können wir schon machen ja, also wenn ihr das wollt und
braucht, damit wir dann zusammenarbeiten können, dann
passt das. Ist doch gut.
Ja, ja. Dann machen n paar Beispiele
Digger. Ja genau, dann nehmen wir schon
mal n paar Beispiele. Ich hab jetzt so n Stripe, hab
ich gesagt, ist ganz klar der der Fall ja also man man hat
dann den Zahlungsdienstleister wie Stripe und dann kommen so
Webbooks zurück wie hat gezahlt hat storniert soweit da gibt es
verschiedene Eventtypen das ist ganz klar mach ich das ganze
Management mit, geht ab ist zum Beispiel.
Github Wer jetzt Github nicht kennt, der soll schnell
kennenlernen. Aber das ist ja quasi unser
Quellcode. Verwaltungsrepository im
Internet das größte und die haben sowas wie die haben tolle
neue Features, kann man alles Mögliche machen, aber die vor
allen Dingen machen die sowas wie ich Update in meinen Source
Code weil ich ne neue Version rausgebracht hab und jetzt
müssen zum Beispiel automatisiert irgendwelche Tests
und so weiter angetriggert werden also Thema CICD ja und
die CICDS die müssen die brauchen ja auch n startevent
sag ich mal. Das wird auch oft über Webbooks
realisiert, dann hat dann ist quasi.
Du hast quasi irgendwo deine CICD Pipeline, was auch
serverseitig läuft. Irgendwo hast du fette Dinger,
ja und die Entwickler Team ja die haben ein Release gemacht,
dann pushen die den Code auf den github Server ja Telefonzentrale
github ja und Telefonzentrale github hat aber registriert zu
Deiner Testingumgebung, dass ein anderer Server wieder sein kann,
kann auch ein anderer Anbieter sein ja mach das das und das und
das und das mit dem neuen Code ja nimm den Kopier den dann für
alle Tests durch so dann schick github quasi als Sender.
Ruft ein Webbook auf auf deiner CICD Serverimplementierung ja
nach dem Motto, Hier hast du neuen, hier ist neuer Code
hochgepusht worden, du musst das bitte noch mal alles testen.
Ja auch so n Klassiker Klassiker, Anwendungsfall ja
Tilio haben wir sogar selbst schon drin, da sind wir quasi,
tatsächlich haben wir sogar webbooks, aber nur für Tilio
Tilio ist ja so n Messaging Tool SMS Tool, da kannst du kannst du
auch Anrufe entgegennehmen programmatisch und so weiter.
Und Tilio hat quasi passt sogar richtig gut.
Das ist wirklich ne Telefonzentrale mehr oder
weniger. Du kannst also als da kannst du
wirklich mit dem Handy bei tilio anrufen und dieser Anruf und die
anderen Antworten, die können dann generiert werden, dann hast
du dann n Paket ja quasi kannst n Audio, Audio Spuren und so
weiter so n bisschen funktioniert das auch mit diesen
automatischen Telefonansagen die jeder hasst.
Ja, aber da rufst du bei Tilio an Tilio schickt n Webbook hier,
da hat jemand angerufen, der hat irgendwie gesagt 2 und dann wird
dann diese 2 wird dann weitergeleitet als Webbook.
Und dann, dann hast du ja deine spezifische Anwendung.
Was ist 2. Ja und dann wird da irgendwelche
Audiodatei abgespielt, irgendwas, das wird dann quasi
zurückgeschickt und so weiter dann geht das auf fort.
Also wir haben in dem Fall jetzt n Webbook um die Kommunikation
von Treeo entgegenzunehmen und ermöglichen es so unseren
Nutzern, Krempel mit SMS und Telefon zu machen.
Genau in Ihren Apps. Ja, und du hast jetzt gesagt,
Treeo schickt einen Webbook ist es.
Highlight schickt schickt ne Nachricht an den vorher
registrierten Webbook. OK, weil du hast es jetzt schon
ein 2. Mal so so gesagt.
Man schickt einen webbooker du meinst schon an den Webbook,
also man sagt tatsächlich man ruft den Webbook auf, man ruft
den auch Nachrichten ja genau das OK, ja genau alles klar und
es geht halt immer du musst, du brauchst halt diese 2 Prozesse
ne du brauchst ne Art kommissionierungsprozess dann
musst vorher musst du musst du mit twilio dich agreed haben ja
und und dieses ganze Schlüsselaustausch und so weiter
das muss richtig erstmal etabliert sein ja bevor das
irgendwie funktioniert ja und dann und wenn das aber erstmal
da ist wenn der Webbook registriert ist bei Twilio.
Und wir aufrufbar sind, dann funktioniert das in also in
Echtzeit quasi. Dann kommt da was rein und dann
schickt, das ist vielleicht das bessere Wort oder ruft auf,
Tilio uns auf dem vorher registrierten Webbook und wir
antworten oder tun, was wir machen wollen, ja, wir antworten
eigentlich nur mit OK, hab ich verstanden und und aber das das
kann also webtechnisch kann das kompliziert sein, da kannst du
ja dann wieder ne happy haben von Tilio und machen was machen
und so weiter und sofort, ja es ist im Prinzip ist es ist der
Webbook n Event Trigger ja mit einer Payload die Payload ist
halt im json ne. Mhm, ja genau, perfekt
verstanden und sonst? Ich mein es gibt es gibt ganz
viele Dinger, du kannst dich an also wenn man sich so in so
Plattform reinhängen kann mit seinen eigenen Tools so dann ist
das auch oft über Webbooks. Ja bei Slack kannst du das zum
Beispiel machen, ja kannst du das irgendwie in dein eigenes
Messaging System weitermachen? Shopify krasses example ja weil
du hast irgendwie rieseninterne Strukturen irgend so weiter und
bei Shopify hat jemand was bestellt und dann musst dann
passieren 1000 Sachen ja kriegst du kriegst du auch über Webbook
rein ja machen wir noch was anderes Discord Server Motion
die können das eigentlich alle ja seipia JIRA.
Und so weiter und sofort. Ja da, es gibt überall quasi
Dinge wo halt wo halt quasi anrufende mit einer Plattform
interagieren, wofür du als drittes aber trotzdem gerne ne
Information hättest, weil du dann irgendwie ne Reaktion drauf
folgen lassen möchtest. Ja, das.
Wollte ich jetzt gerade fragen. Tatsächlich wollte ich dich auf
Sapia, manche sagen Sapia ja, manche sagen Sapia ist auch
egal, aber SZAPIER darauf wollte ich die ansprechen.
Da bin ich aber auf dem Eis, das kann ich dir jetzt schon sagen.
Ich weiß nicht, ob ich das Antworten kann, aber was ist
los? Ne was die was die ja machen ist
es no codemäßig Webservices miteinander verbinden ne also in
deinem CRM klickst du irgendwas und dann passiert an anderer
Stelle weiß ich nicht wird es grün oder so in einem ganz
anderen Tool oder so ne oder beschissenes Beispiel ne aber ne
ne zahlung du kriegst ne Zahlung rein und dann.
Ist in in deinem Reporting Tool ist der Kunde aufspringt auf
gezahlt ja angenommen das sind 2 Tools und die sind nicht
miteinander direkt integriert, könntest du sie über Zipia
miteinander integrieren, wenn die beide ne AP anbieten so mehr
oder weniger haben die denn läuft das auch über Webbooks
wahrscheinlich ne ja weiß man nicht genau.
Keine Ahnung, könnte sein, ja, also was man dazu sagen kann,
Webbooks sind ja jetzt, also man muss, das hab ich jetzt immer so
gesagt, ne, du musst das irgendwie da vorher
kommissionieren und austauschen und so weiter das das kann man
natürlich als Mensch machen über über entsprechende Interface und
UIS. Du kannst das aber auch alles
programmatisch machen, ne, also der Komplexität und der der wie
soll ich sagen, der Freiheitsgrade ist da irgendwie
keine Einschränkung gegeben. Ne du kannst ja auch einfach
programmatisch n Webbook etablieren und auch wieder
wieder abbauen, ne und das machen wir zum Beispiel in
Chilio Case auch so, weil die die die Komplexität hört sich ja
wenn du mandantenfähig wirst oder mindestens Accounts hast,
dann wird ja quasi die URL deines anzurufenden Webbooks ja
jedes Mal quasi erst dynamisch. Ist die die, die kennst du ja
noch gar nicht am Anfang, ja, aber du kommst also bei unserer
Plattform läuft ja die ganze Zeit, dann kommt n neuer Nutzer
in unsere Plattform, der hat n neuen Account und nur in diesem
neuen Account, der ja ne neue URL quasi generiert URL darauf
will ich n Webbook haben. Ja das heißt ich muss den Kram
ganz schön dynamisch machen, dann muss ich quasi zur Laufzeit
von unserem Tool sagen to tilio pass mal auf, hier gibt es jetzt
jemand Neues übrigens das ist jetzt hier die die URL die es
ist registrier das da bitte mal hin.
Und du darfst ihn so lange anrufen, bis der Kunde zum
Beispiel, aber auch vielleicht wieder sagt, so, nö, ich meld
mich jetzt wieder ab. So mein Account gibt es nicht
mehr, dann solltest du ja aber auch den Kram wieder abbauen,
programmatisch und so weiter also im Detail ist das schon,
muss man das n bisschen managen sag ich mal ne weil du weil du
halt diesen Registrierungs und deregistrierungsschritt hast und
auch noch die ganze Sicherheit musst du noch dabei gleichzeitig
im Begriff haben, also deswegen ist es auch nicht ganz so
trivial, weil wir weil wir können zwar schnell n webbook
machen. Für die Heisenware das bringt ja
aber keinem was, du willst ja für deinen Account, also für
deine Miniwolke in der Heisen im Heisenware Space nen Webbook
haben und der wird ja erst dynamisch erzeugt so das Macht
die, das Macht die Sache schon so.
N bisschen soll ich sagen, bisschen anspruchsvoller beim
Programmieren, ne, deswegen haben wir es vielleicht heute
noch nicht, aber vielleicht übermorgen.
Ja ja versteh schon ne, das ist wieso oft ne wenn das natürlich
sehr eilig wird, dann wird es auch sehr wichtig oder wenn da
jemand ist und das unbedingt möchte.
OK, aber mir hat das zur Einordnung mal sehr geholfen.
Jetzt kann ich doch jemand mitreden, wenn jemand fragt, ich
bin dann doch immer lieber so, dann sag ich halt nee, keine
Ahnung was das bedeutet, ehrlich gesagt ja ich klär das ab und
jetzt haben wir es abgeklärt. Jetzt kann ich wieder auf die
Leute zurückgehen. Ja, es ist ja, also ich meine,
deswegen machen wir den Podcast ja der, der es gibt halt so viel
Krams, und das ist halt manchmal schwört der ja selber die rüber,
obwohl du es eigentlich weiß, musst du auch noch sagen,
Moment, Moment, Moment, ja, weil dann das das Passwort Bingo, das
geht ja immer schnell an bei solchen Gesprächen.
Und ich komm manchmal selber gar nicht mit, in welchen Tempo
manche Leute dann irgendwelche Wörter rausklatschen, weil ich
versuch, das immer wieder gleich zusammenzuschalten, komm ich gar
nicht hinterher. Ja, weil muss, man muss schon
kurz mal drüber nachdenken, wer ruft hier wen an und ist der
Server oder Server oder Client Server und was weiß ich alles.
Es gibt ja auch wirklich alles Mögliche an Architekturen, ja um
um halt im im Netz zu kommunizieren, ja und die
Webbooks sind im Prinzip, man kann sich so n bisschen, ich
fass es noch mal zusammen, das ist so ne Art Erweiterung der
Rest API und gedacht für. Server to Server Communication
ja in Echtzeit mit dem Push im im im im Mind ja, also ohne
Polling. Ja das passt jetzt glaube ich
ganz gut zusammen. Perfekt, cool.
OK, dann belassen wir es dabei heute mal ne Dreiviertelstunde.
Ist auch mal Gute. Folge ja richtig und ich sag
danke Burkhard, danke Euch fürs zuhören, wir hören uns in 2
Wochen wieder bei einfach komplex bis dahin tschau tschau.
So ist es. Tschüss aus Hamburg.
Einfach komplex wird präsentiert und produziert von Heise mehr.
Wir freuen uns auf deine Fragen und
deinfeedbackanpodcast@heisemehr.com vielen Dank fürs Hören dieser
Folge bis Dienstag in 2 Wochen und Tschüss aus Hamburg.