5 Alternativen zu node-fetch im Vergleich: Native Fetch, Axios, Got, Ky und SuperAgent

Es gibt keinen universellen Sieger unter den „node-fetch“-Alternativen. Beginnen Sie mit den Funktionen, die Ihre Anwendung tatsächlich benötigt, und überprüfen Sie anschließend die installierte Hauptversion sowie die Node.js-Basisversion.

Diese Optionen lassen sich in drei Kategorien einteilen: eine Laufzeit-API, ein Fetch-Wrapper und vollständige HTTP-Clients. Vergleichen Sie innerhalb der richtigen Kategorie, anstatt jede Funktionslücke als Mangel zu betrachten.

Betrachten Sie die Entscheidung als „behalten“, „entfernen“ oder „ersetzen“. Behalten Sie node-fetch bei, wenn sein aktuelles Verhalten durch Tests abgedeckt ist, Ihre Laufzeitbeschränkungen dies rechtfertigen und eine Migration keinen konkreten betrieblichen Nutzen bringt. Entfernen Sie es, wenn Ihre unterstützten Node.js-Versionen bereits globales `Fetch` bereitstellen und Ihr Code nur standardkonforme Anfragen benötigt. Ersetzen Sie es, wenn Wiederholungsversuche, Hooks, gestaffelte Timeouts, zentralisierte Transformationen oder Upload-Hilfsfunktionen zu einer von der Anwendung verwalteten Infrastruktur werden.

Ein praktischer Leitfaden zur Erstellung von HTTP-Anfragen mit „node-fetch“ kann weiterhin nützlich sein, wenn Sie eine bestehende Integration warten. Das Paket ist nicht automatisch die falsche Wahl, nur weil neuere Laufzeiten „Fetch“ enthalten. Die relevante Frage ist, ob eine andere Option das Risiko oder den Code reduziert, ohne die Semantik stillschweigend zu ändern.

Natives Fetch reduziert die Abhängigkeitsfläche und richtet den Servercode am standardisierten Modell aus, das aus Request, Response, Headers und Body besteht. Die offizielle globale Fetch-Dokumentation von Node.js enthält Angaben zur Versions- und Stabilitätshistorie, die Sie mit der genauen, in der Produktion eingesetzten Laufzeitumgebung abgleichen sollten.

Verlassen Sie sich nicht auf ein angenommenes Plattform-Timeout. Legen Sie mit `AbortController` eine explizite Frist fest oder verwenden Sie AbortSignal.timeout() erst dann, nachdem Sie sich vergewissert haben, dass die API in jeder unterstützten Node.js-Version vorhanden ist.

Die dokumentierte „node-fetch“-Dokumentation beschreibt v3 als ausschließlich ESM-basiert und v2 als CommonJS-kompatibel. Sie berichtet zudem über gebündelte TypeScript-Deklarationen für v3 und eine ältere Mindestversion von Node.js; diese Details und Wartungshinweise sind jedoch zeitabhängig. Überprüfen Sie die Paket-Metadaten, bevor Sie sich für eine der beiden Varianten entscheiden.

Verfahren Sie ebenso bei Axios, Got, Ky und SuperAgent. Überprüfen Sie engines, type, exportsund types mit npm view <package> engines type exports typesund testen Sie anschließend die tatsächliche Importform in der CI. Aktuelle Hauptversionen können sich hinsichtlich ESM-Unterstützung, CommonJS-Interoperabilität und Laufzeitanforderungen unterscheiden.

Verwenden Sie dies als Vorauswahl. B steht für „integriert“, A für „Add-on oder Adapter“ und M für „manuellen Anwendungscode“. Ein Sternchen kennzeichnet eine zeitkritische Funktion, die einer release-spezifischen Überprüfung bedarf.

Die längste Funktionsliste ist selten das beste Kriterium. Definieren Sie den Anforderungsvertrag: Body-Kodierung, Statusfehler, Fristen, Wiederholungsversuche und den an den nachgelagerten Dienst übergebenen Stream-Typ. Eine Wahl unter den Node-Fetch-Alternativen ist nur dann sicher, wenn diese Verhaltensweisen beabsichtigt bleiben.

