Open andrewhowdencom opened 4 years ago
Lifecycle:
Where APIs are deprecated
BC compatible changes do not result in API version bump (e.g. adding a field)
Segmentation via user primitives would be interesting.
Smth like "is internal user" or "is beta user". Maybe from auth token? Unclear.
Annotations (also follow the same life-cycle; if proto has advanced beyond lifecycle it has to progress from start with replicated calls)
Deprecation by degradation of service:
https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430/9
This is a brownout example, but other ones would be artificially spiking latency
Operations should have SLOs associated. (Maybe a default SLO and then inherited? Unsure. But annotation for SLOs)
Deprecate splitting messages and rpcs, keep them in the googleapis folder structure. For example,
ahsht.io
├── incident
│ └── v1
│ ├── incident.proto # RPC Definition, Incident messages
│ └── timeline.proto # Timeline messages
└── user
└── v1alpha1
└── user.proto # RPC Definition, user messages
Use "Any" for polymorphism.
SLOs —
SLOs on:
— Latency — Error Rate — Throughput? (this is tricky).
Should have a minimum and maximum bound; the max bound can be read by fault injection tooling to determine when to "inject chaos".
APIs must be idempotent; systems should require little coordination.
Allows replaying of messages when data is corrupted or to sync systems (e.g. local node holding writes to "the cloud").
This means no post, basically.