Відео

Wir haben eine Camel-Schulung für unsere IPaaS-Initiative die auch auf Karavan basiert bei Predic8 konsumiert und ich kann sie nur empfehlen.

Erinnert mich stark an Node-RED. Jedenfalls interessant

Vielen Dank für das informative Video. Lohnt sich wirklich es sich mal tiefer anzuschauen wie es scheint.

Ich bin ein wenig entsetzt. Das Beispiel Abruf von Kundendaten über das Internet spricht doch klar gegen Basic Auth. Du hast hier eine schützenswerte Ressource, wo sichergestellt werden muss, dass ein Aufrufer berechtigt ist, eine solche Schnittstelle abzurufen. In der Regel beschränken sich Prüfungen mit ob Nutzer und Passwort übereinstimmen. Wer aber kümmert sich um Schwachstellen in Bezug auf Brute Force Angriffe. Des Weiteren sendet man das Passwort bei Basic Auth im Klartext. Man muss Sorge tragen, dass solche Header in keinen Logs landen, weil wie bereits erwähnt, ein Zurücksetzen des Passwort nicht möglich ist. Bei hardkodierten auf dem Server kommt erschwerend hinzu, dass ich einen Nutzer nicht einfach sperren kann. Außerdem muss ich mich darauf verlassen, dass alle im Prozess beteiligten Personen die Credentials sicher verwahren. Werden sie kompromitiert, ist ein Wechsel nicht möglich. Aus meiner Sicht ist das Absichern von Schnittstellen mit Basic Auth, über die sensible Daten übertragen werden etwas, was man auf keinen Fall machen sollte.

Gehört zu den besten Videos zu dem Thema, die ich je gesehen habe! Danke!

Sehr schön und ruhig erklärt. Man kommt gut mit und kann nebenbei am Juiceshop selbst testen.

Was mich vor Jahren an dem ganzen Thema total ernüchtert hat sind Proxies, welche SSL-Verschlüsselung aufbrechen. Der Browser fragt beim Proxy, der Proxy leitet weiter, bekommt vom Server die Daten SSL-Verschlüsselt, der Proxy entschlüsselt, prüft (=verarbeitet), verschlüsselt mit seinem Proxy-Zertifkat und schickt es an den Browser und der Browser merkt davon exakt null, weil das Proxy-Zertifikat im Browser (getestet mit den offiziellen Downloads vom [damals noch] IE, Chrome, Firefox, Opera, Safari) auf die Wildcard * hinterlegt ist. Und das Tolle: der Proxy muss nicht Mal konfiguriert werden sondern wird - dank DHCP/DNS - stets gezogen (sprich: alle Anfragen gehen pauschal an die IP des Proxy). So ein Ding beim ISP aufgestellt und der ganze SSL-Zauber ist vorbei. Da ist es dann egal ob Basic-Auth, Oauth2, gegenseitiger Zertifikatsaustausch, oder was auch immer. Da hilft nur das Protokoll zu wechseln, weil der Proxy das dann nicht mehr versteht. Allerdings sollen "gute Proxies" das aufbrechen nicht nur mit SSL beherrschen, sondern auch mit diversen anderen Protokollen wie SSH, Wireguard, usw..

Könnte man den JMediator theoretisch mit dem CQRS-Pattern vergleichen, und somit auch Sachen von AxonIQ dafür verwenden? Ich finde die Features von AxonIQ auch u.a. nützlich für sowas.

Super, dass das Thema auch endlich bei Java in Deutschland ankommt. Aber das mit den Dateien ist kein Zwang. Wenn die Quelldateien *über alle Schichten* hinweg in einem Package sind, ist das in auch Ordnung. Die Gruppierung nach Feature ist, glaube ich, auch nur eine Vorliebe und sollte als Ratschlag gesehen werden. Es ist durchaus vorstellbar, dass der Slice ein ganzes (DDD)-Aggregat ist. Eine Alternative zum Mediator ist ein Command Bus (wie z. B. der von clouddogu). Damit kann keinen Stream von Handler erzeugen, sollte aber für die Fälle, bei denen man die Vor- und Nachbearbeitung eines Commands nicht explizit von der eigentlichen Verarbeitung trennen möchte, ausreichend sein.