Dieser Leitfaden berücksichtigt keine Geschwindigkeitsrankings, Downloadzahlen, Sternebewertungen, Angaben zur Paketgröße und Wartungs-Ranglisten. Ohne aktuelle Messwerte, Datumsangaben und eine angegebene Methode vermitteln diese Zahlen eher eine falsche Präzision als eine fundierte technische Entscheidung.

Clients im Fetch-Stil erfordern in der Regel explizite JSON.stringify()Inhalts-Header, das Parsen von Antworten sowie response.ok Prüfungen. Axios wandelt Objekt-Nutzdaten um, stellt geparsten Inhalt auf response.dataund lehnt standardmäßig Antworten, die nicht im 2xx-Bereich liegen, ab, sofern validateStatus diese Regel geändert wird. Dieser Unterschied kann dazu führen, dass Code aus einem normalen Zweig in catch.

Legen Sie Fristen unabhängig vom Client explizit fest. Unterscheiden Sie zwischen einer Gesamtfrist für die Anfrage und den Phasen „Verbindung“, „TLS“, „First-Byte“ und „Socket“. Auch für Wiederholungsversuche ist eine schriftlich festgelegte Richtlinie erforderlich. Die Wiederholung eines GET-Aufrufs nach einem vorübergehenden Fehler unterscheidet sich von der Wiederholung eines POST-Aufrufs, der möglicherweise bereits abgeschlossen wurde. Behandeln Sie die Unterstützung für automatische Wiederholungsversuche als Richtlinien-Engine und nicht als einfaches Kontrollkästchen.

Bei Node.js-Diensten und beim Scraping bestimmen oft die Transportdetails den Client. Die Proxy-Unterstützung kann über eine Client-Option, einen HTTP-Agenten, einen Fetch-Dispatcher oder einen Adapter erfolgen. Die Persistenz von Cookies erfordert in der Regel ein JAR oder Anwendungslogik, da serverseitige Clients den Cookie-Speicher eines Browsers nicht erben.

Prüfen Sie, ob Antwortkörper Node.js Readable Streams oder WHATWG ReadableStream -Objekte sind, bevor Sie die Download-Pipelines ändern. Überprüfen Sie das Verhalten von Multipart-FormData, Dateigrößenbeschränkungen, die Behandlung von Weiterleitungen, die Dekomprimierung und den Gegendruck. Die HTTP/2-Unterstützung kann vom Client, einer Erweiterung oder der zugrunde liegenden Laufzeitumgebung bereitgestellt werden.

Ein praktischer Leitfaden zur Proxy-Konfiguration in `node-fetch` und ein umfassenderer Leitfaden zum Web-Scraping mit JavaScript und Node.js sind naheliegende Begleitmaterialien, wenn diese Transportaspekte bei der Migration im Vordergrund stehen.

Bei unterstützten Laufzeiten sollte „Native Fetch“ die erste Basis sein, an der andere „node-fetch“-Alternativen gemessen werden. Es bewahrt die vertraute, auf Promises basierende Schnittstelle ohne externes Client-Paket, behält aber auch die bewusste Explizität von Fetch bei: Man serialisiert JSON, parst den Antworttext und entscheidet selbst, was ein HTTP-Fehler bedeutet.

const controller = new AbortController();
const timer = setTimeout(() => controller.abort(), 5_000);

try {
  const response = await fetch('https://api.example.com/items', {
    signal: controller.signal
  });

  if (!response.ok) {
    throw new Error(`HTTP ${response.status}`);
  }

  const items = await response.json();
  console.log(items);
} finally {
  clearTimeout(timer);
}

Dieses Beispiel legt eine eigene Frist fest, anstatt von einem undokumentierten Standardwert auszugehen. Netzwerkausfälle und Abbrüche führen zur Ablehnung des Promises, während ein 404- oder 500-Fehler weiterhin eine Antwort erzeugt, die Ihr Code überprüfen muss. Dieses Verhalten entspricht dem übergeordneten Fetch-Standard.

Die größte Herausforderung bei der Migration sind Streams. „node-fetch“ stellt für Node.js lesbare Response-Inhalte bereit, während natives „Fetch“ der Web-Stream-Semantik folgt. Wenn bestehender Code direkt in stream.pipeline, passen Sie den Body an oder konvertieren Sie ihn und führen Sie Regressionstests für Backpressure, Abbruch und Fehlerweitergabe durch.

