Was ist gRPC? Unterschied zu REST

Was ist gRPC?

Kurz gesagt: Was ist gRPC? Es ist ein Open Source Framework für entfernte Prozeduraufrufe (Remote Procedure Call), das Google auf Basis von HTTP/2 entwickelt hat. Es überträgt Daten als kompakte Protocol Buffers Nachrichten und erlaubt Ihnen, eine Methode auf einem entfernten Server aufzurufen, als wäre sie lokal.

Unser Team trifft auf diese Frage besonders oft, wenn ein Projekt in eine Microservice Architektur übergeht. Sobald die Anzahl der Dienste wächst, gewinnt die Geschwindigkeit und Zuverlässigkeit der Kommunikation zwischen ihnen schnell an Bedeutung. In diesem Beitrag erklären wir die Grundmechanik, die Rolle von Protocol Buffers, den Unterschied zu REST API und GraphQL sowie typische Einsatzszenarien, gestützt auf die offizielle grpc.io Dokumentation.

In den folgenden Abschnitten finden Sie außerdem die vier Kommunikationsmodelle, unterstützte Programmiersprachen, die Fehlerbehandlung und die ersten Schritte zur Einrichtung. Unser Ziel ist es, einen dichten Fachbegriff in klarer Sprache mit echten Beispielen zu erklären.

Was ist gRPC in der Praxis für ein Problem wert?

Ein großes System hat oft Dutzende Dienste, die sich ständig gegenseitig aufrufen. Jede Anfrage als schweren, textbasierten Datensatz zu übertragen, bremst das ganze System aus. Ein binäres Format löst dieses Problem teilweise, denn es belegt auf der Leitung deutlich weniger Platz.

Außerdem wählen verschiedene Teams oft unterschiedliche Sprachen: ein Dienst in Go, ein anderer in Java, ein dritter in Python. Ohne einen gemeinsamen Vertrag bauen Sie für jede Integration eigenen Verbindungscode. Dieses Framework definiert einen Vertrag, den jede Sprache gleich versteht; ein Client in einer Sprache spricht dadurch problemlos mit einem Server in einer anderen.

Somit bauen Teams die gleiche Integrationslogik nicht für jedes neue Dienstpaar erneut auf. Eine einzige Quelldatei wird zur gemeinsamen Referenz, auf die sich alle Seiten verlassen.

Wie funktioniert gRPC technisch?

Zunächst schreiben Sie eine .proto Datei, die alle Methoden eines Dienstes samt ihren Parametern und Rückgabewerten auflistet. Konkret ist diese Datei der Vertrag, auf den sich Server und Client einigen.

Danach liest der protoc Compiler diese Definition und erzeugt Client und Server Code in Ihrer Zielsprache. Also füllen Sie nur die generierten Funktionen mit echter Logik. Die Netzwerkverbindung, das Paketformat und die Fehlerbehandlung im Detail bauen Sie dabei nicht selbst.

Laut der offiziellen grpc.io Einführung erzeugt der generierte Code serverseitig eine Schnittstelle, die Sie implementieren, und clientseitig ein Objekt, das man Stub nennt. Sie rufen diesen Stub auf, als wäre er ein ganz normales lokales Objekt.

Was ist Protocol Buffers (Protobuf)?

Protocol Buffers ist die Standard Schnittstellenbeschreibungssprache (IDL) dieses Frameworks und übernimmt zugleich die binäre Serialisierung. Sie beschreiben jede Nachricht in einer .proto Datei als benannte Felder; eine Benutzernachricht enthält zum Beispiel ein Namensfeld und ein E-Mail Feld.

Anders als JSON wiederholt Protobuf Feldnamen nicht in jeder Nachricht. Stattdessen nutzt es einmal vergebene, nummerierte Felder. Dadurch bleibt das Paket klein und das Parsen geht schneller.

Bei großen, häufig wiederholten Dienstaufrufen spart Protobuf dadurch echte Bandbreite gegenüber textbasierten Formaten. Unser Team beobachtet diesen Unterschied bei stark frequentierten Diensten klar. Sobald Sie Feldnummern einmal festlegen, pflegen Sie Kompatibilität mit alten Clients, selbst wenn sich der Dienst weiterentwickelt.

