Leistung und Skala
Überblick
Leistung ist ein Feature mit einem Budget. Messen Sie es, begrenzen Sie es, und respektieren Sie, dass heutiges Verhalten zu morgigen Verträgen wird. Systeme breiten selten unter dem Durchsatz zusammen, für den Sie ausgelegt haben – sie brechen an der Abfrage, die Sie nicht indiziert haben, und an der Liste, die Sie nicht paginiert haben.
Die Prinzipien
- Budgets setzen und dagegen messen. Latenzziele (gebunden an die SLOs von
observability-and-slos) und Client-Budgets (z.B. Bundle-Größe). Eine Regression über das Budget hinaus ist ein Fehler. - Messen, bevor Sie optimieren. Finden Sie den wahren Engpass mit Daten – Profile, Abfragepläne, Traces – bevor Sie Code ändern. Keine spekulative Optimierung.
- Standardmäßig paginieren. Jede Liste, die wachsen kann, wird mit einer begrenzten Seitengröße paginiert. Unbegrenzte Ergebnismengen sind ein Latenz- und Denial-of-Service-Risiko.
- Hüten Sie sich vor N+1-Zugriffsmustern. Daten, die in einer Schleife abgerufen werden, sind der häufigste Skalierungsfehler; verwenden Sie stattdessen Batch oder Join. (In diesem Stack: Verwenden Sie die Look-Ahead/DataLoader-Schicht von GraphQL anstatt Auflösung pro Zeile.)
- Hyrum's Law ist real: Jedes beobachtbare Verhalten einer Schnittstelle wird zu einem Vertrag, von dem jemand abhängt, sobald es genügend Konsumenten gibt – einschließlich Verhaltensweisen, die Sie nie beabsichtigt haben (Reihenfolge, Nullsetzbarkeit, Fehlerformen, Timing). Behandeln Sie öffentliche Schnittstellen (insbesondere die API/das Schema) als Verträge: Hinzufügen und als veraltet markieren, nicht stillschweigend ändern. Die Vertragstests von
graphql-contract-testingfixieren die von Ihnen gewählten Verhaltensweisen; Disziplin schützt die, die Sie nicht gewählt haben.
Kurzreferenz
| Geruch | Behebung |
|---|---|
| Abfrage innerhalb einer Schleife | Batch oder Join; Look-Ahead verwenden |
| List-Endpunkt ohne Limit | Begrenzte Paginierung hinzufügen |
| „Lass mich optimieren“ ohne Messung | Zuerst profilieren; den wahren Engpass finden |
| Typ/Nullsetzbarkeit/Reihenfolge eines Felds ändern | Es ist eine Vertragsänderung – neu hinzufügen, altes als veraltet markieren |
| Kein Latenz- oder Bundle-Ziel | Budget setzen; Regressionen als Fehler behandeln |
Durchsetzung: Budgets werden in CI geprüft, wo automatisierbar (Bundle-Größen-Limits, Abfragekosten-Limits); Paginierung und N+1-Vermeidung liegen im Ermessen des Reviewers, unterstützt durch Lasttests und Abfrageplan-Reviews.
Vollständige Begründung: Artikel XI der Verfassung, gebündelt unter engineering-constitution/references/engineering-constitution.md.