Axios ist eine starke Alternative zu Node.js-Fetch, wenn die Benutzerfreundlichkeit über Browser- und Servercode hinweg zentralisiert werden soll. Die Übergabe eines einfachen Objekts als Anfragedaten löst die JSON-Serialisierung und die entsprechende Inhaltsverarbeitung aus, und geparste Antwortdaten sind über response.data. Standardmäßig werden Statuscodes, die nicht im 2xx-Bereich liegen, als Fehler mit Serverdetails unter error.response.

Mit wiederverwendbaren Instanzen lassen sich Basis-URLs, Header, Zeitlimits und validateStatus. Interceptors sind integrierte Middleware für Authentifizierung, Tracing, Protokollierung, Aktualisierungsabläufe und die Umwandlung von Antworten. Das kann sich wiederholenden Wrapper-Code ersetzen, kann aber auch das Verhalten verbergen; testen Sie daher die Reihenfolge der Interceptors und die Fehlerpfade.

Wiederholungsversuche sind in den erfassten Nachweisen nicht Teil des Axios-Kerns. Fügen Sie diese über eine Erweiterung oder eine Anwendungsrichtlinie hinzu und überprüfen Sie die zulässigen Methoden. Das Proxy-Verhalten kann vom Protokoll, von Umgebungsvariablen, Adaptern oder benutzerdefinierten Agenten abhängen; testen Sie daher den genauen Bereitstellungspfad, anstatt davon auszugehen, dass eine Proxy-Option alle Fälle abdeckt.

Ein spezielles Axios-Proxy-Einrichtungshandbuch und ein Axios-Header-Leitfaden sind nützliche interne Folgemaßnahmen. Überprüfen Sie vor dem Commit außerdem die aktuelle Node.js-Mindestanforderung des Pakets, die Modul-Exporte, die Abbruch-API, das Stream-Verhalten und etwaige HTTP/2-Adapter.

„Got“ ist die am stärksten auf Node.js ausgerichtete Option in dieser Reihe von „node-fetch“-Alternativen. Sein Vorteil liegt in der Kontrolle: Separate Timeout-Phasen können DNS-Lookup, Verbindung, TLS-Aushandlung, das Senden der Anfrage, das erste Antwortbyte, Socket-Inaktivität oder den gesamten Lebenszyklus abdecken. Dadurch lässt sich die Fehler-Telemetrie besser nutzen als bei einem einzigen generischen Timeout.

Got stellt außerdem Hooks und Streaming-APIs bereit, die für Service-zu-Service-Integrationen geeignet sind. Die zugehörige Dokumentation beschreibt automatische Wiederholungsversuche mit Backoff, die Berücksichtigung von Retry-Aftersowie native HTTP/2-Unterstützung, doch müssen Standardwerte, zulässige Methoden und das aktuelle Transportverhalten für die installierte Hauptversion überprüft werden. Lassen Sie niemals zu, dass eine Standard-Wiederholungsrichtlinie eine zustandsändernde Anfrage ohne Idempotenzstrategie wiederholt.

Bei Scraping oder ausgehenden API-Gateways sollten Sie die Agentenkonfiguration, das Proxy-Routing, die Cookie-Jar-Integration, die Dekomprimierung und die Stream-Limits überprüfen. Die umfangreichere Optionspalette von Got kann benutzerdefinierte Infrastruktur überflüssig machen, erhöht jedoch die Verantwortung bei der Konfiguration. Bevorzugen Sie eine gemeinsam genutzte, geprüfte Instanz gegenüber einer unübersichtlichen Vielzahl von Optionen pro Aufruf.

Aktuelle Versionen werden üblicherweise als ESM-orientiert und ausschließlich für Node dokumentiert. Überprüfen Sie engines, Exporte, gebündelte Typen und den Wartungsstatus, bevor Sie sich für Got als CommonJS-Dienst oder für eine ältere Laufzeitumgebung entscheiden.

Ky liegt zwischen nativem Fetch und einem vollständigen Node.js-HTTP-Client. Es akzeptiert Eingaben im Fetch-Stil und bietet zusätzlich Methoden-Shortcuts, wiederverwendbare Instanzen, Hooks und Anfrageoptionen, die sich wiederholenden Code reduzieren. Das macht es attraktiv, wenn man die Fetch-Semantik schätzt, aber einen schlankeren Anwendungs-Wrapper wünscht.