Wächst ein Dienst, fügen Sie der gleichen .proto Datei neue Felder hinzu. Alte Clients überspringen unbekannte Felder einfach, sodass alte und neue Version parallel laufen. Entfernen Sie ein Feld komplett, verwenden Sie dessen Nummer nicht erneut, sonst deuten ältere gespeicherte Datensätze die Werte später falsch.

Diese einfache Regel macht Versionswechsel in einem großen System deutlich sicherer. Teams aktualisieren Dienste dadurch unabhängig voneinander; ein Team ergänzt ein Feld, während ein anderes noch die ältere Version nutzt, ohne vorher ein Meeting zu brauchen.

Warum läuft dieses Framework über HTTP/2?

Die Wahl von HTTP/2 als Transportschicht ist kein Zufall. HTTP/2 transportiert viele Anfragen gleichzeitig über eine einzige Verbindung, daher entfällt der Aufwand, für jeden Aufruf eine neue Verbindung zu öffnen.

Außerdem komprimiert HTTP/2 Header und bietet beidseitiges Streaming. Die offizielle Dokumentation beschreibt genau diese Streaming Unterstützung: Server und Client senden über dieselbe Verbindung fortlaufend Nachrichten in beide Richtungen.

Warum ist das wichtig? Weil genau diese HTTP/2 Eigenschaft die Grundlage für die vier Streaming Modi bildet, die Sie gleich sehen. Mit reinem HTTP/1.1 bräuchten Sie für dieselbe Flexibilität deutlich mehr zusätzliche Schichten.

Was ist der Unterschied zwischen REST API und gRPC?

REST API überträgt meist JSON als Text und arbeitet über HTTP Methoden wie GET und POST gegen benannte Ressourcen. Das Grundprinzip einer API haben wir bereits in unserem Beitrag Was ist eine API erklärt, das wiederholen wir hier nicht.

Dieses Framework legt seinen Vertrag dagegen über eine .proto Datei fest und überträgt Daten binär. Dadurch verbraucht es weniger Bandbreite und arbeitet mit geringerer Verzögerung als ein typischer REST Aufruf.

Andererseits lesen Browser und allgemeine Webclients REST Antworten direkt, ohne zusätzliche Werkzeuge. Genau deshalb bleibt REST die verbreitetere Wahl für öffentliche, nach außen offene APIs. Ihre Entscheidung hängt letztlich davon ab, wer den Dienst aufruft.

Was ist der Unterschied zwischen GraphQL und gRPC?

GraphQL erlaubt dem Client, genau die gewünschten Felder anzugeben, und läuft meist über einen einzigen Endpunkt. Dieses Thema und den Vergleich zu REST behandeln wir in unserem Beitrag Was ist GraphQL, daher wiederholen wir diese Geschichte hier nicht.

Hier zählt nicht flexible Abfrage, sondern eine schnelle, streng vertraglich geregelte Kommunikation zwischen Diensten. Statt die wechselnden Datenwünsche einer mobilen App zu bedienen, zielt dieses Framework auf zwei Server, die schnell und zuverlässig miteinander sprechen müssen.

Kurz gesagt sind alle drei Kommunikationswege, doch jeder bedient ein anderes Publikum: einer die Außenwelt, einer flexible Clients, einer interne Systeme.

Wie vergleichen Sie gRPC, REST und GraphQL?

Stellen Sie die drei Methoden nebeneinander, erkennen Sie viel leichter, welche zu welchem Szenario passt. Die folgende Tabelle fasst die wichtigsten Unterschiede zusammen.

Behalten Sie beim Lesen dieser Tabelle eines im Kopf: Keine Zeile macht die anderen überflüssig. Jede Methode gewinnt in ihrem eigenen Szenario.

Wie viele Kommunikationsmodelle hat gRPC?

Nach der technischen Antwort lohnt sich ein Blick auf die Kommunikationsmodelle. Laut dem offiziellen grpc.io Leitfaden zu den Grundkonzepten definiert dieses Framework vier Arten von Dienstmethoden.

• Unary: Der Client sendet eine Anfrage, der Server liefert eine Antwort.
• Server Streaming: Der Client sendet eine Anfrage, der Server liefert eine Folge von Nachrichten.
• Client Streaming: Der Client sendet eine Folge von Nachrichten, der Server liefert eine Antwort.
• Bidirectional Streaming: Client und Server senden unabhängig voneinander Nachrichten über dieselbe Verbindung.