Danke natürlich erstmal für die Mühe, solch ein Beispiel zu erstellen. Aber wenn ich mir die Details so anschaue, dann hat es schon seinen Grund, warum man das bisher in der Java-/Spring-Welt nicht findet. 😄 Ich war schon kurz davor, einen langen Kommentar über die diversen fragwürdigen Dinge zu formulieren. Aber ich glaube ich belasse es dabei festzustellen, dass ich als Software-Architekt da nichts wichtiges verpasst habe und unsere Entwickler damit nicht behelligen muss. 😄

It was a great video, but it could have been better if I understood the German language.

Was mir gefehlt hat sind weitere Möglichkeiten, die die Lücke zwischen BasicAuth (einfach) und OAuth2 (komplex) schließen würden.

Wie immer sehr informativ und gut erklärt !

Super Video, das sollte jeder IT-Absolvent einmal gesehen haben! Ich finde es prima, wie du die Unterschiede, aber v.a. die Gemeinsamkeiten der Architekturen herausstellst.

Das klärt es endlich mal! Sehr sympathischer und gekonnter Vortrag!

Super, Danke. Weitere Videos zu API Sicherheit wären natürlich top.

Top!

Gibts ein solches Tutuorial auch für GET Endpoints?

Jetzt bin ich auf das Beispiel gespannt. Denn eigentlich habe ich das Gefühl, dass hier jetzt irgendwie alles durcheinander gewürfelt wird: Software-Architektur, Modularisierung, Repository-Aufteilung. Ich kann und sollte doch auch mit jeder beliebigen Schichtenarchitektur die Ziele von minimierter Koppelung und maximaler Kohäsion erreichen. Das gebietet doch schon das DDD, wo wir Bounded Contexts identifizieren und daran unsere Modularisierungsschnitte ausrichten. Sprich jedes Modul entspricht einer gewissen Fachlichkeit. Die Gesamtheit der Module bildet die vertikalten Schnitte. Natürlich verwende ich dann innerhalb jedes Moduls eine Schichtenarchitektur - egal ob wir die jetzt Onion oder sonstwie nennen. Wie viele Repositories ich daraus mache, steht doch auf einem ganz anderen Blatt. Theoretisch kann alles in einem Repo sein, oder jedes Modul hat sein eigenes Repo, oder ich teile sogar jedes Modul noch auf mehrere Repos auf (lieber nicht). Und auch ob ich das ganze später als Modulith oder Microservices deploye bleibt dabei noch offen. Also, was ist jetzt der Clou an der Vertical Slices Architecture? Dass ich nicht fachlich im Sinne von DDD schneide, sondern technisch/organisatorisch nach umzusetzenden Features? Das klingt für mich nicht wirklich viel versprechend. Ein Feature ist schließlich kein Ordnungsbegriff, den man in einer Architektur vorfindet, sondern lediglich als Ordnungskriterium in der Projektorganisation während der Umsetzung. Ich finde es generell auch nicht hilfreich, dass selbst im Jahre 2024 immer wieder neue Säue durchs Dorf getrieben werden. Eigentlich sollten wir Architekten wohl langsam mal wissen, wie man Software sinnvoll schneidet und organisiert.

Gut erklärt!

Klingt erstmal so, als würde man auf den einzelnen Ebenen Code duplizieren, um Abhängigkeiten zu vermeiden? Selten sind die einzelnen Use-Cases absolut orthogonal...

Vielen Dank für die slice Einführung. Freu mich schon auf das spring boot Beispiel, super 👍

Wie eine Geschichte erklärt, vielen Dank!

Vielen Dank für die Erläuterungen. Freue mich auf das Spring Boot Beispiel.

Super Tutorial!

