How Chenile implements policies at the gateway and the last mile

The five-part story

▸ 5. How Chenile helps

6. BDD testing

7. Messaging abstraction

8. Configuration (cconfig)

9. Registry & proxies

One abstraction, two homes

Chenile’s answer to the placement problem in part 4 is deliberately simple: there is only one kind of policy.

A policy is a Chenile interceptor. The very same interceptor contract runs in two places:

inside the auth gateway shipped in chenile-security, at the edge, and
inside every service’s interception pipeline, at the last mile.

You do not write a “gateway version” and a “service version” of authorization. You write the policy once, and you deploy it where it belongs.

The Chenile promise

Write a service policy once. Run it at the API gateway, at the last mile, or both — chosen by configuration in the service registry, not by rewriting code.

The registry decides placement

Every Chenile service has an entry in the service registry (chenile-service-registry). That entry is where operations are described and where policies are attached, through typed extension keys (part 3). Because placement and tuning are configuration, moving a policy from the last mile to the gateway — or adding it in both places for defence in depth — is a registry change, not a refactor.

gateway:                          last mile (per service):
┌──────────────────────────┐      ┌───────────────────────────────┐
│  Chenile auth gateway     │      │  Chenile interception pipeline │
│  ─ authenticate (policy)  │─────▶│  ─ authenticate? (trusted)     │
│  ─ rate-limit  (policy)   │      │  ─ authorize resource (policy) │
│  ─ coarse authz (policy)  │      │  ─ tenancy      (policy)       │
└──────────────────────────┘      │  ─ i18n / audit (policy)       │
        edge                       │  ─▶ S1ServiceImpl.op1()        │
                                   └───────────────────────────────┘
   same interceptor contract in both boxes

What Chenile gives you out of the box

The pieces that make this work are spread across the framework’s repositories, but they compose into one model:

chenile-core — the runtime substrate: the ChenileExchange model, the interceptor/orchestration pipeline, service and operation definitions, HTTP binding and state-machine support. This is the engine that runs policies at the last mile.
chenile-security — the contract-first auth framework: auth-server, gateway, and resource-server starters, plus the security-interceptor. This is how policies run at the edge, and how services trust the edge’s decisions.
chenile-service-registry — the registry that binds policies to operations and carries their configuration.
chenile-proxies — call other Chenile services through their interface, locally or remotely, without hand-written transport, so the same policy model spans in-process and cross-process calls.
chenile-messaging — extends the model beyond HTTP to pub/sub (MQTT, Kafka, Azure, in-JVM) and the cloud-edge switch, so policies apply to event-driven entry points too.

Because a policy is configuration-driven and orchestration-unaware, the same authorization interceptor can guard an HTTP request at the gateway, an internal proxy call at the last mile, and a message consumed from a queue.

Bringing the whole story together

The five moves, in one breath

1. We adopt microservices (or moduliths) for deployability, ownership and blast-radius control — and pay a hidden tax in duplicated plumbing. 2. So we split each service into a definition (api) that consumers depend on and an implementation (service) that nobody depends on. 3. The horizontal concerns become named policies — single-responsibility, configuration-driven interceptors — instead of inline code. 4. Policies must run in two places: the API gateway for early, coarse, high-leverage decisions, and the last mile for context-rich ones. 5. Chenile uses one interceptor abstraction for both, with the service registry choosing placement — so you write a policy once and govern every entry point consistently.

That is Chenile: business logic stays pure, governance stays consistent, and where each policy runs is a decision you make in configuration — not a rewrite.

Generate your first service → Watch the video series