Client-Server-Kommunikation

Web Services mit GraphQL (statt REST/SOAP)

GraphQL ist ein modernes API-Paradigma, das sich zunehmend als Alternative zu klassischen Web-Service-Modellen wie REST oder SOAP etabliert. Im Vergleich zu diesen Modellen erlaubt GraphQL eine flexible, clientgesteuerte Datenabfrage über eine einheitliche Schnittstelle. Seine typisierte Struktur, die Möglichkeit zur Introspektion und die präzise Steuerung von Abfrageinhalten machen GraphQL besonders attraktiv für dynamische Webanwendungen und KI-basierte Systeme.

Einordnung: Was sind Web Services?

Web Services stellen eine standardisierte Methode dar, um Daten zwischen Client und Server auszutauschen – meist über das HTTP-Protokoll. Sie ermöglichen plattformunabhängige Kommunikation, eine lose Kopplung zwischen Systemkomponenten und den Zugriff auf zentrale Datenquellen oder Geschäftslogik.

Etablierte Architekturen im Vergleich

Im Laufe der Zeit haben sich drei grundlegende Web-Service-Modelle etabliert: SOAP, REST und GraphQL. Die folgende Tabelle bietet eine strukturierte Gegenüberstellung:

Kriterium SOAP REST GraphQL
Architekturtyp Protokollbasiert Architekturstil Abfragesprache & Laufzeitumgebung
Transportprotokoll HTTP, SMTP, TCP HTTP HTTP (meist POST)
Datenformat XML JSON, XML JSON
Endpunkte Mehrere, pro Operation Mehrere, pro Ressource Ein einziger Endpunkt
Abfrageflexibilität Gering – festgelegte Operationen Mittel – durch verschiedene Endpunkte Hoch – clientseitig definierte Abfragen
Versionierung Über WSDL-Dateien Häufig über URL-Versionierung (z. B. /v1/) Nicht erforderlich – Schema kann erweitert werden
Caching Komplex, selten genutzt Gut unterstützt durch HTTP-Caching Eingeschränkt – abhängig von Abfragekomplexität
Fehlerbehandlung Standardisierte Fehlercodes in XML HTTP-Statuscodes + optionale Fehlermeldungen Fehlerobjekte im JSON-Format
Sicherheitsmechanismen WS-Security (z. B. XML-Signaturen) TLS/HTTPS, OAuth, API-Keys TLS/HTTPS, OAuth, API-Keys
Einsatzgebiete Unternehmensanwendungen, Legacy-Systeme Web-APIs, Microservices, mobile Anwendungen Moderne SPAs, mobile Apps, datenintensive Anwendungen
Komplexität Hoch – umfangreiche Spezifikationen Mittel – abhängig vom Design

Hoch – insbesondere bei komplexen

Schemas

GraphQL im Detail

GraphQL ist ein modernes API-Design-Paradigma, das 2015 von Facebook veröffentlicht wurde. Es verfolgt einen abfragegetriebenen Ansatz, bei dem der Client exakt definiert, welche Daten benötigt werden. Dies unterscheidet sich grundlegend von REST, wo die Struktur der Antwort durch den Server vorgegeben wird.

Ein GraphQL-Endpunkt akzeptiert zwei Arten von Operationen:

Beispiel: Datenabfrage mit einer Query

query {
  books {
    title
    author
  }
}

Diese Abfrage fordert vom Server alle Bücher und gibt pro Buch nur die Felder title und author zurück – weitere Felder wie id, createdAt etc. werden ignoriert, sofern sie nicht explizit abgefragt werden.

Beispiel: Datenerzeugung mit einer Mutation

mutation {
  addBook(title: "Clean Code", author: "Robert C. Martin") {
    id
    title
    author
  }
}

Mutationen ähneln POST-Requests in REST. Sie erlauben das Anlegen, Verändern oder Löschen von Datenobjekten.

Aufbau eines GraphQL-Backends

Ein GraphQL-Dienst basiert auf einem Schema, das die verfügbaren Typen, Queries und Mutationen beschreibt. Die eigentliche Logik liegt in sogenannten Resolvern, die die Daten bereitstellen oder verändern.