Was für ein Gefasel, ohne Mehrwert und in sich absolut inkonsistent. Nach vier Minuten war ich dann endgültig raus, es ging nicht mehr, nachdem du dein KundenRepository Interface in die BLL gepackt hast, kurz nachdem du die klaren Abhängigkeiten nach unten definiert hattest. Wie implementierst du denn ein Interface aus einer Schicht auf die du gar keinen Zugriff hast? Das ist lächerlich. Auch wie du am Anfang die Architekturen einfach mit DDD zusammen gewürfelt hast. DDD kannst du mit jeder Architektur machen, das hat rein garnichts damit zu tun. Ich arbeite seit 25 Jahren in Enterprise Umgebungen und Software Projekten mit hunderten bis tausenden Entwicklern. Overarchitecturing, genauso wie Overengineering, sind Haupt-Faktoren warum Software Projekte scheitern. Viel wichtiger als das hier ist immer eine gute, einfache Implementation (oder besser technisches Design), die einfach dokumentiert ist, Clean Code und saubere Trennung vor allem durch naming (bsp: Controller, Manager, Service) damit jeder Entwickler sofort weiß, wo was zu finden ist, und gute Contracts dazwischen. Starre, unverständliche Anwendungsarchitekturen, die meist nur der Architekt versteht der aber niemals eine Zeile Quellcode geschrieben hat, sind kontraproduktiv und stiften nur Verwirrung. Es ist im Kleinen (Anwendungs-Architektur) wie im Großen (Deployment-Struktur) das Gleiche, nur ein bisschen mehr wird immer gleich richtig viel teurer am Ende. KISS Prinzip, oder du bist einfach nur schlecht in dem was du tust.

Super Einfuehrung :) Ich habe letztens noch eine BA von der HHU gelesen, wo die Erfinder sich einig waren, dass die Modelle mehr oder weniger dasselbe in Gruen sind. Interessant finde ich da die Blogbeitraege von Jimmy Bogard ueber seine Erfahrung bzgl Onion-Architektur und der daraus resultierenden Vertical Slice Architektur. Ich hoffe die wurde fuer das naechste Video geteasert :)

Irgendwie ist es alles die gleiche Suppe. Mich irritieren eher die Versuche, für die eigentlich immer gleichen Prinzipien ständig neue Namen zu erfinden. Erstmal: Es sind doch alles Schichten-Architekturen. Und natürlich gab es auch schon vor 25 Jahren Abstraktionen durch die Trennung von Interface und Implementierungen. Ok, wir hatten da noch keine DI-Frameworks, aber sowas wie Factories und Service-Provider. Neue Begriffe wie "Ports" einzuführen und mit einer hexagonalen Architektur irgendeine Bedeutung auf die Zahl 6 zu legen, halte ich für unnötig und täuscht diffuse Neuerungen vor, wo gar keine sind. Die Onion Architektur bleibt leider eher vage in diesem Video. Es bleibt z.B. unklar, wieso die Infrastruktur ganz außen ist, obwohl da offenbar sowohl externe Infrastruktur (z.B. eine REST-API) als auch interne (Persistenz-Schicht) dazu gehört. Für mich auf diesem Level nicht nachvollziehbar. Dann kommt noch die Clean Architecture, um die Verwirrung komplett zu machen. Irgendwie ähnlich zur Zwiebel und der Bienenwabe, aber schon wieder andere Begriffe auf anderen Abstraktionsebenen. Wo würde man z.B. Controller und Use Cases in der Zwiebel finden? Oder wieso sind Presenters auf gleicher Ebene wie Controller?

Sehr gute Übersicht... Alistair Cockburn wird allerdings ohne "ck" ausgesprochen = Alistair Co burn

Ich liebe diesen deutschen Content. Weiter so!

Wieso trennt man in ein Interface und eine Implementierung und macht nicht einfach eine normale Java Class als Service?

Hatte eine lustige Erfahrung damit. Team A hat einen Teil vom Schema und Team B nen anderen Teil. Team B nutzt einen Modeller in dem das ganze Schema abgebildet ist. Bei Änderungen wurde das ganze Schema gedropped und man hat sich gewundert wo auf einmal die ganzen Testdaten waren😂

Interessant ist auch wie Stripe es mit der Versionierung macht: es wird bei jeder Versionsänderung auch ein "ChangeSet" für Abwärtskompatiblität erstellt. So dass jede bisherige Version auch mit bedient werden kann. Gut erklärt in der Docu mit dem Titel: "APIs as infrastructure: future-proofing Stripe with versioning"