Die aktuelle Dokumentation sollte hinsichtlich des genauen Timeouts, der Standardwerte für Wiederholungsversuche, der zulässigen Methoden und des Fehlerverhaltens überprüft werden. Die erfassten Informationen beschreiben Nicht-2xx-Antworten als Fehler und Wiederholungsversuche als standardmäßig integriert; beides kann das Verhalten beim Ersetzen von `node-fetch` verändern. Behalten Sie Ihre bestehenden Status-Branches bewusst bei, anstatt die Entscheidung einem bequemen Standardwert zu überlassen.

Ky delegiert wichtiges Transportverhalten an die zugrunde liegende Fetch-Implementierung. Proxy- oder Dispatcher-Konfiguration, Cookies, Web-Streams, FormData und HTTP/2 hängen daher teilweise von der Laufzeitumgebung ab. Der Download-Fortschritt wurde in einigen Releases dokumentiert, während die Unterstützung für den Upload-Fortschritt eingeschränkter ist; überprüfen Sie daher beides, bevor Sie eine Telemetrie darauf aufbauen.

Entscheiden Sie sich unter den „node-fetch“-Alternativen für Ky, wenn Fetch-Kompatibilität wichtiger ist als die Node-spezifische Transportsteuerung.

SuperAgent ist eine pragmatische Node-Fetch-Alternative für Teams, die eine flüssige API wie .get(), .set(), .send(), .field(), und .attach(). Seine Formular- und Datei-Helfer machen mehrteilige Workflows übersichtlich, während die integrierte Antwortanalyse und fortschrittsorientierte APIs den Code für Uploads oder Downloads vereinfachen können.

Der Nachteil ist die semantische Distanz zu „Fetch“. Fehlerbehandlung, Timeout-Konfiguration, Weiterleitungen, Abbruch und Zugriff auf den Body erfordern einen neuen Testplan statt eines einfachen Import-Wechsels. Die Quelle enthält widersprüchliche Angaben zu Hooks und der Unterstützung von „AbortController“. Behandeln Sie Plugins als Add-ons und prüfen Sie, ob die von Ihnen gewählte Version eine eigene Abbruchmethode verwendet, Signale akzeptiert oder einen Wrapper erfordert.

Überprüfen Sie ebenfalls das Wiederholungsverhalten und die zulässigen Methoden, bevor Sie diese Funktion aktivieren, und gehen Sie nicht davon aus, dass HTTP/2 standardmäßig integriert ist, solange keine aktuelle Dokumentation vorliegt. Überprüfen Sie in Node.js das Verhalten von Agent, Proxy, Cookie-Persistenz und Streams für Ihren konkreten Workflow.

SuperAgent eignet sich am besten, wenn seine verkettbaren Formen und Datei-APIs sinnvollen benutzerdefinierten Code ersetzen – nicht nur, weil die Syntax prägnant aussieht.

Eine sichere Migration beginnt damit, die bestehende Semantik zu dokumentieren und dann jeweils nur eine Ebene nach der anderen zu ändern. Wenn Sie auf natives Fetch umsteigen, besteht die kleinste Änderung unter Beibehaltung des Verhaltens möglicherweise darin, den Import zu entfernen und gleichzeitig die explizite JSON-Serialisierung, Statusprüfungen und die Abbruchfunktion beizubehalten.

// Before
import fetch from 'node-fetch';
await sendJson(fetch);

// After
await sendJson(globalThis.fetch);

async function sendJson(fetchImpl) {
  const controller = new AbortController();
  const timer = setTimeout(() => controller.abort(), 5_000);

  try {
    const response = await fetchImpl('https://api.example.com/jobs', {
      method: 'POST',
      headers: {'content-type': 'application/json'},
      body: JSON.stringify({status: 'queued'}),
      signal: controller.signal
    });

    if (!response.ok) throw new Error(`HTTP ${response.status}`);
    return await response.json();
  } finally {
    clearTimeout(timer);
  }
}

Bei der Umstellung auf Axios oder einen anderen Client, der Statusfehler auslöst, sollten Sie dessen Statusrichtlinie konfigurieren oder den umgebenden Kontrollfluss gezielt umschreiben. Lassen Sie nicht zu, dass ein 404-Fehler versehentlich aus einem behandelten Ergebnis in einen generischen Wiederholungsweg gelangt.