Ein einfaches Setup umfasst:

  1. Definition des Schemas (Typen & Operationen)

  2. Implementierung der Resolver

  3. Bereitstellung über einen GraphQL-Server

Apollo Server

Für Node.js-Projekte ist Apollo Server eine der bekanntesten und am besten dokumentierten Lösungen zur Umsetzung eines GraphQL-Endpunkts. Apollo Server stellt Werkzeuge bereit, um:

Apollo lässt sich leicht mit Express oder Fastify kombinieren und ist durch seine Modularität für einfache wie komplexe Projekte gleichermaßen geeignet.

Weitere verwandte Tools im Apollo-Ökosystem sind:

GraphQL und KI

Ein zunehmend relevanter Anwendungsbereich für GraphQL ist die Kombination mit künstlicher Intelligenz (KI). Dabei ergeben sich mehrere Synergieeffekte:

Introspektive APIs für maschinelles Verständnis

GraphQL-APIs sind introspektiv – das heißt, sie geben auf Anfrage strukturiert Auskunft darüber, welche Operationen erlaubt sind, welche Parameter benötigt werden und welche Typen verfügbar sind. Das ist besonders im KI-Kontext von Vorteil:

Beispielhafte Introspection-Query

{
  __schema {
    queryType {
      fields {
        name
        args {
          name
          type {
            name
          }
        }
      }
    }
  }
}

Damit können LLMs (wie ChatGPT) oder andere KI-Systeme eigenständig die Struktur einer API analysieren – ohne auf externe Dokumentation angewiesen zu sein. REST-basierte APIs erfordern dafür meist zusätzliche Spezifikationen (z. B. OpenAPI).

Weitere Einsatzfelder

Typische Einsatzszenarien

GraphQL eignet sich besonders für Anwendungen mit variablen oder dynamisch zusammensetzbaren Datenansichten, z. B.:

Im CMS-Kontext ist GraphQL besonders dann interessant, wenn verschiedene Frontends unterschiedliche Datenansichten benötigen – etwa eine Vorschau in der Admin-UI und eine kompakte Darstellung im öffentlichen Blog.

Zusammenfassung

GraphQL ist ein leistungsfähiges und zugleich flexibel einsetzbares Werkzeug für moderne Webarchitekturen. Es bietet eine strukturierte und typisierte Alternative zu REST und ermöglicht effiziente, clientgesteuerte Datenabfragen. Die Einführung in ein Projekt lohnt sich vor allem dann, wenn unterschiedliche Clients auf dieselbe API zugreifen oder Daten gezielt gefiltert werden sollen.

Ein vollständiges Beispiel zur Umsetzung eines GraphQL-Servers mit Apollo und TypeScript findest du in unserem Repository: https://gitlab.rlp.net/marius.klein2/awt-marius-klein/-/tree/main/beispielaufgaben/server-client-kommunikation/1-graphql-book-service

Microservices

Microservices sind ein Architekturparadigma, das sich in den letzten zehn Jahren stark verbreitet hat. Der Begriff steht für eine Herangehensweise, bei der Software nicht mehr als eine große, monolithische Anwendung entwickelt und betrieben wird, sondern als Sammlung kleiner, voneinander unabhängiger Dienste. Jeder dieser Dienste erfüllt eine klar abgegrenzte Aufgabe innerhalb des Gesamtsystems und kommuniziert mit anderen Diensten über wohldefinierte Schnittstellen.

 

Ursprünge und Motivation

Die Idee der Microservices entwickelte sich im Kontext wachsender monolithischer Systeme, die mit zunehmendem Umfang schwer wart- und testbar wurden. Die Beobachtung: Je größer der Code und je mehr Teams beteiligt sind, desto größer wird die Reibung beim gemeinsamen Arbeiten an einer gemeinsamen Codebasis. Änderungen in einem Bereich ziehen häufig Änderungen in anderen Bereichen nach sich, und das Deployment eines Features kann durch die Abhängigkeit von nicht fertiggestellten Teilbereichen blockiert sein.

Microservices sind eine Antwort auf diese Skalierungsprobleme. Sie setzen auf:

 

Technisches Grundprinzip

Ein Microservice-System besteht aus mehreren eigenständigen Prozessen, die über Netzwerkprotokolle miteinander kommunizieren – in der Regel über HTTP (REST oder GraphQL), gRPC oder asynchrone Messaging-Systeme wie Kafka oder RabbitMQ.

