flexway
FRENTalk to an expert

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

  1. ImportThe existing configuration becomes a flexway.yaml and an annotated contract, with a report of what does not carry over
  2. Validateflexway validate offline, in CI, before any traffic
  3. Serve alongsideFlexway and the old gateway in parallel; routes switch one by one
  4. 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.

Open this template in the editor

Configuration

The replace-gateway example, as it ships with Flexway v1.6.3.

examples/replace-gateway/flexway.yaml
# 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.

FeatureStatus
Import of an existing gateway's configuration, with a coverage reportDelivered · v1.1.0
An OpenAPI 3.1 contract loaded; what is served is derived from itDelivered · v0.1.0
flexway validate offline, output usable in CIDelivered · v0.1.0
Start refused when a declared operation has no upstreamDelivered · v0.1.0
An invalid configuration never replaces the running oneDelivered · v0.1.0
Live reload through an immutable snapshot, no request lostDelivered · v0.1.0
JWT validation, cached JWKS keys with rotationDelivered · v0.1.0

Going further

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.