Diese vier Modelle decken ganz unterschiedliche Datenflussbedürfnisse innerhalb eines einzigen Frameworks ab. Schauen wir uns jedes einzeln an.

Was ist ein Unary RPC?

Ein Unary RPC ähnelt am stärksten einem klassischen Funktionsaufruf. Der Client sendet eine Anfrage, der Server verarbeitet sie, und eine einzige Antwort kommt zurück. Für eine einfache Abfrage oder eine einzelne Datenaktualisierung passt dieses Modell am besten.

Konkret nimmt ein Bestellabfragedienst eine Bestellnummer entgegen und liefert den Bestellstatus in einer Antwort zurück. In der Praxis beginnen die meisten Teams mit diesem Modell, denn sein Verhalten lässt sich am einfachsten vorhersagen und testen.

Neue Teams starten meist hier, bevor sie zu Streaming wechseln, sobald sie es wirklich brauchen. Dieser schrittweise Weg hält die Lernkurve überschaubar und bringt den ersten Dienst schneller in den produktiven Einsatz.

Was ist ein Server Streaming RPC?

Beim Server Streaming sendet der Client eine einzige Anfrage, doch der Server liefert die Antwort als Folge von Nachrichten statt als einen Block. Dann liest der Client diese Nachrichten nacheinander.

Dieses Modell passt zu großen Ergebnismengen, die Sie stückweise übertragen, oder zu einem ständig aktualisierten Datenstrom wie einem Live Preisstream. Daher beginnt der Server mit dem Senden, bevor er alle Daten vollständig vorbereitet hat.

Ein Suchdienst kann so Ergebnisse liefern, sobald er sie findet, statt vorher alles zu sammeln. Der Client zeigt frühe Ergebnisse sofort an, während weitere Daten im Hintergrund eintreffen.

Was ist ein Client Streaming RPC?

Beim Client Streaming tauschen sich die Rollen: Der Client sendet eine Folge von Nachrichten nacheinander, und der Server liefert erst am Ende des gesamten Stroms eine einzige Antwort.

Diese Struktur passt zu einem Gerät, das Messdaten in Stücken sendet, die am Ende zu einem zusammengefassten Ergebnis führen. Statt alles vorher zu sammeln, sendet der Client die Daten in dem Moment, in dem sie entstehen.

Ein Upload Dienst zeigt das gut: Der Client teilt eine Datei in kleine Teile und sendet sie nacheinander, der Server antwortet mit einer einzigen Bestätigung, sobald jedes Teil angekommen ist. Dieser Ansatz braucht deutlich weniger Arbeitsspeicher, als eine große Datei auf einmal zu senden.

Was ist ein Bidirectional Streaming RPC?

Bidirectional Streaming erlaubt beiden Seiten, unabhängig voneinander über dieselbe Verbindung Nachrichten zu senden und zu empfangen. Somit schreiben und lesen beide Seiten in ihrem eigenen Tempo.

Dieses Modell passt zu Echtzeit Chat, gemeinsamen Arbeitswerkzeugen oder jedem System, das einen fortlaufenden, beidseitigen Datenfluss braucht. Konkret hält die offizielle Dokumentation fest, dass die Nachrichtenreihenfolge innerhalb eines einzigen RPC Aufrufs fest bleibt, sodass keine Seite vertauschte Daten erhält.

Von den vier Modellen ist dieses das anspruchsvollste, denn beide Seiten müssen genau steuern, wann die Verbindung endet. Richtig umgesetzt, bietet es Ihnen etwas, das einer eigenen Messaging Schicht nahekommt, ohne dass Sie ein separates Echtzeitsystem von Grund auf bauen.

Wann wählen Sie dieses Framework?

Sie greifen zu diesem Framework vor allem, wenn der Verkehr zwischen Servern hoch ist und Leistung wirklich zählt. Vor allem interne Dienste, die niemals direkt nach außen gehen, passen gut zu diesem Profil.

1. Systeme, in denen mehrere Microservices häufig und mit geringer Latenz miteinander kommunizieren.
2. Umgebungen, in denen Dienste aus verschiedenen Sprachen einen gemeinsamen Vertrag brauchen.
3. Überwachungs oder Telemetriesysteme, die auf fortlaufendes Streaming setzen.
4. Mobile Clients, die über eine Verbindung mit begrenzter Bandbreite mit einem Backend sprechen.

