Was ist Middleware? Definitions- und Beispielanwendungsfälle

Middleware ist ein häufig verwendeter Begriff in der Webentwicklung. Es kann je nach Kontext viele Dinge bedeuten, was den Begriff etwas verwirrend macht.

In diesem Artikel definieren wir zunächst den Begriff und diskutieren anschließend einige verschiedene Anwendungsfälle.

Nachdem Sie diesen Artikel gelesen haben, können Sie sich stärker auf technische und architektonische Gespräche mit Ihren Kollegen einlassen. Sie sind auch in der Lage, sichere und zuverlässige APIs und Datenflüsse zu entwerfen.

Definition von Middleware

Middleware ist eine Software, die als Vermittler zwischen zwei Anwendungen oder Diensten fungiert, um deren Kommunikation zu erleichtern.

Sie können sich das als Proxy vorstellen, der als Datenakkumulator, Übersetzer oder nur als Proxy fungieren kann, der Anforderungen weiterleitet.

Häufige Anwendungsfälle für Middleware

1) Übersetzer

Es gibt viele Datenaustauschformate wie JSON, XML und Protobuf. Obwohl wir heutzutage meistens JSON verwenden, hat jeder von ihnen seine eigenen Anwendungsfälle.

Beispielsweise ist bekannt, dass Protobuffer leistungsfähiger als JSON sind, sie sind jedoch nicht für Menschen lesbar. Möglicherweise verwenden Sie Protobuffer für interne Dienste und JSON, wenn der API-Consumer ein Browser ist.

Sie können auch meinen Artikel über Protobuffer lesen, wenn Sie mehr darüber erfahren möchten.

Nehmen wir nun an, wir benötigen diese beiden Dienste, die unterschiedliche Protokolle sprechen, um miteinander zu kommunizieren.

Wir können eine Middleware erstellen, die eine Datenkonvertierungsbibliothek verwendet und die Anforderungen in ein Format übersetzt, das der empfangende Dienst verstehen kann.

2) Akkumulieren-Duplizieren von Daten

Microservice-Architektur ist ein beliebtes Architekturmuster, das häufig in modernen Anwendungen angewendet wird.

Wenn Sie mit der Microservices-Architektur nicht vertraut sind, bedeutet dies im Grunde, dass Ihre Anwendung aus vielen kleinen Apps oder Diensten besteht, die unabhängig voneinander sind und über die Kommunikation über das Internet zusammenarbeiten.

In einem E-Commerce-Projekt verfügen Sie möglicherweise über einen Microservice zum Speichern und Abrufen von Produkten, einen weiteren Microservice zum Suchen und einen weiteren zum Authentifizieren und Speichern von Benutzern. Und jeder hat seine eigene Datenbank.

Nehmen wir nun an, wir möchten unsere Suche so implementieren, dass sowohl nach Benutzern als auch nach Produkten gesucht wird.

Wenn dies eine monolithische Anwendung wäre, könnten wir einfach eine Abfrage schreiben, um jede Tabelle zu durchsuchen und die Ergebnisse zu verknüpfen. Aber jetzt laufen unsere Datenbanken auf verschiedenen Servern.

Dieses Problem hat mehrere Lösungen, und wir werden zwei davon betrachten.

Daten akkumulieren

Wir können eine Middleware verwenden, um Anforderungen an beide Server zu senden und sie zu bitten, ihre Datenbanken nach Benutzernamen und Produkten zu durchsuchen, die dem gesuchten Wort entsprechen.

Dann können wir die Ergebnisse von beiden Servern sammeln und an den Client zurückgeben. Beachten Sie, dass die Anzahl der Anforderungen linear zunimmt, wenn wir die Anzahl der Server erhöhen (und diese Daten auch zusammenführen müssen).

Daten duplizieren

Wir können doppelte Daten auf unserem Suchserver speichern, damit er sie direkt durchsuchen kann, anstatt sie von Produkt- und Benutzerservern anzufordern. Dies ist weniger speichereffizient, aber viel schneller - und die Geschwindigkeit ist für Suchdienste von entscheidender Bedeutung.

Wenn die Tabellen, die wir benötigen, Produkt und Benutzer sind, können wir diese Tabellen auch auf unserem Suchserver erstellen. Wenn wir dann einen neuen Benutzer in unserer Benutzerdatenbank speichern, speichern wir auch eine Kopie auf dem Suchserver.

