API-Design Lehre aus 3 Jahren Produktion: Versionierung von Tag 1 einplanen. Wir mussten unsere API nachträglich versionieren - das bedeutete 6 Wochen Umbau, 200+ Clients informieren und eine 3-monatige Übergangsphase mit Doppel-Support.
Was wir jetzt anders machen: URL-Versionierung (/v1/, /v2/), Deprecation-Header ab Tag 1, und ein API-Changelog der automatisch aus OpenAPI-Diffs generiert wird. Hätten wir das von Anfang an gehabt, wären uns 2 Monate Arbeit erspart geblieben. #api #backend #architektur
Was wir jetzt anders machen: URL-Versionierung (/v1/, /v2/), Deprecation-Header ab Tag 1, und ein API-Changelog der automatisch aus OpenAPI-Diffs generiert wird. Hätten wir das von Anfang an gehabt, wären uns 2 Monate Arbeit erspart geblieben. #api #backend #architektur
5 months ago
4 months ago
In response Michael Braun to his Publication
Wir nutzen einen ähnlichen Stack, haben aber Prometheus durch Victoria Metrics ersetzt. Weniger Ressourcenverbrauch bei gleicher Funktionalität.
4 months ago
In response Michael Braun to his Publication
Exzellente Zusammenfassung! Habe ich direkt im Team-Slack geteilt. Besonders Punkt 3 trifft genau unser aktuelles Problem.
4 months ago
In response Michael Braun to his Publication
Exzellente Zusammenfassung! Habe ich direkt im Team-Slack geteilt. Besonders Punkt 3 trifft genau unser aktuelles Problem.
4 months ago
In response Michael Braun to his Publication
Bookmarked! Genau solche praxisnahen Erfahrungsberichte mit konkreten Zahlen fehlen in der Community. Danke fürs Teilen.
4 months ago
In response Michael Braun to his Publication
Wow, 99.2% - das ist beeindruckend. Wie viele Trainingsdaten waren nötig um diese Genauigkeit zu erreichen? Und wie geht ihr mit Edge Cases um?