• Überprüfen Sie ESM- oder CommonJS-Importe sowie die minimal eingesetzte Node.js-Version.
• Vergleichen Sie die Serialisierung von JSON, URL-kodierten Daten, Blobs, Dateien und FormData.
• Behalten Sie die Behandlung von Nicht-2xx-Fehlern, Umleitungsmodi und -beschränkungen sowie Annahmen bezüglich absoluter URLs bei.
• Überprüfen Sie die Fehlerarten bei der Abbruchbehandlung und ob die Fristen den gesamten Lebenszyklus abdecken.
• Beachten Sie, dass ein bereits verarbeiteter Body ohne Klonen oder Puffern nicht zweimal gelesen werden kann.
• Konvertieren Sie Node-Streams und Web-Streams explizit und testen Sie anschließend den Gegendruck sowie Teilausfälle.
• Konfigurieren Sie Proxys, Agenten oder Dispatcher, Cookie-Jars, die Dekomprimierung und Begrenzungen der Antwortgröße neu.
• Fügen Sie Regressionstests für Uploads, große Downloads, Wiederholungsversuche, Schutz vor doppelten POST-Anfragen und die Bereinigung nach Abbrüchen hinzu.

Verwenden Sie diese Szenario-Standardeinstellungen, um die fünf „node-fetch“-Alternativen einzugrenzen:

• Moderner Dienst mit minimalen Abhängigkeiten: Beginnen Sie mit nativem Fetch.
• Ältere CommonJS-Anwendung: Behalten Sie vorübergehend „node-fetch v2“ bei oder wählen Sie einen Client, dessen aktueller CommonJS-Pfad und Node-Basis verifiziert sind.
• Gemeinsamer Browser- und Servercode: Prüfen Sie zunächst Axios, dann Ky, wenn die Kompatibilität mit Fetch wichtiger ist als Interceptoren.
• Node-Integration mit vielen Wiederholungsversuchen: Bewerten Sie „Got“ mit einer expliziten Idempotenzrichtlinie.
• Formulare, Anhänge und Upload-Fortschritt: Bewerten Sie „SuperAgent“ oder „Axios“ anhand des genauen Workflows.
• Proxy-basiertes Scraping: Treffen Sie Ihre Wahl anhand der Anforderungen an die Steuerung von Agenten oder Dispatchern, Cookies, Stream-Handling und Block-Management – nicht allein anhand der Request-Syntax.

Testen Sie zunächst natives „Fetch“ auf jeder Node.js-Version, die Sie tatsächlich unterstützen. Dies ist die klarste Grundlage für die Entscheidung, ob eine andere Abhängigkeit ihren Platz verdient.

Entscheiden Sie sich für Axios wegen der plattformübergreifenden Vorteile, für Got wegen der umfassenden Node.js-Kontrollmöglichkeiten, für Ky wegen der Fetch-ähnlichen Benutzerfreundlichkeit oder für SuperAgent wegen der verkettbaren Formular- und Datei-Workflows. Die beste Alternative zu Node Fetch ist diejenige, deren bewährte integrierte Funktionen sinnvollen benutzerdefinierten Code ersetzen und gleichzeitig Ihren Request-Vertrag beibehalten.

• Testen Sie zunächst das native „Fetch“, wenn jede eingesetzte Node.js-Version dies unterstützt und Sie lediglich ein explizites, standardkonformes HTTP-Verhalten benötigen.
• Entscheiden Sie sich für eine Bibliothek wegen bewährter Annehmlichkeiten, die benutzerdefinierten Code überflüssig machen, und nicht wegen der längsten Liste an Funktionen.
• Stellen Sie die JSON-Kodierung, die Behandlung von Nicht-2xx-Statussen, Zeitlimits, Abbrüche, Weiterleitungen und Wiederholungssemantik mithilfe von Regressionstests sicher.
• Behandeln Sie Proxys, Cookie-Speicher, Stream-Typen, Uploads und HTTP/2 als Transportaspekte, die möglicherweise Agenten, Adapter oder Plugins erfordern.
• Überprüfen Sie die aktuellen Paket-Metadaten und die offizielle Dokumentation, bevor Sie sich auf Modulformate, Node.js-Mindestanforderungen oder Standardwerte verlassen.