Jeder Dienst bringt idealerweise seine gesamte technische Infrastruktur mit:

Diese vollständige Kapselung wird in der Praxis jedoch nicht immer konsequent umgesetzt. Besonders im Bereich der Datenpersistenz kommt es oft zu Überschneidungen, etwa wenn mehrere Dienste auf dieselbe Datenbank oder Tabelle zugreifen müssen. Das steht im Spannungsfeld zum Prinzip der vollständigen Isolation.

 

Paradigmen und Interpretationen

Es gibt verschiedene Interpretationen und Ableitungen des Microservices-Gedankens:

Diese Vielfalt führt dazu, dass unter dem Begriff „Microservices“ oft unterschiedliche Dinge verstanden werden. Eine klare und konsistente Definition fehlt bis heute.

 

Vorteile von Microservices

Vorteil Beschreibung
Skalierbarkeit Einzelne Services lassen sich unabhängig skalieren (z. B. CPU-hungrige Module).
Flexibilität Technologieentscheidungen können pro Dienst individuell getroffen werden.
Deployment-Freiheit Teams können unabhängig voneinander releasen.
Fehlertoleranz Ein Fehler in einem Dienst betrifft nicht notwendigerweise das Gesamtsystem.
Teamautonomie Kleinere Teams können Verantwortung für „ihren“ Dienst übernehmen.

 

Herausforderungen und Kritik

Nachteil / Herausforderung Beschreibung
Systemkomplexität Die Gesamtarchitektur wird komplexer, insbesondere hinsichtlich Kommunikation und Datenfluss.
Testing-Aufwand Integrationstests und End-to-End-Tests werden aufwendiger.
Verteilte Transaktionen ACID-Eigenschaften sind über mehrere Dienste schwer zu garantieren.
Fehlende Übersicht Es kann schwierig sein, einen systemweiten Überblick zu behalten.
Tooling & Infrastruktur Microservices benötigen reifes CI/CD, Observability, Logging, Monitoring.

 

Entwicklung und Trendwende

Microservices galten über Jahre hinweg als das Ideal moderner Softwarearchitektur. Viele Unternehmen haben ihre Systeme unter großem Aufwand von Monolithen auf Microservices umgestellt. Mittlerweile mehren sich jedoch die Stimmen, die auf die Nachteile und Überforderungen durch zu viele verteilte Komponenten hinweisen.

In der Praxis zeigt sich: Nicht jedes Team ist darauf vorbereitet, eine derart feingranulare Architektur sinnvoll zu betreiben. Auch große Unternehmen wie Amazon oder Uber haben Teile ihrer Architektur wieder konsolidiert oder stark modularisierte Monolithen eingeführt.

Derzeit entstehen vermehrt Architekturen, die eine Balance zwischen Modularität und Einfachheit suchen:

 

Wann sind Microservices sinnvoll?

Microservices lohnen sich besonders, wenn folgende Bedingungen erfüllt sind:

Für kleinere Projekte oder Teams kann ein gut strukturierter Monolith hingegen deutlich effektiver und wartbarer sein.

 

Infrastruktur und Orchestrierung

Microservices entfalten ihr volles Potenzial erst mit der passenden Infrastruktur. Zwei Schlüsseltechnologien, die den Betrieb verteilter Systeme ermöglichen, sind:

Ein „Cluster“ ist in diesem Zusammenhang eine Gruppe vernetzter physischer oder virtueller Server, auf denen Kubernetes die Microservices verteilt und steuert.

Der Aufbau eines produktionsreifen Microservice-Systems setzt daher Kenntnisse in Containerisierung und Orchestrierung voraus – ein Grund, warum der Infrastrukturaufwand im Vergleich zu monolithischen Architekturen deutlich höher ist.

 

Glossar