Im Gegenzug bleibt REST die praktischere Wahl für APIs, die Sie direkt aus einem Browser aufrufen und einem breiten Entwicklerkreis öffnen. Zudem können Sie diese Liste als Checkliste nutzen und jeden Dienst einzeln bewerten.

Ein Zahlungsdienst, der ständig mit einem Lagerdienst kommuniziert, passt intern sehr gut. Ein öffentliches Kundenportal im gleichen System spricht dagegen meist weiterhin über REST oder GraphQL.

Warum ist gRPC für Microservices von Vorteil?

Was ist gRPC also wert, sobald ein System aus mehreren Microservices besteht? In einer Microservice Architektur wächst die Anzahl der Aufrufe zwischen Diensten schneller als die Anzahl der Dienste selbst. Die zugrunde liegende Logik behandeln wir in unserem Beitrag Was ist Microservices Architektur, hier konzentrieren wir uns direkt auf den Beitrag dieses Frameworks.

Das binäre Format zusammen mit HTTP/2 basiertem Multiplexing senkt Latenz und Netzwerklast bei diesem starken internen Verkehr. Die gemeinsame .proto Datei hält den Vertrag auch dann konsistent, wenn getrennte Teams Dienste unabhängig voneinander bauen.

Dadurch entdecken Teams Integrationsfehler früh, bereits beim Kompilieren. Wenn Sie Backend Sprachen für Microservices vergleichen möchten, lohnt sich unser Beitrag Python gegen Go im Vergleich als nächste Lektüre.

Mit wachsender Dienstanzahl gewinnt die Beobachtbarkeit ebenfalls an Bedeutung. Sie füttern Ihre Überwachungswerkzeuge mit den Metriken, die dieses Framework für jeden Aufruf liefert, und erkennen so schneller, welcher Dienst zum Flaschenhals wird.

Welche Programmiersprachen unterstützt gRPC?

Die offizielle Dokumentation hält klar fest, dass dieses Framework Server und Clients in vielen Sprachen erlaubt, sodass ein Server in einer Sprache problemlos mit einem Client in einer anderen Sprache spricht. Der sprachspezifische Code aus dem protoc Compiler macht das möglich.

• Teams schreiben die Serverseite häufig in Go, Java, C++ oder Python.
• Die Clientseite läuft in Web, mobilen und Desktop Anwendungen in unterschiedlichen Sprachen.
• Der generierte Code für jede Sprache stammt aus derselben .proto Definition, daher bleibt das Verhalten konsistent.

Diese mehrsprachige Unterstützung wird in großen Unternehmen mit unterschiedlichen Technologiepräferenzen zu einem echten Vorteil. Ein Team wählt für die Datenverarbeitung vielleicht Python, ein anderes schreibt einen leistungskritischen Dienst in Go, trotzdem sprechen beide denselben Vertrag.

Welche Grenzen und Nachteile gibt es?

Dieses Framework passt nicht zu jedem Szenario. Ein direkter Aufruf aus dem Browser braucht eine zusätzliche Brückenschicht, denn Standardbrowser bieten keinen vollen Zugriff auf die benötigten, niedrigschwelligen HTTP/2 Funktionen.

Außerdem ist das binäre Format für das menschliche Auge nicht lesbar, daher brauchen Sie bei der Fehlersuche zusätzliche Werkzeuge. Zudem braucht ein Team, das neu mit diesem Stack arbeitet, mehr anfängliche Einrichtungszeit für das Schreiben von .proto Dateien und die Codeerzeugung als für einen einfachen REST Endpunkt.

Ein Teil der Überwachungs und Protokollierungswerkzeuge braucht außerdem ein Zusatzmodul, um binären Datenverkehr zu lesen. Das ist ein kleiner Punkt, den Sie in Ihrer Planung berücksichtigen sollten. Für ein kleines Team mit nur einem Dienst übersteigt dieser Zusatzaufwand oft den Nutzen, daher lohnt sich die Frage "Was ist gRPC wert" erst bei entsprechendem Verkehrsvolumen.

Jedes neue Teammitglied muss zudem die Vertragssprache selbst lernen. Diese Lernkurve verlangsamt ein kleines, schnelles Team in den ersten Wochen etwas, mit der Zeit gleicht die gewonnene Konsistenz diesen Aufwand aber wieder aus.

