Separate what a service does from how it is governed.
Chenile lets you write plain-Java services that hold nothing but business logic — then apply security, logging, tenancy, i18n and retries as reusable service policies, consistently at the API gateway and the last mile.
* Figures marked as placeholders are illustrative — replace with your own measured numbers.
The Chenile story
The website and the video series both follow the same arc — from a plain question about microservices to a concrete way of governing them.
Why microservices?
What we actually want from microservices — independent deployability, clear ownership, blast-radius control — and the tax we pay when every team re-implements the same plumbing.
Read part 1 →Separate service definition from implementation
A service is a contract, not a codebase. Chenile puts the interface and model in an api module that consumers depend on, and the logic in a service module nobody depends on. That's the Dependency Inversion Principle, made physical.
Service policies are part of the division
Authentication, authorization, logging, i18n, multi-tenancy, retries — these are horizontal requirements that cut across every service. They belong to the definition side, not tangled into business code. Chenile expresses each as a single-responsibility interceptor.
Read part 3 →Where do policies live? Gateway and last mile
Some policies belong at the edge — the API gateway — where you terminate auth and shed load early. Others must run at the last mile, right next to the service, where the business context lives. Most real systems need both.
Read part 4 →How Chenile implements policies in both places
The same interceptor abstraction runs in Chenile's gateway and inside each service's interception pipeline. Write a policy once; deploy it at the edge, at the last mile, or both — driven by service-registry configuration, not by rewriting code.
Read part 5 →Test once, run everywhere: BDD across unit & integration
The same idea, applied to testing. One Gherkin .feature file runs as a fast in-process unit test over Spring MockMvc and as a full integration test over REST Assured. Write the behaviour once; swap the glue, not the spec.
Messaging: one interface, many transports
The same move, applied to events. Services depend on the chenile-pub-sub interface while MQTT, Kafka, Azure and in-JVM are swappable implementations — and every message runs the same interception pipeline as an HTTP call, so your policies just work.
Configuration management with cconfig
Every module owns a JSON config that can be overridden at runtime — down to a nested path — and resolved per tenant via a custom attribute. Sources (properties, JSON, env, database) are pluggable behind one CconfigClient.
Service registry & proxies — with client-side interception
Chenile ships its own service registry and a proxy framework: call another service through its interface, routed locally or remotely without code changes, while a configurable client-side interceptor chain handles headers, auth, retries and responses on the way out.
Read part 9 →Business logic in one module. Everything else, out.
✅ s1-api — the definition
What consumers depend on. Pure contract.
- The service interface (
S1Service) - The model objects
- No implementation, no transport, no Spring
- Packaged as a library — never deployed alone
⚙️ s1-service — the implementation
What nobody depends on. Swappable.
- A plain POJO implementing the interface
- A health checker for deep readiness probes
- Wired through a Chenile controller
- Horizontal concerns handled by policies, not code
// The whole service. Business logic and nothing else —
// no auth, no logging, no tenancy checks tangled in here.
public class S1ServiceImpl implements S1Service {
@Override
public S1Entity op1(S1Entity s1Entity) {
s1Entity.id = "S1ServiceImpl";
return s1Entity; // policies run around this, not inside it
}
}One policy model — the gateway and the last mile
Chenile's interceptor abstraction is the same whether it runs at the edge or beside the service. The service registry decides where each policy applies.
At the API gateway
Terminate authentication, coarse authorization, rate-limiting and request normalization at the edge — so bad traffic never reaches your services. Chenile ships an auth gateway and resource-server starters in chenile-security.
At the last mile
Fine-grained authorization, multi-tenancy, i18n, idempotency and business-aware logging run inside each service's interception pipeline — where the domain context actually exists. Same interceptor contract, different deployment.
One Gherkin spec. A unit test and an integration test.
Chenile ships the same step vocabulary in two libraries — so a single .feature file runs in-process over Spring MockMvc and against a live server over REST Assured.
Unit / component — cucumber-utils
Spring MockMvc stands the service up in an ephemeral in-process instance and drives it from the outside. Because the request passes through the real Chenile pipeline, it exercises the service and its interceptors — governance is under test. Fast enough for every build.
Integration — it-cucumber-utils · chenile-bdd
The identical scenarios run over REST Assured against a really deployed server, verifying the wire, packaging, config and environment. it-cucumber-sec-utils does the same for secured endpoints. Same spec, run against staging.
The 11 Chenile repositories
Versioned together under chenile-parent and currently aligned on v2.1.29.
chenile-parent
Build baseline
Shared Maven super-parent and dependency-management BOM. Standardizes Java, Spring Boot, plugin and Chenile artifact versions for every sibling repo.
chenile-core
Core runtime
The execution engine: ChenileExchange model, the interceptor pipeline, service/operation definitions, HTTP binding, state-machine (STM) support and MCP support.
chenile-query-workflow-blueprints
Application blueprints
Reusable query and workflow patterns on top of core — metadata-driven queries (MyBatis) and workflow-enabled services built on Chenile STM.
chenile-process-management
Application blueprints
Orchestration for long-running parent and child processes with sub-process tracking and pluggable process starters.
chenile-service-registry
Integration
Registry of services and delegates that lets Chenile discover and resolve service interactions and their policy configuration.
chenile-proxies
Integration
Proxy framework for invoking Chenile services through interfaces rather than hand-written transport code — local and remote.
chenile-security
Integration
Security support including the contract-first auth framework: auth-server, gateway and resource-server starters, plus the security interceptor.
chenile-messaging
Integration
Messaging and pub-sub integrations: MQTT, Kafka, Azure, in-JVM pub-sub and the cloud-edge switch.
chenile-bdd
Testing
Integration-test and BDD support — Cucumber utilities for services and security so behavior is verified end to end.
chenile-others
Auxiliary
Supporting entry points and integrations: file-watch, a Kubernetes-aware scheduler, cache, and the config maven plugin.
cconfig
Configuration
Modular runtime configuration storage and overrides that the rest of the stack can consume.
Loved by the engineers who maintain it
↓ Placeholder testimonials — swap in real, attributable quotes before publishing.
We deleted three internal 'framework' libraries after adopting Chenile. Our services now contain business logic and almost nothing else.
The split between the api module and the service module finally made our dependency graph honest. New engineers understand a service in minutes.
We moved authentication to the gateway and kept fine-grained authorization at the last mile — same policy code, two places. That used to be a quarter of work.
Chenile's interceptor model gave us a single, testable place for multi-tenancy. BDD tests came almost for free.
Generate your first Chenile service in minutes
Scaffold an api + service pair, get a deployable monolith, and start attaching policies.