I've been evaluating Recraft for generating consistent assets across a microservices project, and the new 'brand book' feature is a significant step forward. It effectively acts as a centralized style configuration—think of it as a single source of truth for your visual schema. The ability to lock in primary colors, typefaces, and logo variations is excellent for maintaining consistency, which is a major pain point in distributed teams.
However, from a backend and automation perspective, the customization feels a bit shallow. The API seems to treat the brand book more as a read-only reference rather than a dynamic, programmable template system.
My main critiques:
* **Limited Template Variables:** You can't define custom, structured template fields (e.g., `{{product_code}}`, `{{event_date}}`) that can be injected via API. This forces post-processing logic outside of Recraft, adding latency.
* **Granularity in Export Rules:** I should be able to define export presets (e.g., "for web," "for print") at the brand book level, specifying format, dimensions, and color profile per asset type, not just globally.
* **Conditional Logic in Styles:** It lacks simple conditional rules. For instance, "If the background is dark, use light text variant X; if light, use dark variant Y." This logic is currently pushed into application code.
A more programmable approach would be akin to a configuration file:
```yaml
brand_book:
styles:
primary_color: "#0033A0"
templates:
hero_banner:
dimensions: [1200, 630]
style_rules:
- if: "context.audience == 'professional'"
then: { typography: "font_serif", color_scheme: "dark" }
- else: { typography: "font_sans", color_scheme: "light" }
export_presets:
web: { format: "webp", quality: 80 }
print: { format: "pdf", dpi: 300 }
```
This level of declarative control would allow developers to integrate it seamlessly into CI/CD pipelines for asset generation. The current implementation is a great v1, but to truly scale, it needs to move from a style guide to a **style engine**.
-- latency
sub-100ms or bust
You're hitting on the classic vendor bait-and-switch. They sell you a "single source of truth" but it's only true inside their walled garden. The API being read-only is the tell.
Your wishlist for templates and logic sounds like you actually need a real template engine, not a brand book. You'll end up with the "post-processing logic" you mentioned becoming your real source of truth, and Recraft just becomes an expensive renderer. At that point, why not just use Inkscape or a scripted imagemagick setup?
Your vendor is not your friend.
Exactly - the "walled garden" issue is spot on. I've seen this pattern with so many "centralized" tools. They create a tight loop that's convenient at first, but then your actual automation logic ends up living outside their system.
You mentioned Inkscape or imagemagick, and that's a valid route, but then you lose the whole "generative" aspect. The real missed opportunity is that a brand book *could* be a perfect structured data source for programmatic asset generation. Imagine if the API let you push a JSON payload with your template variables and it returned an asset following the locked-in rules.
For now, you're right, it's a read-only style guide. The generative part is still manual inside their UI.
Your point about API-driven template variables is spot on. That's where the true backend efficiency gain would be. It shifts the system from a static reference to a live asset generation engine.
The latency you mentioned is the hidden cost. Every external post-processing step introduces another network hop and potential failure point. If the brand book API allowed you to POST a JSON payload with your `event_date` and `product_code`, the entire asset pipeline could be a single, cacheable request.
I've had to build similar logic on top of other "single source of truth" services, and you end up with a fragmented system. The brand book holds the styles, your application holds the logic and data, and you're stitching them together at runtime. It defeats the purpose of a centralized system.
This is a common pattern where the API is an afterthought to the UI. They've built a great config interface but neglected the programmatic control needed for automation. For microservices, that's a deal-breaker.
sub-100ms or bust
Ah, the "centralized style configuration." Let's be honest, a color palette and font list in a database isn't a technological marvel, it's a lookup table. The real test is whether it *does* anything.
Your critiques are spot on, and they point to the real issue: this is a style guide, not an engine. The lack of conditional logic is the dead giveaway. A real programmable system would let you define rules like, "If the asset type is 'event,' use this secondary palette; if for 'product,' use the primary one." Without that, you're just handing a PDF to your devs with extra steps.
I'd add that calling it a "single source of truth" is premature. For it to be the source, it actually has to be the thing that generates the final output. Right now, it's just a source of *constraints*, while the "truth" of the final asset still lives in your glue code. So we have two sources of truth, which, as we all know, is just a lie.
cg
"Single source of truth" is a compliance term, not a marketing one. The moment you have to add "post-processing logic outside of Recraft," it stops being that source. Your point about export rules is good, but the API being read-only is the foundational flaw. Can you even audit who changed a hex code last Tuesday, and through which deployment pipeline it propagated? Without that, it's just a pretty configuration file, not an engine.
- Nina