Take over an existing API
Take over an existing API, without rewriting it all.
Your current gateway carries hundreds of routes. Flexway imports its configuration, says what does not carry over, and serves from your OpenAPI contract: migration goes route by route, the old gateway alongside.
The path
- ImportThe existing configuration becomes a flexway.yaml and an annotated contract, with a report of what does not carry over
- Validateflexway validate offline, in CI, before any traffic
- Serve alongsideFlexway and the old gateway in parallel; routes switch one by one
- ObserveSame traces, readable refusals in the console
What is not declared in the contract is not served: the import often reveals routes the old gateway exposed without anyone knowing. A free audit of the surface actually exposed.
Configuration
The replace-gateway example, as it ships with Flexway v1.6.3.
# What a team replacing its gateway usually needs on day one (1.0.0): anonymous
# users behind a BFF counted apart, a bucket per operation as most gateways count, errors typed under
# its own portal with field codes in its own words, the body left to the service, tokens of an old
# and a new audience accepted while the audience is renamed.
version: 1
contracts:
openapi: ./openapi.yaml
upstreams:
default:
url: http://shop.internal:8080
hosts:
api.example.com: { default_upstream: default, validation: params } # the services validate their bodies
server:
trusted_proxies: [local] # the mesh proxy: the pod's own addresses (not the loopback)
peer_identity_header: l5d-client-id # the mTLS identity that proxy verified
errors:
type_base: https://docs.example.com/errors/ # type = https://docs.example.com/errors/<code>
field_codes: { minLength: too_short, maxLength: too_long, minimum: out_of_range, maximum: out_of_range }
auth:
issuers:
- name: customers
discovery: https://login.example.com/.well-known/openid-configuration
audiences: [shop-api, api] # the old name and the new, during the rename
policies:
definitions:
per-user:
type: rate-limit
config:
key: header # anonymous: X-Client-Key, if the BFF set it
header: X-Client-Key
trusted: [web-bff.web.serviceaccount.identity.linkerd.cluster.local]
scope: operation # a bucket per operation and user, not one per class
classes:
read: { rps: 20, burst: 40 }
write: { rps: 5, burst: 10 }
chains:
global: [per-user]Features
What is delivered in the published release v1.6.3, and what is coming; a feature is never shown as delivered before its release.
| Feature | Status |
|---|---|
| Import of an existing gateway's configuration, with a coverage report | Delivered · v1.1.0 |
| An OpenAPI 3.1 contract loaded; what is served is derived from it | Delivered · v0.1.0 |
| flexway validate offline, output usable in CI | Delivered · v0.1.0 |
| Start refused when a declared operation has no upstream | Delivered · v0.1.0 |
| An invalid configuration never replaces the running one | Delivered · v0.1.0 |
| Live reload through an immutable snapshot, no request lost | Delivered · v0.1.0 |
| JWT validation, cached JWKS keys with rotation | Delivered · v0.1.0 |
Going further
- Open this template in the editorYour architecture, its flexway.yaml and its simulated decisions, in the browser.
- The guideStep by step, in the documentation of the published release
- APIREST, gRPC, SSE, WebSocket, from the contract
- SecurityOIDC, API keys, mTLS, closed by default
- OperationsOpenTelemetry, console, proposals as PRs
Let's talk about your gateway
Flexwiz is a young company: you talk directly with the person who founds it. Tell us what you want to run through Flexway. We talk about your infrastructure and your digital sovereignty requirements.
Online booking is coming soon; until then, an e-mail is enough.