The Chenile story
The website and the YouTube series share one narrative arc. Read it end to end, or jump to any chapter.
Why microservices — and what they really cost
What we actually want from microservices, and the recurring tax every team pays when the same plumbing is rebuilt service by service.
Read part 1 →Separate the service definition from the implementation
A service is a contract, not a codebase. Chenile splits the interface and model into an api module that consumers depend on, and the logic into a service module that nobody depends on.
Read part 2 →Service policies: the other half of the division
Horizontal requirements — security, logging, tenancy, i18n, retries — are not business logic. Chenile names each one a policy and implements it as a single-responsibility interceptor.
Read part 3 →Where policies live: the API gateway and the last mile
Some policies belong at the edge; others must run beside the service. Most real systems need both — and choosing well is an architectural decision, not a framework limitation.
Read part 4 →How Chenile implements policies at the gateway and the last mile
One interceptor abstraction, two deployment sites. Write a policy once; the service registry decides whether it runs at the edge, at the last mile, or both.
Read part 5 →Test once, run everywhere: BDD across unit and integration
Chenile ships a Gherkin vocabulary implemented twice — over Spring MockMvc for in-process unit tests and over REST Assured for integration tests. The same .feature file drives both.
Read part 6 →Messaging: one interface, many transports
chenile-messaging applies the same discipline to events. Services depend on a small messaging interface; MQTT, Kafka, Azure and in-JVM are swappable implementations behind it — and every message runs the same pipeline as an HTTP call.
Read part 7 →Configuration management with cconfig
cconfig gives every module its own JSON configuration, lets any value — or a nested path inside it — be overridden at runtime, and resolves the effective config per tenant. Sources are pluggable behind one client.
Read part 8 →Service registry & proxies: calling services through their interface
Chenile ships its own service registry and a proxy framework. Call another service through its Java interface — Chenile routes the call locally or remotely and runs a client-side interceptor chain on the way out.
Read part 9 →