Begriff Bedeutung
API-Gateway Zentrale Anlaufstelle für externe Anfragen an ein Microservice-System.
Cluster Gruppe aus mehreren Servern, die gemeinsam eine verteilte Umgebung bilden.
Container Leichtgewichtige Umgebung zur isolierten Ausführung von Software-Komponenten.
DDD Domain-Driven Design – domänenzentrierter Ansatz zur Softwaremodellierung.
Docker Plattform zur Containerisierung und zum Deployment verteilter Anwendungen.
Kubernetes System zur automatisierten Verwaltung, Skalierung und Orchestrierung von Containern.
Monolith Architektur, bei der die gesamte Anwendung als eine Einheit betrieben wird.
Self-contained System Architekturansatz, bei dem jeder Dienst auch UI, Logik und Persistenz umfasst.
Service Discovery Verfahren, mit dem Microservices einander automatisch auffinden können.

 

Sockets

Das WebSocket-Protokoll ermöglicht eine bidirektionale, persistente Kommunikation zwischen Client und Server über eine einzelne TCP-Verbindung. Im Gegensatz zum traditionellen HTTP-Protokoll, das auf einem Anfrage-Antwort-Modell basiert, erlaubt WebSocket eine kontinuierliche Datenübertragung in beide Richtungen, ohne dass der Client ständig neue Anfragen stellen muss. Dies ist besonders nützlich für Anwendungen, die Echtzeitdaten erfordern, wie Chat-Anwendungen, Online-Spiele oder Live-Dashboards.

Historischer Kontext

Vor der Einführung von WebSockets waren Entwickler auf Techniken wie Polling oder Long Polling angewiesen, um Echtzeitkommunikation zu simulieren. Diese Methoden waren jedoch ineffizient und belasteten sowohl Server als auch Netzwerkressourcen. Mit der Standardisierung des WebSocket-Protokolls durch die IETF im Jahr 2011 (RFC 6455) wurde eine effizientere Lösung geschaffen, die echte bidirektionale Kommunikation ermöglicht.

Funktionsweise von WebSockets

Verbindungsaufbau (Handshake)

Der Verbindungsaufbau beginnt mit einem HTTP-Request des Clients, der ein Upgrade auf das WebSocket-Protokoll anfordert. Wenn der Server zustimmt, antwortet er mit einem 101 Switching Protocols-Statuscode, und die Verbindung wird auf WebSocket umgestellt. Ab diesem Punkt bleibt die Verbindung offen und ermöglicht den kontinuierlichen Datenaustausch.

Datenübertragung

Nach dem erfolgreichen Handshake können sowohl Client als auch Server jederzeit Nachrichten senden. Die Kommunikation erfolgt über Frames, die entweder Text- oder Binärdaten enthalten können. Diese Frames sind leichtgewichtig und verursachen minimalen Overhead, was zu einer effizienten Datenübertragung führt.

Vorteile von WebSockets

Nachteile und Herausforderungen

Anwendungsfälle

 

Implementierung im Backend mit Node.js und ws

Die ws-Bibliothek ist eine schlanke und performante Lösung zur Implementierung von WebSocket-Servern in Node.js. Sie ermöglicht die einfache Einrichtung eines Servers, der bidirektionale Kommunikation mit Clients unterstützt.


Installation

Zunächst wird ein neues Node.js-Projekt erstellt und die ws-Bibliothek installiert:

mkdir websocket-server
cd websocket-server
npm init -y
npm install ws

 

Einfacher WebSocket-Server

Im Anschluss kann ein einfacher WebSocket-Server wie folgt implementiert werden:

const WebSocket = require('ws');

const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', (ws) => {
  console.log('Neuer Client verbunden');

  ws.on('message', (message) => {
    console.log(`Empfangen: ${message}`);
    ws.send(`Server: ${message}`);
  });

  ws.on('close', () => {
    console.log('Client hat die Verbindung geschlossen');
  });
});

console.log('WebSocket-Server läuft auf ws://localhost:8080');

Dieser Server lauscht auf Port 8080 und ermöglicht es Clients, Nachrichten zu senden und Antworten zu empfangen.

 

Erweiterte Funktionen

Die ws-Bibliothek bietet zusätzliche Funktionen, wie z.B.:

 

Ein Beispiel für Broadcasting:

wss.on('connection', (ws) => {
  ws.on('message', (message) => {
    // Nachricht an alle Clients senden
    wss.clients.forEach((client) => {
      if (client.readyState === WebSocket.OPEN) {
        client.send(message);
      }
    });
  });
});


Implementierung im Frontend

