Why We Built Mistcraft: A Library-First Approach to Infrastructure

Introduction

In the world of infrastructure as code, most tools follow a similar pattern: they're applications first, libraries second. At Evorine, we encountered the limitations of this approach firsthand, leading us to create Mistcraft—a tool that flips this paradigm on its head.

The Problem with Existing Tools

Traditional infrastructure management tools like Terraform and even Pulumi, despite their strengths, present significant challenges when you need to embed them into larger solutions:

• Process Isolation: Most tools require running as separate processes, adding complexity and overhead
• Application-Centric Design: They're built as standalone applications, making library usage an afterthought
• Limited Integration: API integration often feels like working against the tool rather than with it
• Thread Management Issues: Static dependencies and poor thread management make embedding difficult

The Library-First Approach

Mistcraft takes a fundamentally different approach. Instead of building an application and then exposing APIs, we built a library ecosystem where each component serves a specific purpose:

This modular architecture means teams can use exactly what they need. Want programmatic infrastructure management? Use Misting directly. Need to embed it into an application? No problem. Prefer declarative configs? Add Mistwrite. Need a CLI? Mistup has you covered.

Architectural Benefits

The library-first design provides several key advantages:

1. In-Process Execution

Run infrastructure management directly within your application. No subprocess spawning, no IPC overhead, no serialization boundaries. Your infrastructure code runs in the same process as your application logic.

// Direct library usage - no subprocess needed
use misting::deployment::Deployment;
use misting::state::FileSystemState;

let mut deployment = Deployment::new();
deployment.add_resource(my_resource);
deployment.apply().await?;

2. Flexible Event Loop Integration

Unlike tools with rigid execution models, Mistcraft integrates seamlessly with your application's event loop. Whether you're using Tokio, async-std, or any other runtime, Mistcraft adapts to your architecture rather than imposing its own.

3. True API-First Design

Every feature in Mistcraft is accessible through clean, well-documented APIs. The CLI is just another consumer of these APIs, not a special case with privileged access to functionality.

Wait! You're thinking about consuming the CLI? Don't worry, it's not a special case. Even the CLI is just available as a library.

4. Customization Without Forking

Need custom behavior? Implement a trait. Want to add a provider? Use the provider SDK. The extension points are designed into the architecture, not bolted on as an afterthought.

The Story Behind Mistcraft

Our Promise

Mistcraft delivers on a clear set of promises that address the pain points we experienced:

Conclusion: Best of All Worlds

Mistcraft represents a fundamental rethink of how infrastructure management tools should be built. By putting the library first, we've created a tool that's equally comfortable being:

• A programmatic infrastructure management library (like Pulumi's Automation API, but better)
• A declarative configuration tool (like Terraform, but type-safe)
• An embedded component in a larger system (unlike anything else)

Teams with specific needs can use only the parts they require and customize them easily. No more fighting with tools that weren't designed for your use case. No more subprocess gymnastics or API limitations.