Chitra AI Image Generation

Context

A prompt goes in, an image comes back, and it lands in a history only its owner can read. The provider key sits on the server and is never handed to the browser, which is the whole reason there is a backend here at all.

Challenge

Every generation on the live site came back a blue-to-green gradient. Instant, 7.3 KB, and completely wrong. The front end was rendering exactly what the API returned, and the API was doing exactly what it was configured to do.

Non-negotiables

• The provider credential never reaches the browser
• A provider outage returns a usable error, not a stack trace
• Generated images are readable only by their owner

Calls I made

1. 01

   Providers behind one interface

   The real provider and a deterministic stub that paints a gradient implement the same interface, so tests and local development never spend credits. The cost of that convenience is that a misconfigured environment produces a working application that is quietly wrong, rather than one that fails loudly.

2. 02

   Provider errors become safe API responses

   A dedicated exception handler maps provider failures onto sanitised responses. A rate limit or a model timeout reaches the user as something they can act on, and nothing about the upstream call leaks out.

3. 03

   Storage behind a swappable interface

   Images are on the filesystem, reached through an interface rather than directly. Moving to object storage is an implementation swap rather than a rewrite, and nothing above the interface knows where a file physically lives.

Trade-offs accepted

• The bootstrap script writes a starter environment file with the provider set to `stub` and defers the switch to a manual post-install step. The deploy script never touches that file, so no amount of pushing to master could have corrected it. The abstraction that made the stub cheap is what let it reach production and stay there.
• Generation is synchronous. It is honest about how long it takes and simple to reason about, but a long-running request is holding a worker the whole time, and that is the thing that would break first under concurrent load.