Was ist grpc-web und wie nutzen Sie es im Browser?

Zurück zur Browser Einschränkung: grpc-web ist genau die Schicht, die darauf antwortet. Standardbrowser verwalten rohe HTTP/2 Streams nicht direkt, daher läuft Browserverkehr zuerst über einen Proxy.

Dieser Proxy nimmt die Anfrage, die ein Browser senden kann, und übersetzt sie in das Format, das der echte Backend Dienst erwartet. Die Antwort reist denselben Weg zurück, in einer für den Browser lesbaren Form. Eine Webanwendung spricht so dieselbe, streng vertraglich geregelte Sprache wie Ihre Backend Dienste, allerdings laufen Streaming Modi jenseits von Unary und Server Streaming auf der Browserseite nicht immer gleich reibungslos.

In der Praxis ergibt diese Brücke Sinn für Teams, die zwischen einer mobilen App und Backend Diensten bereits einen Vertrag teilen und diesen Vertrag auf eine Weboberfläche erweitern wollen. Einen gemeinsamen Vertrag zu schreiben schlägt die Pflege von zwei getrennten Integrationscodes für dasselbe Backend.

Nicht jedes Projekt braucht diese Zusatzschicht. Ist Ihr Verkehr gering und ein einfacher REST Endpunkt funktioniert bereits gut, fügt eine zusätzliche Proxy Schicht meist nur Komplexität hinzu, ohne klaren Nutzen. Diese Entscheidung hängt vollständig vom Umfang Ihres Projekts ab.

Wie funktioniert die Fehlerbehandlung bei gRPC?

Dieses Framework nutzt eine eigene Menge von Statuscodes statt HTTP Statuscodes; jeder Aufruf endet entweder erfolgreich oder mit einem bestimmten Fehlercode. Der Client liest diesen Code, um zu entscheiden, ob er die Anfrage wiederholt.

Ist ein Server zum Beispiel überlastet, liefert er einen Code zurück, der auf fehlende Ressourcen hinweist. Ein gut gebauter Client wiederholt die Anfrage in diesem Fall nicht sofort; stattdessen wartet er kurz und versucht es danach erneut, ein Muster, das die offizielle Dokumentation direkt empfiehlt.

Auch Zeitlimits (Deadlines) gehören zur Fehlerbehandlung: Ein Client bricht einen Aufruf selbst ab, sobald ein festgelegtes Zeitfenster ohne Antwort verstreicht. Dadurch blockiert ein langsamer Dienst nicht die gesamte Kette, denn der Fehler bleibt auf einen einzigen Aufruf begrenzt, während der Rest des Systems weiterläuft.

Wie schreiben Sie Tests für gRPC Dienste?

Sobald Sie eine klare Dienstdefinition in einer .proto Datei schreiben, bauen Sie getrennte Testreihen für Server und Client. Servertests bestätigen, dass jede Methode bei gegebener Eingabe die richtige Antwort liefert.

Clienttests laufen meist gegen einen simulierten Server, dadurch validieren Sie Szenarien ohne echte Netzwerkverbindung. Beim Testen von Streaming Methoden prüfen Sie zudem die Nachrichtenreihenfolge und den Zeitpunkt, an dem der Stream tatsächlich endet.

Integrationstests, die kurzzeitig eine echte Serverinstanz starten und Ihren Clientcode dagegen laufen lassen, liefern das Ergebnis, das dem Produktionsverhalten am nächsten kommt. Testen Sie an dieser Stelle auch Fehlercodes und Zeitlimit Szenarien, denn diese Fälle tauchen in der lokalen Entwicklung selten auf. Ein kleiner Lasttest mit wenigen gleichzeitigen Aufrufen ist zudem eine gute Gewohnheit, um das Verhalten unter Druck zu prüfen.

Unser Team prüft sowohl Unary Aufrufe als auch vorhandene Streaming Methoden mit getrennten Szenarien, bevor ein neuer Dienst live geht. Dieser Schritt fängt einen beachtlichen Teil der Überraschungen ab, bevor sie die Produktion erreichen.

Wie starten Sie die Einrichtung?

Der erste Schritt ist die Installation des protoc Compilers und des gRPC Plugins für Ihre Zielsprache. Danach schreiben Sie eine .proto Datei, die Ihre Dienste und Nachrichten definiert.