Deshalb lässt man Entwickler nicht an Datenbanken rum frickeln. Für so etwas gibt es Leute, die etwas von Datenbanken verstehen. Und statt seltsamen Übergabetabellen verwendet man procedures und Views, die den Anwendungsentwicklern zur Verfügung gestellt werden. Da gab's vor vielen Jahren schon Talks zB. von Zalando zu. Das Problem mit den Verbindungen kann man auch problemlos lösen, für so etwas gibt es z.B. pgbouncer. Microservice.... Noch mehr unnötiger Quatsch. Vielleicht vernünftige Datenbanken verwenden und Leute, die wissen, was sie tun.

Wie im richtigen Leben. Team A hat die ganze Arbeit und Team B jammert wenn etwas nicht ad hoc funktioniert. 😅

In meinem Bereich kommt das regelmäßig vor… auch dass das Reporting bricht. Die Kunden sagen Observability nur sehr selten vor einem Change Bescheid, deshalb sind meist auch die Kunden selbst verantwortlich dafür, ihre SQL-Abfrage zu pflegen. Schreiben in fremde Datenbanken tun wir nur äußerst ungern, wäre zeitweise zwar praktisch, oft scheint es aber so, als ob die Betreiber von sich glauben, die einzigen zu sein, und dass man als Observability-Team nichts Besseres zu tun hat, als alle 5 Minuten die Notizen aus den Tiefen eines Intranets zu ziehen.

Ich war verblüfft, als unsere neuen junioren meinten sie hätten eine Datenbank entwickelt. Es war expressjs. Offenbar ist durch die Cloud das Verständnis etwas verzogen, was eine Datenbank ist, . De facto haben sie in ihrem leben wahrscheinlich immer mit irgendwelchen Rest APIs gearbeitet, und dies so in ihrer Vorstellung mit einer Datenbank gleichgesetzt. Immerhin verwenden sie eine Abstraktionsschicht, bei dem Videotitel fühlte ich mich jedoch direkt angesprochen.

"die Blauen sind schuld" - jetzt aber nicht politisch werden, Herr Bayer, gell... ;-) - Scherz beiseite: prima Erklärung des Sachverhaltes!

Bei uns wird die Datenbank fast überall als Schnittstelle verwendet. Dazu kommt eine Regional übergreifende Replikation. Jedes größere Update ist der Horror und kostet so viel Zeit, Planung, Downtime... Leider fehlt bei uns jeglicher Wille etwas zu verbessern, wenn es nicht gerade ein fertiges "DevOps" Tool gibt welches man halbherzig auf das Problem werfen kann.

"Da machen Microservices mal Sinn!" 😆

Wieso Timer und keine Trigger ?!

1:03:48 gemeinsamer Bus, Architektur. 1:04:17 Arten von Mikroservice Architekturen = gemeinsame DB oder gemeinsame Services oder gemeinsamer bus Regel Architektur: es gibt immer etwas gemeinsames 1:06:28 mikroservicedefinition als architekturstil und kultur 1:08:19 1:08:31 fazit: das was geteilt wird bestimmt den Service schnitt

sehr Hilfreich Dankeschön :)

Ihr solltet Vorlesungen für IT-Studenten halten. So wichtiges Zeugs wird meist nicht vermittelt.

Danke für das Video. Sehr gut erklärt. Was mich bei 11:10 etwas irritiert. Es wird angegeben, dass der User Admin ist. Wenn ein Mitarbeiter, welcher einen normalen Token (bsp, Admin false oder Groups = "Mitarbeiter") hat, könnte den Eintrag von false auf true setzen oder als Gruppe Admin hinzufügen. Den manipulierten Token könnte man dann in die Session schreiben und dieser würde dann bei der nächsten Anfrage mitgegeben. Dies wäre dan ein ziemliches Sicherheitsrisiko.

Genial erklärt. Ich habe es immer noch nicht geschafft eine Schulung zu buchen, steht aber auf der Agenda.

Wieder alles sehr gut erklärt - Danke👋

Thank you so much, I´m sorry for my English, I´m from Bolivia and speak Spanish.. I´m happy fpr my with your video explain, grettings.

Danke

Bomben Video, die anderen Kommentare fassen es wirklich gut zusammen, sehr stark.