`TaskRepository` Component

[LeoBorai]

Introduce the TaskRepository component in charge of providing the Task in runtime.

Tasks are the execution units for Mate, a Task contains the logic to be executed during a Job
provided params. Tasks are likely to be defined by a developer as part of their own logic but
they can also be published for more generic environments.

For instance a Mail service could build its own Task for sending emails as part of Jobs, we might
want to have different namespaces for this reason, that way a project could handle different "send-email" tasks as part of their job ecosystem.

pub struct TaskIdentifier {
    pub namespace: String,  // "acme-corp", "engineering-team", "john-doe"
    pub name: String,       // "data-processor", "image-optimizer"
    pub version: Version,   // 1.2.3
}

acme-corp/image-optimizer@1.2.3

Flowchart

flowchart TD
    Start([Scheduler triggers job]) --> Executor[Executor requests Task WASM]
    Executor --> L1{Check L1 Cache<br/>In-Memory}
    
    L1 -->|Hit| Return1[Return compiled module]
    Return1 --> Execute[Execute job]
    
    L1 -->|Miss| L2{Check L2 Cache<br/>Disk/Filesystem}
    
    L2 -->|Hit| Compile1[Compile WASM]
    Compile1 --> StoreL1_1[Store in L1 Cache]
    StoreL1_1 --> Return2[Return compiled module]
    Return2 --> Execute
    
    L2 -->|Miss| Repo{Fetch from Repository}
    
    Repo --> RepoImpl{Repository Type?}
    RepoImpl -->|Local FS| FetchFS[Fetch from Local Filesystem]
    RepoImpl -->|Remote| FetchRemote[Fetch from Remote Server]
    
    FetchFS --> StoreL2[Store in L2 Cache]
    FetchRemote --> StoreL2
    
    StoreL2 --> Compile2[Compile WASM]
    Compile2 --> StoreL1_2[Store in L1 Cache]
    StoreL1_2 --> Return3[Return compiled module]
    Return3 --> Execute
    
    Execute --> End([Job completed])
    
    style L1 fill:#e1f5ff
    style L2 fill:#fff4e1
    style Repo fill:#ffe1e1
    style Execute fill:#e1ffe1

Loading