Nach dem Kompilieren fügen Sie den generierten Code Ihrem Projekt hinzu. Serverseitig füllen Sie die Methodenkörper, clientseitig rufen Sie den generierten Stub auf. Läuft Ihre Entwicklungsmaschine auf Apple Silicon, verhalten sich manche älteren Pakete anders; das behandeln wir in unserem Beitrag Apple Silicon Paketinkompatibilität.

Wird die Einrichtung einer eigenen Projektumgebung komplex, lohnt sich ein Blick auf unsere individuelle Softwareentwicklung. Wir wägen dieselben Architekturentscheidungen selbst ab, wann immer wir Kommunikation zwischen Diensten für einen Kunden entwerfen.

Was bedeuten Channel und Metadata?

Ein Channel ist das Verbindungsobjekt, das einen Client mit einem bestimmten Server verknüpft; der Client baut darüber einen Stub und führt Aufrufe aus. Konkret kann ein Channel unterschiedliche Zustände haben, etwa verbunden oder im Leerlauf.

Metadata sind Schlüssel Wert Informationen, die einen Aufruf begleiten; Authentifizierungsdaten reisen zum Beispiel meist über Metadata. Die offizielle Dokumentation reserviert jeden Schlüssel, der mit grpc- beginnt, für die interne Nutzung. Wählen Sie für Ihre eigenen Schlüssel daher ein anderes Präfix.

Diese beiden Begriffe richtig zu verstehen, erleichtert die spätere Fehlersuche deutlich. Zudem beschleunigt eine gemeinsame Metadata Konvention in großen Teams die Integration zwischen Diensten.

Eine Anfragekennung, die Sie über Metadata mitführen, lässt Sie zum Beispiel bei einem Fehler die Protokolle mehrerer Dienste unter demselben Schlüssel durchsuchen. Diese kleine Gewohnheit verkürzt die Zeit, einen Fehler in einem verteilten System aufzuspüren, und erspart dem Dienst habenden Entwickler viel Rätselraten.

Wie arbeitet dieses Framework mit Sicherheit und Drittanbieter Werkzeugen?

Authentifizierung kombiniert meist eine Verschlüsselung auf Channel Ebene mit Tokens in den Metadata. Wir empfehlen, in der Produktion unter keinen Umständen eine unverschlüsselte Verbindung einzusetzen.

Für Überwachung, Ratenbegrenzung oder Caching greifen Sie auf Drittanbieter Schutzwerkzeuge zurück; wir nennen bewusst kein einzelnes Produkt und empfehlen, Optionen nach Ihrem eigenen Bedarf zu bewerten. Jedes Werkzeug hat eigene Integrationsschritte, daher ist ein Blick in die offizielle Dokumentation der sicherste Weg.

Ebenso wichtig ist die Planung, wer mit welcher Berechtigung auf welchen Dienst zugreift. Teilen sich mehrere Teams dasselbe Servicenetz, verringert eine zentral definierte Berechtigungsregel spätere Verwirrung deutlich.

Fazit: Was ist gRPC also wert?

Zusammengefasst lässt sich was ist gRPC so beantworten: ein leistungsorientiertes Framework für die Kommunikation zwischen Diensten, aufgebaut auf HTTP/2 und Protocol Buffers. Es bietet internen Microservices mit häufigen, schnellen Aufrufen eine wirklich starke Option.

Im Gegensatz dazu bleiben REST oder GraphQL meist praktischer für öffentliche APIs, die ein Browser direkt liest. Eine frühe Entscheidung, welcher Dienst welches Protokoll spricht, erspart Ihnen später eine schmerzhafte Neuentwicklung.

Ein kleines Startprojekt läuft womöglich gut als einzelner Monolith, doch sobald die Dienstanzahl wächst, kommt diese Frage zurück. Trennen Sie internen und externen Verkehr früh, beantwortet sich die Protokollfrage meist von selbst.

Unser Team klärt diese Entscheidung am liebsten gemeinsam mit Kunden gleich am Anfang jeder neuen Dienstarchitektur, denn eine frühe, richtige Entscheidung senkt den späteren Pflegeaufwand erheblich. Jedes Projekt hat sein eigenes Verkehrsprofil und seine eigene Teamstruktur, daher bewerten wir jeden Fall einzeln statt eine feste Vorlage anzuwenden.