¶ Intro
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
¶ Client & Server
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
¶ Wozu Webhooks?
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
¶ Webhook als Softwareanbieter
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
¶ Eigenschaften von Webhooks
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.
¶ Bekannte Beispiele
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.