Die WebSocket-API ist in modernen Browsern nativ verfügbar und ermöglicht eine einfache Integration:

const socket = new WebSocket('ws://example.com/socket');

socket.onopen = () => {
  console.log('Verbindung geöffnet');
  socket.send('Hallo Server!');
};

socket.onmessage = (event) => {
  console.log('Nachricht vom Server:', event.data);
};

socket.onclose = () => {
  console.log('Verbindung geschlossen');
};

socket.onerror = (error) => {
  console.error('Fehler:', error);
};

In diesem Beispiel wird eine Verbindung zum Server hergestellt, eine Nachricht gesendet und eingehende Nachrichten sowie Verbindungsereignisse behandelt.

Zusammenfassung

WebSockets bieten eine leistungsfähige Lösung für Anwendungen, die Echtzeitkommunikation erfordern. Durch die bidirektionale, persistente Verbindung können Daten effizient und mit minimaler Latenz übertragen werden. Trotz einiger Herausforderungen, wie Sicherheitsaspekte und Netzwerkkompatibilität, sind WebSockets ein unverzichtbares Werkzeug für moderne Webanwendungen.

Für weitere Informationen und tiefergehende technische Details empfiehlt sich die offiziellen Spezifikation RFC 6455 sowie die Dokumentation auf MDN Web Docs.

Message Queueing

Hier ist ein umfassender Wiki-Artikel zum Thema Message Queuing, mit besonderem Fokus auf RabbitMQ als Praxisbeispiel:

 

 

 

📬 Message Queuing – Grundlagen und Praxis mit RabbitMQ

 


 

1. Einführung: Was ist Message Queuing?

 


Message Queuing (MQ) ist ein Kommunikationsparadigma, das es ermöglicht, Nachrichten asynchron zwischen verschiedenen Komponenten eines Systems auszutauschen. Dabei werden Nachrichten in einer Warteschlange (Queue) zwischengespeichert, bis sie von einem Empfänger (Consumer) verarbeitet werden. Dieses Modell fördert die Entkopplung von Systemkomponenten und erhöht die Skalierbarkeit und Fehlertoleranz von Anwendungen.


 

2. Vorteile von Message Queuing

 

 

 


 

Anwendungsfälle

 


 

RabbitMQ – Ein Praxisbeispiel

RabbitMQ ist ein weit verbreiteter, quelloffener Message Broker, der das Advanced Message Queuing Protocol (AMQP) implementiert. Es ermöglicht das Senden, Empfangen und Weiterleiten von Nachrichten zwischen Anwendungen oder Diensten.

Grundkonzepte

 

Exchange-Typen

 

Implementierung mit RabbitMQ

Installation

RabbitMQ kann lokal installiert oder über Docker bereitgestellt werden. Eine einfache Möglichkeit ist die Verwendung des offiziellen Docker-Images:

docker run -d --hostname my-rabbit --name some-rabbit -p 5672:5672 -p 15672:15672 rabbitmq:3-management

Dies startet RabbitMQ mit dem Management-Plugin, das über http://localhost:15672 erreichbar ist.

 

Beispiel: Nachricht senden und empfangen mit Python

Verwendung der pika-Bibliothek:


Producer (Sender):

import pika

connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()
channel.queue_declare(queue='hello')
channel.basic_publish(exchange='', routing_key='hello', body='Hello World!')
print(" [x] Sent 'Hello World!'")
connection.close()

Consumer (Empfänger):

import pika

def callback(ch, method, properties, body):
    print(f" [x] Received {body}")

connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()
channel.queue_declare(queue='hello')
channel.basic_consume(queue='hello', on_message_callback=callback, auto_ack=True)
print(' [*] Waiting for messages. To exit press CTRL+C')
channel.start_consuming()

Diese einfachen Beispiele zeigen, wie Nachrichten in eine Queue gesendet und von dort empfangen werden können.

 

Zusammenfassung

Message Queuing ist ein leistungsfähiges Muster zur asynchronen Kommunikation in verteilten Systemen. RabbitMQ bietet eine robuste und flexible Implementierung dieses Musters und ist in vielen Szenarien einsetzbar, von einfachen Anwendungen bis hin zu komplexen Microservices-Architekturen.

 

Weiterführende Ressourcen: