# SRE Core Architecture

The Smyth Runtime Environment (SRE) is designed with a philosophy inspired by operating system kernels. This approach establishes a clean separation between the core runtime services and the pluggable Connectors that interface with external services and infrastructure. This modularity is the key to Sre's flexibility and scalability.

## The SRE Lifecycle

The SRE is a singleton that gets initialized via the `SRE.init()` static method. This is the main entry point to the entire environment and is responsible for bootstrapping all configured subsystems based on the provided configuration.

Once initialized, the `sre.ready()` method must be called. This method asynchronously initializes all the specific connectors that were configured for each subsystem, ensuring they are connected and operational before any services are requested.

### Initialization Sequence

1. `SRE.init(config)`: The configuration object is parsed, and each subsystem (like `Cache`, `Storage`, `Log`) is mapped to a specific connector implementation.
2. `sre.ready()`: The SRE iterates through the configured subsystems and calls the `init()` method on each assigned connector. This is often an `async` operation, as it may involve establishing network connections or authenticating with external services.
3. Operational State: Once `sre.ready()` resolves, the SRE is fully operational and its services can be safely accessed.

The full initialization process is managed within the main `SRE` class.

> For the source code, see `packages/core/src/Core/sre.class.ts`.

## The Connector Model

The power of SRE's architecture lies in its connector model. Every external service, whether it's a database, a cache, a file system, or an LLM provider, is accessed through a `Connector`.

A connector is a class that implements a standardized interface for a specific type of service. For example, the `IStorageConnector` interface defines a set of methods (`write`, `read`, `delete`, `list`, etc.) that any storage connector must implement.

### How it Works

1. Interface Definition: A common interface is defined for a service type (e.g., `IStorageConnector`).
2. Concrete Implementations: Separate classes are created to implement this interface for different backend services (e.g., `LocalStorageConnector`, `S3StorageConnector`).
3. Configuration-based Loading: The SRE's configuration file dictates which specific connector implementation to load at runtime.

This design allows a developer to switch the underlying infrastructure—for example, from local file storage to S3—by changing only a single line in the configuration file. The application code, which interacts with the `IStorageConnector` interface, remains completely unchanged.