![predic8](/img/default-banner.jpg)
- 251
- 1 256 611
predic8
Germany
Приєднався 6 січ 2014
Tutorials und Informationen für Programmierer und Softwarearchitekten über:
- Open Source Integration
- Big Data
- Java
- APIs
- Integration
- Microservices
Impressum
predic8 GmbH
Koblenzer Straße 65
53173 Bonn
info@predic8.de
Vertretungsberechtigte Geschäftsführer: Thomas Bayer, Tobias Polley
Registergericht: Amtsgericht Bonn
Registernummer: HRB 16152
Steuernummer: 206/5206/5943 Ust-IdNr.: DE259171855
Inhaltlich Verantwortliche gemäß § 6 MDStV: Thomas Bayer, Tobias Polley
Haftungshinweis: Trotz sorgfältiger inhaltlicher Kontrolle übernehmen wir keine Haftung für die Inhalte externer Links. Für den Inhalt der verlinkten Seiten sind ausschließlich deren Betreiber verantwortlich.
- Open Source Integration
- Big Data
- Java
- APIs
- Integration
- Microservices
Impressum
predic8 GmbH
Koblenzer Straße 65
53173 Bonn
info@predic8.de
Vertretungsberechtigte Geschäftsführer: Thomas Bayer, Tobias Polley
Registergericht: Amtsgericht Bonn
Registernummer: HRB 16152
Steuernummer: 206/5206/5943 Ust-IdNr.: DE259171855
Inhaltlich Verantwortliche gemäß § 6 MDStV: Thomas Bayer, Tobias Polley
Haftungshinweis: Trotz sorgfältiger inhaltlicher Kontrolle übernehmen wir keine Haftung für die Inhalte externer Links. Für den Inhalt der verlinkten Seiten sind ausschließlich deren Betreiber verantwortlich.
Low Code Integration mit Apache Camel Karavan - ausführliche Demo
Apache Camel Karavan ist eine innovative Low-Code Plattform zur grafischen Entwicklung von Integrationsanwendungen. Karavan ermöglicht es Anwendern, Integrationen effizient zu gestalten und sie auf Docker oder Kubernetes zu betreiben.
Karavan basiert auf dem leistungsfähigen und beliebten Apache Camel Framework. Integrationsanwendungen werden in Camel mit einer Domain spezifischen Sprache, einer DSL erstellt. Es gibt DSLs für Java, YAML und XML. Entwicklern ermöglicht die DSL ein effizientes Arbeiten. Voraussetzung für die Entwicklung mit Camel ist jedoch das Beherrschen von Java. Für die Arbeit mit Karavan sind dagegen keine Java Kenntnisse notwendig. Dem Anwender stehen in Karavan ebenso die zahlreichen Adapter und Integrationsmuster zur Verfügun.
Für Nicht-Programmierer gab es bislang verschiedene kommerzielle und Open-Source-Produkte zur grafischen Integrationserstellung. Karavan setzt sich durch folgende Vorteile ab: Immer auf dem neuesten Stand, unterstützt Karavan stets die aktuellen Features und Komponenten von Camel. Der grafische Editor ist eine Ergänzung zur Camel-YAML-Sprache und ermöglicht es, Integrationen als Quellcode in Git-Repositories abzulegen und so DevOps-Prinzipien zu implementieren. Zudem können die erstellten Routen ohne den Einsatz von Karavan auf Docker oder Kubernetes ausgeführt werden.
In dieser ausführlichen Live-Demonstration zeige ich, wie Apache Camel Karavan funktioniert und wie es die Entwicklung von Integrationsanwendungen unterstützt.
Inhalt:
00:00 Einleitung
01:00 Laufzeitumgebung
01:29 Life Demo
02:20 API Designer
03:07 Routen Editor
05:30 Enterprise Integration Patterns
05:53 Dataformats
07:00 Splitter
07:24 Grenzen von Low Code
09:15 MongoDB Service
09:55 Kamelets
11:25 YAML
12:45 Tracing
13:25 git Anbindung
14:48 Topology View
16:12 Kamelet selber schreiben
17:38 Docker Build
19:26 Deployment
20:00 Geschichte von Apache Karavan
Schulungen Online, in Bonn oder als Firmenseminar:
Integration mit Apache Camel
www.predic8.de/camel-schulung.htm
Intensivkurs Softwarearchitektur: Paradigmen, Technik und Praxis
www.predic8.de/softwarearchitektur-schulung.htm
Mich, Thomas Bayer findet ihr auf:
Twitter: @thomasub
Xing: www.xing.com/profile/Thomas_Bayer9
LinkedIn: www.linkedin.com/in/thomas-bayer-0291592/
Karavan basiert auf dem leistungsfähigen und beliebten Apache Camel Framework. Integrationsanwendungen werden in Camel mit einer Domain spezifischen Sprache, einer DSL erstellt. Es gibt DSLs für Java, YAML und XML. Entwicklern ermöglicht die DSL ein effizientes Arbeiten. Voraussetzung für die Entwicklung mit Camel ist jedoch das Beherrschen von Java. Für die Arbeit mit Karavan sind dagegen keine Java Kenntnisse notwendig. Dem Anwender stehen in Karavan ebenso die zahlreichen Adapter und Integrationsmuster zur Verfügun.
Für Nicht-Programmierer gab es bislang verschiedene kommerzielle und Open-Source-Produkte zur grafischen Integrationserstellung. Karavan setzt sich durch folgende Vorteile ab: Immer auf dem neuesten Stand, unterstützt Karavan stets die aktuellen Features und Komponenten von Camel. Der grafische Editor ist eine Ergänzung zur Camel-YAML-Sprache und ermöglicht es, Integrationen als Quellcode in Git-Repositories abzulegen und so DevOps-Prinzipien zu implementieren. Zudem können die erstellten Routen ohne den Einsatz von Karavan auf Docker oder Kubernetes ausgeführt werden.
In dieser ausführlichen Live-Demonstration zeige ich, wie Apache Camel Karavan funktioniert und wie es die Entwicklung von Integrationsanwendungen unterstützt.
Inhalt:
00:00 Einleitung
01:00 Laufzeitumgebung
01:29 Life Demo
02:20 API Designer
03:07 Routen Editor
05:30 Enterprise Integration Patterns
05:53 Dataformats
07:00 Splitter
07:24 Grenzen von Low Code
09:15 MongoDB Service
09:55 Kamelets
11:25 YAML
12:45 Tracing
13:25 git Anbindung
14:48 Topology View
16:12 Kamelet selber schreiben
17:38 Docker Build
19:26 Deployment
20:00 Geschichte von Apache Karavan
Schulungen Online, in Bonn oder als Firmenseminar:
Integration mit Apache Camel
www.predic8.de/camel-schulung.htm
Intensivkurs Softwarearchitektur: Paradigmen, Technik und Praxis
www.predic8.de/softwarearchitektur-schulung.htm
Mich, Thomas Bayer findet ihr auf:
Twitter: @thomasub
Xing: www.xing.com/profile/Thomas_Bayer9
LinkedIn: www.linkedin.com/in/thomas-bayer-0291592/
Переглядів: 349
Відео
Vertical Slice Architecture mit Java und Spring Boot (Code Beispiel mit Mediator)
Переглядів 60021 день тому
Die Vertical Slice Architecture (VSA) bietet eine überzeugende Alternative zur herkömmlichen Schichtenarchitektur. Sie zeichnet sich durch ihre einfache Verständlichkeit und leichte Umsetzbarkeit aus, was sie besonders attraktiv macht. Im Vergleich zu abstrakteren Architekturansätzen wie der Hexagonalen oder der Clean Architecture ist die Vertical Slice Architecture zugänglicher und weniger kom...
Basic Authentication für APIs: Sicherheitslücke oder einfache Alternative?
Переглядів 2 тис.Місяць тому
In diesem Video tauchen wir in das Thema "Basic Authentication für APIs" ein und beleuchten sowohl die Vorteile als auch die potenziellen Risiken dieser Authentifizierungsmethode. Basic Authentication (kurz: #BasicAuth) ist eine der ältesten und einfachsten Methoden, um den Zugriff auf ein #API zu sichern. Doch ist sie in der modernen, #sicherheit-sbewussten Welt der Softwareentwicklung noch ze...
Vertical Slice Architecture - Bessere Alternative zur Schichtenarchitektur?
Переглядів 944Місяць тому
Die Vertical Slice Architecture ermöglicht es, Use Case gesteuert vorzugehen und fachliche Anforderungen effizient umzusetzen. Entworfen wurde die Architecture von Jimmy Bogard, dem Entwickler des MediatoR-Frameworks. Bogard stieß bei der der Onion-Architektur auf diverse Schwierigkeiten und begann daraufhin, seinen Code anders zu organisieren. Im Video werfen wir einen genaueren Blick auf die ...
Hexagonal-, Onion- und Clean-Architecture verstehen in unter 15 Minuten
Переглядів 9672 місяці тому
Im Video stelle ich euch die Hexagonale Architektur, die Onion Architecture und die Clean Architecture vor. Diese Architekturen helfen, flexible und übersichtliche Systeme zu bauen und ermöglichen ein Vorgehen nach Domain Driven Design. Zunächst werfen wir einen Blick auf die klassische Schichtenarchitektur. Danach werde ich die Konzepte erläutern und Unterschiede sowie Gemeinsamkeiten der vers...
Eine Datenbank ist keine Schnittstelle!
Переглядів 2,4 тис.2 місяці тому
In diesem Video erfährst du, warum es problematisch ist, eine #Datenbank als #Schnittstelle zu verwenden, und wie du es besser machen kannst. Darüberhinaus erhältst du Argumentationshilfen für euer Projekt. Es kommt häufig vor, dass Datenbanken als Schnittstellen zwischen verschiedenen Anwendungen missbraucht werden. Obwohl der gleichzeitige Zugriff mehrerer Anwendungen auf eine Datenbank techn...
Was sind JSON Web Tokens? JWT Einführung in 12 Minuten
Переглядів 8693 місяці тому
Was sind JSON Web Tokens? Wie sehen #JWT aus? Wozu braucht man sie? JSON Web Tokens sind der De-Facto-Standard, wenn es um Sicherheitsmechanismen im Internetzeitalter mit REST-APIs geht. Es vergeht kein Tag, an dem kein #Token in meinem Namen im Internet unterwegs ist: Sei es bei Microsoft, Google oder Amazon. Häufig werden JWTs als Magie gesehen, da sie für Menschen schwierig lesbar sind (eyJh...
API Versionierung, Deprecation und Sunsetting mit OpenAPI - Ein Leitfaden
Переглядів 9333 місяці тому
#API #Versionierung ermöglicht es, Änderungen vorzunehmen, ohne den Ausfall von Clients zu riskieren. Sie dient der Verwaltung von Änderungen, wobei alles, was modifiziert werden kann, versioniert werden kann - sei es Dokumente, Quellcode oder APIs. Jeder Stand der Änderungen erhält eine Versionsnummer, um gezielt auf eine bestimmte Version zuzugreifen. API-Versionierung ist nicht zwingend erfo...
SaaS & Mandantenfähigkeit - Migration einer Standardsoftware in die Cloud
Переглядів 1,4 тис.5 місяців тому
Software as a Service (SaaS) ist ein attraktives Modell für Kunden und Anbieter. Anstatt eine Software an vielen Standorten dezentral zu installieren und betreiben, übernimmt der Anbieter zentral den Betrieb und stellt die Lösung über das Netz zur Verfügung. Dieses Video betrachtet die Migration einer Kaufsoftware zu einer Cloud-basierten SaaS Lösung aus der Sicht eines Softwarearchitekten, der...
Spring Modulith - Einführung, Code Beispiel & Live Demo
Переглядів 2 тис.6 місяців тому
Mit #Spring #Modulith können Anwendungen aus fachlichen #Modulen aufgebaut werden. Die Spring Boot Erweiterung unterstützt den Entwickler mit automatisierter Verifikation der Modultrennung, durch Modul-Tests und die Generierung von Dokumentation. Im Video wird gezeigt, wie eine Anwendung in Module gegliedert werden kann. Die Features von Spring Modulith werden in einer Live-Demo vorgeführt und ...
REST API Cache & Synchronisation mit ETag Header - API Caching Folge 3
Переглядів 4826 місяців тому
Web Browser speichern Webseiten, Bilder und Skripte in einem lokalen Cache, um ein unnötiges Übertragen beim erneuten Besuch einer Webseite zu vermeiden. Über einen HTTP Header, der #ETag oder Entity Tag genannt wird, kann die gespeicherte Version einer Ressource auf dem Client mit der aktuellen auf dem Server abgeglichen werden. Eine weitere Anwendung der ETags sind bedingte (conditionale) HTT...
Monolith, Microservices oder Modulith? Wie gebe ich Anwendungen eine Struktur?
Переглядів 1,4 тис.7 місяців тому
Neben #Microservices und #Monolith gibt es mit dem #Modulith eine dritte Alternative für die Softwarearchitektur einer Anwendung. Bei allen drei Ansätzen gibt es Möglichkeiten zur Strukturierung und Gliederung. In diesem Video erfährst du, was ein Modul ist und wie man in jedem der drei Architekturstile für Ordnung sorgt. 00:00 Begrüßung 00:21 Monolith 00:45 Struktur Monolith 04:47 Microservice...
API Caching mit Cache Server u. Cache-Control Header - #API #Caching Teil 2
Переглядів 4507 місяців тому
Ein #Cache Server kann die Antwortzeiten eines #API verkürzen und die Last von Server nehmen. Voraussetzung für das Caching ist die Einhaltung von HTTP- und #REST Prinzipien. Im Video wird gezeigt, wie zwischen Client und Server ein Web Cache Server wie z.B. squid, Varnish oder nginx platziert werden kann. Eine Anpassung des Quellcodes von Client oder Server ist nicht notwendig. Die Steuerung d...
Was ist ein API Cache? Einführung u. Funktionsweise - API Caching #1
Переглядів 1,2 тис.8 місяців тому
#Caching ist ein entscheidender Vorteile von #REST. Ein HTTP #Cache kann nachträglich zwischen API und Client geschaltet werden, ohne den Code anzupassen. Was ist ein Web Cache und wie funktioniert dieser? Was ist der Unterschied zwischen Web- und API-Caching? Wie bleibt ein Cache frisch? Auf diese Fragen gehe ich in diesem ersten Teil meiner Reihe zum API Caching ein 00:00 Einleitung 00:56 HTT...
Verteilung von Stammdaten - Softwarearchitektur am Beispiel
Переглядів 2,2 тис.8 місяців тому
Verteilung von Stammdaten - Softwarearchitektur am Beispiel
API Design First mit dem OpenAPI Code Generator
Переглядів 1,6 тис.9 місяців тому
API Design First mit dem OpenAPI Code Generator
Die Nachteile des API First Ansatzes
Переглядів 1,5 тис.10 місяців тому
Die Nachteile des API First Ansatzes
Was ist AsyncAPI? Format, Werkzeuge und Reife
Переглядів 1 тис.11 місяців тому
Was ist AsyncAPI? Format, Werkzeuge und Reife
Queue an API - Unzuverlässige Schnittstellen anbinden - Softwarearchitektur in der Praxis
Переглядів 1,8 тис.Рік тому
Queue an API - Unzuverlässige Schnittstellen anbinden - Softwarearchitektur in der Praxis
API an Queue am Beispiel einer Importschnittstelle - Softwarearchitektur in der Praxis
Переглядів 2,2 тис.Рік тому
API an Queue am Beispiel einer Importschnittstelle - Softwarearchitektur in der Praxis
Synchrone & asynchrone Kommunikation - Softwarearchitektur Grundlagen für Einsteiger
Переглядів 1,5 тис.Рік тому
Synchrone & asynchrone Kommunikation - Softwarearchitektur Grundlagen für Einsteiger
API Lifecycle mit DevOps und OpenAPI - Ausführliches APIOps Beispiel
Переглядів 921Рік тому
API Lifecycle mit DevOps und OpenAPI - Ausführliches APIOps Beispiel
API Design mit ChatGPT - Erstelle mir eine OpenAPI!
Переглядів 1,5 тис.Рік тому
API Design mit ChatGPT - Erstelle mir eine OpenAPI!
API Management oder APIOps? API Verwaltung in der Praxis
Переглядів 1,1 тис.Рік тому
API Management oder APIOps? API Verwaltung in der Praxis
Monolith oder Microservices Patterns?
Переглядів 1,3 тис.Рік тому
Monolith oder Microservices Patterns?
Warum ein Monolith oft besser ist als Microservices
Переглядів 4,9 тис.Рік тому
Warum ein Monolith oft besser ist als Microservices
Wie plane ich einen Kubernetes Cluster?
Переглядів 2,4 тис.Рік тому
Wie plane ich einen Kubernetes Cluster?
SQL oder NoSQL? Welche Datenbank passt zur Anwendung?
Переглядів 6 тис.Рік тому
SQL oder NoSQL? Welche Datenbank passt zur Anwendung?
Tradebot Wettstreit #2 - Softwarearchitektur, Zwischenstand & Algorithmus
Переглядів 1,4 тис.2 роки тому
Tradebot Wettstreit #2 - Softwarearchitektur, Zwischenstand & Algorithmus
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!
Danke
Sehr schön und ruhig erklärt. Man kommt gut mit und kann nebenbei am Juiceshop selbst testen.
Danke und viel Spaß beim "Hacken" mit dem Juiceshop.
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.
Ja, durch die Unterscheidung von Abfrage und Befehl, kannst du Lesen und Schreiben unterschiedlich behandeln. Für den Mediator könnte man Eventsourcing Infrastruktur wie z.B. AxonIQ einsetzen. Besonders, wenn man die Tools bereits im Einsatz hat. Der Charme von Jimmy Bogart's MediatoR ist, dass er embedded läuft und keine zusätzlichen Abhängigkeiten benötigt.
@@thomas-bayer Alles klar, vielen Dank.
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 für den Tip mit dem Command Bus. Vielleicht ist der von clouddogu eine Alternative. Das Projekt schaue ich mir mal genauer an. Die Spring Application Events gehen z.B. nicht, da es keinen Rückweg gibt. Apache Artemis oder NATS könnte man einsetzen, aber das wäre nicht mehr so leichtgewichtig.
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. 😄
Danke für deine Einschätzung. Die VSA halte ich auch nicht pauschal für die Architektur, die zu jedem Projekt passt. Momentan beobachte ich, dass es mit der Hexagonalen und Clean Architekture übertrieben wurde und man sich einen einfacheren Ansatz mit weniger Abstraktionen wünscht. Das könnte auch eine "normale" Spring Boot Anwendung sein. Bei manchen Projekten könnte ich mir durchaus vorstellen, dass die VSA passt: wenig oder nur einfache Businesslogik, hohe Fluktuation im Team, hoher Anteil an Junior-Entwicklern. Wie so oft gibt es in der IT keinen Königsweg.
@@thomas-bayer Ich weiß, was Du meinst. Genau vor dem Problem stehen wir auch gerade mit einem neuen Projekt. Zu wenig Entwickler, Fluktuation, zu viel Junior. Leider wird dadurch die Komplexität der vor uns liegenden Aufgabe nicht geringer. Machen wir uns nichts vor. Wenn heutzutage noch inhouse entwickelt wird, dann muss das gut begründet sein und vor allem dazu dienen, einen Business Value zu schaffen, den die Lösung vom Markt so nicht bietet. Ich gebe Dir sofort Recht, dass man nicht übertreiben darf mit den Schichten und Abstraktionen. Da kann man sich auch drin verlieren. Aber ich sag Dir mal meine Meinung, wo eigentlich das Hauptproblem der meisten Software-Projekte liegt: Dass a.) bereits alte Legacy-Systeme vorhanden sind, die man irgendwie ablösen muss, und niemand weiß mehr so genau, was die alles tun und warum. Und b.) die Fachbereiche einem nicht sagen können, was sie eigentlich wollen und wo die Reise hingehen muss - in einer Weise, die man versteht und in ein Design gießen kann. Denn wenn das alles klar wäre, dann kannst Du relativ straight forward beginnen, dein DDD machen, deine Bounded Contexts schneiden und schön nach und nach als Module umsetzen - und dabei noch schrittweise das Altsystem ablösen - die Würgefeige lässt grüßen. Aber wie gesagt brauchst Du dafür Leute, die wissen was sie wollen und andere Leute (dein Team), die wissen, was sie tun. 😀
It was a great video, but it could have been better if I understood the German language.
Thanks for your feedback. Hope the automatic translation works good enough.
@@thomas-bayer I can understand better with the draws, thanks for that.
Was mir gefehlt hat sind weitere Möglichkeiten, die die Lücke zwischen BasicAuth (einfach) und OAuth2 (komplex) schließen würden.
Das wäre ja Stoff für weitere Videos. (Ohne zuviel zu verraten: Es sind schon weitere Videos in Planung.) Denkst Du da an ein konkretes Verfahren?
@@TPolley Aber genau darum geht es ja, weil zwischen 1999 und 2024 nun eben eine "Lücke" von 25 Jahre klafft ;-). JWT wurde ja bereits behandelt. API-Keys wurden im Video erwähnt, dies wäre die Variante, bei der es sicherlich genug Spielarten gibt (HMAC, Digest Authentication). mutualTLS und Certificate Pinning wären auch noch zu nennen. Nun, genug Stoff fürs nächste Video!
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.
Danke für den Kommentar und das Feedback
Das klärt es endlich mal! Sehr sympathischer und gekonnter Vortrag!
Super, Danke. Weitere Videos zu API Sicherheit wären natürlich top.
Danke für den Kommentar. Ich glaube nicht, dass Tobias nur Basic Auth für APIs bespricht ;-) Da kommt bestimmt noch was 🙂
Top!
Gibts ein solches Tutuorial auch für GET Endpoints?
Nein, gibt es leider nicht. Ein GET kannst du aber ähnlich anlegen. Anstatt eines requestBody kannst du unter Parameters Query Parameter anlegen.
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.
dito
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 :)
Richtig getippt 😉 Das nächste Mal geht es um die Vertical Slice Architecture.
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?
Hallo @marcom, danke für deinen ausführlichen Kommentar. Der Unterschied zur klassischen Schichtenarchitektur ist bei den drei Architekturen die Unabhängigkeit zur Infrastruktur mittels Dependency Inversion. Ansonsten sind alle drei gleich und unterscheiden sich wie du schreibst nur im Namen, den Bezeichnungen und in der Notation der Diagramme. Selbst die Anzahl der Schichten ist in allen drei Ansätzen variabel. Die Diagramme, die in den Beschreibungen der Architekturen verwendet werden, unterscheiden sich, aber das ist nur Darstellung. Einige sehen da Unterschiede oder Vorschläge zur Einteilung der Schichten. Die Persistenz-Schicht gehört nicht zum Kern der Anwendung, zumindest nicht die Implementierung der Schicht. Intern werden nur die Schnittstellen z.B. für Repositories festgelegt (Hex: Port, Onion: Domain Services, Clean: Application Layer), die Implementierung z.B. KundenNoSQLRepository wird weiter außerhalb angesiedelt (Hex: Adapter, Onion: Infrastructure, Clean: Interface Adapters). Controller findest du im Zwiebelbeispiel von Palermo ganz außen in der Infrastrukturschicht. Use Cases sind in der Zwiebel in der Domain Schicht. Dass selbst Palermo sich nicht festlegt, wo genau was angesiedelt ist („The first layer around the Domain Model is <<typically>> where we would find interfaces…“) trägt sicher zur Verwirrung bei.
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?
Man trennt in Interface und Implementierung, um Komponenten zu bilden. Andere Module können das Interface kennen, die Implementierung ist aber verborgen, d.h. ein anderes Modul hat nur eine Abhängigkeit auf die Schnittstelle. Das trägt zur Gliederung und Flexibilität der Anwendung bei. Die Trennung benutzt man dann, wenn man abstrahieren möchte. Die Abstraktion hat aber auch ihren Preis. Es kann daher sinnvoll sein, in Interface und Implementierung zu trennen oder auf das Interface zu verzichten.
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"
Danke für den Hinweis. Das schaue ich mir gleich mal an.
@@thomas-bayer "Rolling Versions" scheint das Keyword für diese Art der Versionierung zu sein.
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.
Was hat das irgendwas mit der Cloud zu tun? So eine deutsche Aussage 😂 willkommen 1990.
@@maddinek Die Cloud hat Microservices aufgrund der Skalierbarkeit populär gemacht. Kenne keinen Microservice der nach vorne SQL spricht. Aber ich nehme an du weisst da mehr?
@@MegaBaellchen klar, die Cloud hat Microservices durch die Skalierbarkeit gepusht. Aber das ist nicht alles. Microservices sind auch beliebt, weil sie flexibel einsetzbar sind, unabhängig vom OS laufen und leichter redundant gestaltet werden können. Und ja, Microservices reden nicht direkt SQL (bzw sollten nicht), aber sie nutzen oft ORMs oder andere Abstraktionsschichten, um auf Datenbanken zuzugreifen. Ein Microservice, der Benutzerinfos verwaltet, könnte intern mit einer SQL-Datenbank kommunizieren, bleibt aber modular und unabhängig. Hab aber nach wie vor keine Ahnung was das mit Junioren und der Cloud zu tun haben soll? Anscheinend solltet ihr bessere Leute einstellen.
@@maddinek Na wenn du Monolithen baust hast du den connectionpool direkt zur DB irgendwo in deinem Stack. Ob mit ORM oder nicht, du arbeitest direkt mit der Datenbank. Mit Microservices hast du an der Stelle aber Rest oder GraphQL oder andere Protokolle. Darum kommen die Cloud natives, denen beigebracht wird Microservices statt Monolithen zu bauen, seltener direkt mit der Datenbank in Kontakt, bzw. sie setzen den Microservice der mit der Datenbank spricht mit der Datenbank selbst gleich. Aber gut ich glaub wir drehen uns im Kreis.
"die Blauen sind schuld" - jetzt aber nicht politisch werden, Herr Bayer, gell... ;-) - Scherz beiseite: prima Erklärung des Sachverhaltes!
Keine Ahnung, woran Du gedacht hast, aber vermutlich haben die meisten Datenbank-Experten an der Stelle des Videos an das große Softwarehaus in Walldorf gedacht, dessen Logo zufällig auch blau ist. Aber Entscheidungen für oder gegen bestimmte Software-Produkte sind oft auch mehr politischer, denn technischer Natur.
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 ?!
Ja Trigger, damit wäre das Beispiel noch besser. Am besten ganz viele über alle Tabellen verstreut mit Stored Procedures und mit viel herstellerspezifischen Funktionen 😉.
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.
Genau. Die Payload könnte er beliebig modifizieren. Allerdings passt dann die Signatur nicht mehr zum Inhalt (Header+Payload). Wenn das modifizierte Token dann ans Zielsystem geschickt wird, schlägt die Validierung der Signatur fehl. Die Signatur könnte man natürlich auch ersetzen. Um das korrekt zu machen, müsste der Mitarbeiter dann allerdings das Geheimnis kennen. - Und das tut er hoffentlich nicht. (Der Fall 'Geheimnis erraten' wird ja auch im Video diskutiert. Geht natürlich auch. Allerdings werden bei guten Geheimnissen sehr sehr sehr sehr viele Rateversuche benötigt, sodass dieser Angriff eher theoretischer Natur ist.) Wenn man Sorge hat, ob die Signatur am Zielsystem korrekt validiert wird (zum Beispiel, weil es sehr sehr viele Zielsysteme gibt), empfiehlt es sich, ein API Gateway vor das Zielsystem zu hängen. Alle HTTP Requests müssen dann durch den durch, bevor sie ans Zielsystem dürfen. Im API Gateway kann man dann die Logik 'wenn Token am Request, validiere Signatur' realisieren. (Full Disclosure: Wir geben als open source Projekt Membrane API Gateway heraus: www.membrane-api.io/ )
@@TPolley Hi, mal ne Frage dazu: ich habe mehrere Microservices und einen (eigenen) Authentifzierungserver. Ich mach die Validierung der Signatur nicht im API Gateway und auch nicht im Resourcenserver, sondern schick das pro Request immern an den Authentifizierungsserver, der dann auch (via Scopes) die Zugriffserlaubnis prüft. Der Vorteil davon ist, dass ich die Scopes dann direkt an den API-Endpunkten in den Resourcen-Microservices definieren kann, und das nicht irgendwie zentral im Gateway mache. Ich nutze Oauth2. Ist dieses Vorgehen Deines Erachtens sinnvoll?
@@legion_prex3650 Aus der Entfernung läßt sich das immer nur bedingt beurteilen. Das Token zu validieren, indem man es zum Authorization Server zurückschickt, ist auf jeden Fall eine Option. Je nach Szenario bekommt der dann halt eine Menge Traffic ab. Die Scopes dezentral zu verwalten, ist ein häufiger Wunsch. Dagegen ist auch erstmal nichts einzuwenden. Ob es dabei folgendes Szenario für Euch relevant ist, müsstet ihr klären. Szenario: Microservice A holt sich Tokens mit Scope S-A1 und S-A2. Microservice B holt Tokens mit Scope S-B. Soweit so geplant. Jetzt machen wir eine Privilege Escalation: B versucht - ungeplant - sich ein Token mit S-A1 zu holen. Die Frage ist: Geht das oder wird's korrekt verhindert? Das kann man natürlich in allen Kombinationen durchdeklinieren. (Ich hab das grundlegende Problem etwas - eigentlich unnötig - aufgebohrt, um näher an Deine Frage zu kommen.)
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.
Thanks for the comment. Hope the subtitles weren't to bad.
Danke
Bomben Video, die anderen Kommentare fassen es wirklich gut zusammen, sehr stark.
Danke für den Kommentar und das Feedback