Wir haben einige Möglichkeiten: Erstens können wir die Speichermethoden des Suchservers von den Speichermethoden der Benutzer- und Produktserver aufrufen, um die Daten zu duplizieren. Oder wir können eine Middleware zum Speichern erstellen, die Folgendes bewirkt:

  • Wenn eine Speicheranforderung eingeht, rufen Sie den Speicher des Produkt- / Benutzerservers und den Speicher des Suchservers auf.
  • Wenn das erste Speichern fehlschlägt, rufen Sie das Speichern nicht bei einem anderen auf (dies hält die Datenbanken konsistent).

Schauen wir uns die Designdiagramme ohne und mit Middleware an. Erstens sieht es so aus ohne:

Sieht hässlich aus, oder? In der Tat ist es hässlich und macht Ihren Code komplizierter und enger gekoppelt.

Hier ist die gleiche Lösung mit einer Middleware:

In diesem Szenario ruft die Clientseite nur die Middleware auf, um ein Produkt oder einen Benutzer zu speichern, und der Rest wird erledigt.

Es gibt keinen Code zum Duplizieren der Daten, weder auf den Produkt- oder Benutzerservern noch auf der Clientseite. Middleware kümmert sich um das Zeug.

3) API-Sicherheit

Für jeden clientseitigen Front-End-Code können wir die ausgehenden Anforderungen entweder in der Browserkonsole oder über einen Proxy anzeigen.

Wir haben über einen Benutzerserver gesprochen, der sich um die Anmeldung und Anmeldung kümmert. Wenn unser Front-End-Code die Anforderungen direkt an diesen Server sendet, wird die Adresse unseres Authentifizierungsservers angezeigt. Nach dem Erlernen der IP-Adresse unseres Backends können Angreifer mithilfe von Tools unsere Endpunkte finden und unseren Server auf Schwachstellen scannen.

Wir können Middleware als Proxy verwenden, um die URL unseres Authentifizierungsservers zu verbergen. Unser Front-End kommuniziert mit Middleware und leitet die Anforderung an den Authentifizierungsserver weiter und gibt die Antwort zurück.

Mit diesem Ansatz können wir auch alle Anforderungen an unseren Authentifizierungsserver blockieren, mit Ausnahme der Anforderungen von der URL unserer Middleware. Dies macht unseren Authentifizierungsserver viel sicherer.

Dies war bisher nicht möglich, da unser Frontend mit dem Authentifizierungsserver kommunizierte. Da das Frontend den Computer des Clients bedeutet, konnten wir keinen IP-Filter anwenden.

4) Offenlegen öffentlicher APIs

Im vorherigen Teil haben wir gelernt, dass Middleware verwendet werden kann, um den Zugriff auf unsere API einzuschränken.

Schauen wir uns nun die andere Seite der Gleichung an: Was ist, wenn wir eingeschränkten Zugriff auf unsere API gewähren möchten? Vielleicht sind wir Software Engineer bei einer Bank und die Bank plant einen Hackathon. Wir müssten Zugriff auf unsere API gewähren, oder?

Da wir eine Bank sind, können wir natürlich nicht auf die gesamte API zugreifen und jede Operation zulassen. Dies bedeutet, dass wir einen Weg finden müssen, um einen eingeschränkten Zugang zu ermöglichen.

Zu diesem Zweck können wir eine Middleware implementieren, die nur einige der Endpunkte verfügbar macht und die Anforderungen an unsere eigentliche API umleitet. Dann stellen wir diese API den Entwicklern beim Hackathon zur Verfügung.

Fazit

In diesem Beitrag haben wir zunächst definiert, was Middleware ist, und versucht, die Anwendungsfälle von Middleware in der Webentwicklung zu kategorisieren.

Denken Sie daran, dass dies keine vollständige Liste der Anwendungsfälle ist, aber ich hoffe trotzdem, dass es für Sie hilfreich war.

Danke fürs Lesen. Wenn Ihnen der Artikel gefallen hat, lade ich Sie ein, meinen Blog zu lesen. Sie können auch meine Mailingliste abonnieren, um benachrichtigt zu werden, wenn ich einen neuen Beitrag veröffentliche :)