Sameh Abouelsaad 9dce815daa feat: Add basic project structure and initial crates

- Added basic project structure with workspace and crates:
  `kvstore`, `vault`, `evm_client`, `cli_app`, `web_app`.
- Created initial `Cargo.toml` files for each crate.
- Added placeholder implementations for key components.
- Included initial documentation files (`README.md`, architecture
  docs, repo structure).
- Included initial implementaion for kvstore crate(async API, backend abstraction, separation of concerns, WASM/native support, testability)
- Included native and browser tests for the kvstore crate

2025-05-13 20:24:29 +03:00

3.2 KiB

Raw Blame History

SAL Repository Structure

Introduction

This document describes the recommended structure for the SAL repository, reflecting the new modular architecture. The goal is to enable robust, maintainable, and WASM-compatible development, while supporting a CLI binary and Rhai scripting.

Recommended Directory Layout

sal/
├── arch/
│   ├── Architecture.md
│   └── RepoStructure.md   # ← this file
├── Cargo.toml             # Workspace manifest
├── kvstore/
│   ├── Cargo.toml
│   └── src/
├── vault/
│   ├── Cargo.toml
│   └── src/
├── evm_client/
│   ├── Cargo.toml
│   └── src/
├── cli_app/
│   ├── Cargo.toml
│   └── src/
│       ├── main.rs        # CLI binary entry point
│       └── commands.rs
├── web_app/
│   ├── Cargo.toml
│   └── src/
├── rhai/
│   └── src/
│       └── lib.rs         # Rhai bindings and script API
└── README.md

Each core component (kvstore, vault, evm_client, rhai) is a separate crate at the repo root.
CLI binary is in cli_app and depends on the core crates.
WebAssembly target is in web_app.
Rhai bindings live in their own crate (rhai/), so both CLI and WASM can depend on them.

Sample Workspace `Cargo.toml`

[workspace]
members = [
    "kvstore",
    "vault",
    "evm_client",
    "cli_app",
    "web_app",
    "rhai",
]

Component Details

kvstore

Async trait for key-value storage.
Native and WASM backends selected by features or cfg.

vault

Manages encrypted keyspaces and cryptographic operations.
Uses kvstore for persistence.

evm_client

Handles EVM RPC, uses vault for signing.

cli_app (Binary)

Provides CLI interface using vault, evm_client, and rhai.
Entry point: cli_app/src/main.rs.

web_app (WASM)

Exposes Rust APIs to JS using wasm-bindgen.
Depends on vault, evm_client, and rhai.

rhai

Contains all Rhai script bindings and API glue.
Shared by both CLI and WASM targets.

Integration & Migration Notes

Move code from src/hero_vault and related modules into the new crates.
The CLI binary is now in cli_app/src/main.rs, depending on all core crates.
Rhai bindings are centralized in the rhai/ crate, making them reusable.
If you need to keep a legacy src/ for migration, do so temporarily—plan to remove it once the transition is complete.

Rationale

Idiomatic Rust: Each crate at the root, easy to manage, test, and publish.
Maintainability: Clear separation of concerns, easy to extend.
WASM & CLI: Both targets are first-class, sharing as much code as possible.
Rhai Integration: Centralized, reusable scripting interface.

Example: How to Build the CLI Binary

cd cli_app
cargo build --release
cargo run -- <args>

The CLI binary will be compiled as target/release/cli_app.

Example: How to Build the WASM Target

cd web_app
wasm-pack build --target web

Summary

This structure enables modular, scalable development for both CLI and browser targets, with robust support for async, WASM, and scripting via Rhai.

3.2 KiB Raw Blame History