# Sim-Link

Sim-Link is a web application designed to take the results of Gazebo simulations, save them, rank the best-performing simulations, and display the detailed results in a clean, easy-to-understand format.

The project is intentionally styled without colors to mimic a legacy system, prioritizing highly readable, pure-text tables over modern visual flair.

## Tech Stack
- **Frontend:** SvelteKit (built into a completely Static Single Page Application using Bun).
- **Backend:** Golang.
- **Database:** SQLite3.
- **Containerization:** Docker & Docker Compose.

## Running with Docker (Recommended)

The easiest way to run Sim-Link is by using the provided `docker-compose` environment. This encapsulates the build steps for both the SvelteKit frontend and the Go backend.

```bash
# Build and start the container in the background
docker compose up -d --build
```
*Note: The `results/` folder and `server/` folder are native volume mounts in Docker Compose. This ensures your simulation logs update live, and the `sim-link.db` SQLite file persists on your host machine.*

You can then access the interface at: [http://localhost:8080](http://localhost:8080)

## Running Locally Manually

If you prefer to run the system directly on your OS without Docker, you will need `Bun` and `Go` (with CGO enabled) installed.

### 1. Build the Frontend
Navigate to the root directory and use Bun to render the static HTML/JS payload.
```bash
bun install
bun run build
```
*(This produces a `build/` directory that the Go backend expects).*

### 2. Run the Backend Server
Because the backend uses `go-sqlite3`, it requires CGO to compile. Navigate completely into the `server` directory so the relative paths for serving the `../build` and `../results` folders remain accurate.
```bash
cd server
go run .
```

The server will automatically scan the `../results` folder on startup, index the simulations into the SQLite database, and host the web interface at [http://localhost:8080](http://localhost:8080).

## API Endpoints

The Go backend provides a simple REST API to interact with the simulations:

### `GET /api/simulations`
Returns a JSON array of all indexed simulations, including their ID, name, created date, and configuration string.

### `POST /api/simulations/create`
Creates a new simulation entry.
- **Request Body:** Raw text containing the YAML configuration block.
- **Behavior:** Checks if an identical config exists. If so, it returns the existing simulation ID/Name for overwriting. If not, it allocates a new `simulation_X` incrementally, inserts it into the database, builds the file directory in `../results`, and returns the new ID/Name.
- **Response:** JSON object `{"id": <int>, "name": <string>}`

### `GET /api/simulations/:id`
Provides detailed JSON metadata for a specific simulation ID, including its name, raw text config, creation timestamp, and a dynamically fetched array of all the internal resources (images, logs, videos) located within its folder.

### `PUT /api/simulations/:id/time`
Updates the numeric benchmarking metrics (`search_time` and `total_time`) for a specific simulation run.
- **Request Body:** JSON object containing floats: `{"search_time": 25.4, "total_time": 105.8}`
- **Response:** JSON object `{"status": "success"}`

### `POST /api/simulations/:id/upload`
Uploads a new media or data resource file directly into a completed simulation run. Supports both images (e.g., PNGs) and heavy video files (e.g., AVIs) out of the box with an initial multi-part allocation pool mapping of 500 MB.
- **Request Data:** `multipart/form-data` packet using the `file` keyword carrying the binary data blocks.
- **Behavior:** The Go service validates the simulation ID exists, dynamically builds the memory pool, opens a stream writer caching the binary blob into the `../results/simulation_X/filename.ext` directory path, and records the resource in the primary SQLite instance.
- **Response:** JSON object `{"status": "success", "filename": "example.png"}`