Heute vor 3 Monaten hatten wir das erste WarEraProjects/API-Client-Release! 🥳

Hier ist eine kurze Geschichte des Projekts!

v0.1.0 💚 - Erstes Projekt-Release

Das war der erste Commit, der den notwendigen Code enthielt, um mit api2.warera.io zu kommunizieren, einen Rate Limiter, sowie die Verarbeitung von Eingabe- und Antworttypen ermöglichte.

v0.1.1 🔍 - ReadMe

Verbesserte ReadMe.md-Dokumentation.

v0.1.2 📚 - Auto-Pagination

Das war das erste große Update des Projekts.
Die Auto-Pagination ermöglicht es Entwicklern, schnell durch „Pages“ zu iterieren, wenn ein Endpoint mit einem cursor aufgerufen wird.

Mit der neuen Loop-Strategie konnte man eingehende Daten sofort verwenden, während die nächsten Daten bereits geladen wurden.
Ab diesem Punkt verbesserte sich das Abrufen von Daten drastisch, da Fetches gestartet werden konnten, ohne darauf warten zu müssen, dass sie vollständig aufgelöst wurden.

v0.1.3 ❌ - Optionen reduzieren

Das Ziel des Packages ist es, weniger Arbeit zu verursachen, was bedeutet, dass auch die Konfiguration geringer sein sollte.
Dieses Update machte Optionen optional und ersetzte erwartete Werte durch Standardwerte.
Zu diesem Zeitpunkt musste man nur noch einen API-Key bereitstellen, um loszulegen.

v0.1.4 🚨 - Eingabeparameter reduzieren

In einigen Fällen funktionierte der Client nicht, wenn kein leeres Objekt übergeben wurde.
Dies wurde behoben.

v0.1.5 🍵 - „Buy me a Coffee“-Button hinzugefügt

Dieser Button wurde nie benutzt. Es ist, wie es ist.

v0.2.0 📲 - GET zu POST geändert

Dieses Update verbesserte die Kommunikationsgeschwindigkeit mit dem Server drastisch.
Anstatt eine lange GET-Anfrage an den Server zu senden, kann nun eine kleinere URL mit einem größeren Payload gesendet werden.
Der Client prüft, ob die URL 16000 Zeichen überschreitet, bevor sie in verschiedene Requests aufgeteilt wird. Die Antworten werden später kombiniert und als ein Objekt zurückgegeben.
Benchmark-Tests wurden hinzugefügt.
Der Client erhielt einen Batch-Logger, der es Entwicklern ermöglicht, Batch-Requests zu debuggen.

v0.2.1 💻 - Für das Frontend lauffähig gemacht

Die Anwendung verwendete eine Dependency, die nur auf einem Server ausgeführt werden konnte.
Funktionsnamen wurden für eine einfachere Nutzung aktualisiert.
Benchmark aktualisiert: Anstatt auf den Abschluss eines Promise zu warten, wird die Schleife fortgesetzt.

v0.2.2 🤖 - Fehlende Response-Typen und Endpoints aktualisiert

Fehlende Endpoints wurden hinzugefügt.
Ein Standard für zukünftige fehlende Endpoints wurde erstellt.

v0.3.0 ⚠️ - Fallbacks & neue Endpoint-Updates

Retry-Fallback-Support für gebatchte tRPC-Requests wurde hinzugefügt, einschließlich konfigurierbarem Retry-Verhalten für abgebrochene Verbindungen und temporäre HTTP-Fehler. Die Endpoint-Abdeckung wurde über generierte API-Typen, Fallback-Collection-Workflows und benutzerdefinierte Endpoint-Typisierungen erweitert. Hinzugefügt wurde Support für Item Offers, User Lookup, Battle Orders/Loot Summaries, Inventory Equipment, Mercenary Auctions, Donations, Elections, MU Members, Trading Orders, Work Stats, Wage Stats, Party Pagination und Company Production Bonuses.

v0.3.1 🏃‍♂️‍➡️ - Batch-Limit eingeführt

Der Server hat ein neues Batch-Limit eingeführt, bei dem maximal 50 Requests pro Batch erlaubt sind.
Dieser Patch behebt dieses Problem.

v0.3.2 ⚔️ - Tournament-Endpoints hinzugefügt.

Was kommt als Nächstes?

Zu Beginn dieser Woche habe ich nach Vorschlägen gefragt. Es gab einige gute Vorschläge, daher ist hier der Plan:

• Alternative Rate-Limit-Setups

• Abbrechen von Requests ermöglichen

• Integration mit dem Gateway für Caching

• Verwaltung eines Client-Singletons, der überall im Projekt verwendet werden kann

• Dokumentation für die öffentliche Nutzung generieren

• Dem Client ermöglichen, basierend auf der Serververfügbarkeit einen Statuscode zurückzugeben

• Schneller Fetching-Algorithmus für cursorbasierte Endpoints

Schau dir das Projekt gerne selbst an!

GitHub - NPM

Schreib mir auf Discord

Ich vermisse meine deutsche Familie :isforme: