Generated SDK Structure

When you run axiom pull, Axiom generates a Thin Layer of typed code. This code represents the "Interface" of your contract but contains zero network or business logic.

Generated Files

By default, Axiom generates two primary files in your lib/axiom_generated/ directory:

1. models.dart (The DTO Layer)

This file contains all Pydantic or SQLAlchemy models discovered in your backend, converted into immutable Dart classes.

• Plain Data Classes: Includes final fields and constant constructors.
• Serialization: Includes optimized fromJson and toJson methods.
• Type Fidelity: Complex Python types like Union, Optional, and Enums are mapped to their closest Dart equivalents.

2. axiom_sdk.dart (The Interface)

This is your primary entry point for communicating with the backend.

• The SDK Class: Manages the initialization and lifecycle of the underlying Rust Runtime.
• Typed Methods: Every FastAPI route is exposed as a typed method. For example, a Python function def get_user(id: int) becomes a Dart method Future<User> getUser({required int id}).
• No Network Logic: The SDK methods simply pass arguments to the native runtime. The Rust engine handles the actual transport, retries, and caching.

---

🚀 Coming Soon: Multi-Contract Support

We are preparing a major update to the axiom_sdk.dart structure to accommodate complex microservice architectures.

The Problem: Currently, the SDK uses a unified namespace. If you pull from two different backend services that both have a login method, a naming collision occurs.

The Solution: Axiom will soon introduce Scoped SDK Instances. Instead of a single global SDK, you will be able to instantiate multiple instances (e.g., BillingApi, AuthApi) allowing you to consume multiple .axiom contracts within the same project without naming conflicts.

---