Ja, sofern es mit Ihrer unterstützten Laufzeitumgebung, Sicherheitsrichtlinie und Ihren Wartungserwartungen kompatibel bleibt. Fixieren Sie die Version, prüfen Sie die aktuellen Projektrichtlinien und stellen Sie sicher, dass das Verhalten der Anfragen durch Tests abgedeckt ist. Betrachten Sie dies als eine explizite Kompatibilitätsentscheidung und nicht als dauerhaften Standard. Planen Sie einen Ausstieg ein, falls ein zukünftiges Node.js-Upgrade, eine Abhängigkeitsrichtlinie oder ein nicht unterstütztes transitives Paket die weitere Nutzung zu kostspielig macht.

Die meisten serverseitigen Clients benötigen eine explizite Cookie-Verarbeitung oder eine Cookie-Jar-Integration. Native Fetch und „node-fetch“ verhalten sich nicht wie ein Browser-Cookie-Speicher. Andere Clients lassen sich möglicherweise in Jars, Agenten oder Plugins integrieren, und ein persistenter SuperAgent-Agent kann in einigen Versionen hilfreich sein. Überprüfen Sie das Verhalten in Bezug auf Domäne, Pfad, Ablauf, Weiterleitung und gleichzeitige Anfragen, bevor Sie sich auf die Sitzungspersistenz verlassen.

Nein, standardmäßig nicht. Ein POST-Aufruf, dessen Zeitlimit abgelaufen ist, könnte den Server bereits erreicht haben, auch wenn der Client nie eine Antwort erhalten hat. Wiederholen Sie den Versuch nur, wenn der Vorgang für eine Wiederholung ausgelegt ist – in der Regel mit einem Idempotenzschlüssel, einer serverseitigen Deduplizierungsregel oder einem sicheren anwendungsspezifischen Vertrag. Begrenzen Sie außerdem die Anzahl der Versuche und beachten Sie gegebenenfalls Backoff-Signale des Servers.

Der Body ändert sich typischerweise von einem Node.js Readable in einen WHATWG ReadableStream. Bestehende .pipe() oder stream.pipeline() Code muss daher möglicherweise angepasst werden, beispielsweise Readable.fromWeb() sofern unterstützt, oder eine Web-Stream-Pipeline. Testen Sie Rückdruck, Abbruchweitergabe, unvollständige Dateien, Dekomprimierung und Bereinigung, da erfolgreiche Tests mit kleinen Puffern Fehler beim Streaming in der Produktion möglicherweise nicht aufdecken.

Die richtige Wahl unter den „node-fetch“-Alternativen hängt davon ab, welches Verhalten Sie beibehalten möchten und welche Infrastruktur Sie nicht mehr warten wollen. „Native Fetch“ ist die sinnvolle Basis für unterstützte Laufzeiten, da es eine Abhängigkeit beseitigt und gleichzeitig die vertraute Fetch-Semantik beibehält. Axios bietet laufzeitübergreifende Transformationen und Interceptoren, Got legt den Schwerpunkt auf detaillierte Node.js-Steuerungsmöglichkeiten, Ky umhüllt Fetch mit praktischen Funktionen und SuperAgent macht Formular- und Datei-Workflows übersichtlich.

Bevor Sie wechseln, sollten Sie die Vertragsbedingungen für jede Anfrage erfassen. Überprüfen Sie Importe, JSON-Serialisierung, die Behandlung von Nicht-2xx-Antworten, Zeitlimits, Abbrüche, die Eignung für Wiederholungsversuche, Weiterleitungen, Cookie-Persistenz, Proxy-Routing, Uploads und Stream-Typen. Vergleichen Sie anschließend die aktuellen Paket-Anforderungen und Standardeinstellungen mit der genauen Hauptversion, die Sie installieren möchten.

Bei Scraping-Workloads ist der HTTP-Client möglicherweise nur eine Ebene des Problems. Wenn Blockierungen, CAPTCHAs und Proxy-Rotation mehr Aufwand verursachen als die Verarbeitung der Antworten, sollten Sie die Scraper-API von WebScrapingAPI in Betracht ziehen. Sie gibt rohes HTML zurück und übernimmt dabei die Bearbeitung dieser Anfrageebene. Behalten Sie die Parsing- und Geschäftslogik in Ihrer Anwendung bei und wählen Sie den Client, der diese verbleibenden Aufgaben am klarsten abgrenzt.