# Silmataivas (Rust Version)

Silmataivas is a weather monitoring service that sends personalized alerts based on user-defined thresholds and notification preferences. This is the Rust version, providing a RESTful API for managing users, locations, weather thresholds, and notification settings.

## Features

- Weather monitoring using OpenWeatherMap API
- Custom weather thresholds per user
- Flexible notifications: NTFY (push) and SMTP (email)
- User-specific configuration
- RESTful API for all resources

## Project Structure

- **src/main.rs**: All application logic and API endpoints (no lib.rs, not a library)
- **src/**: Modules for users, locations, notifications, weather thresholds, etc.
- **migrations/**: SQL migrations for SQLite
- **Dockerfile**: For containerized deployment

## Quick Start

### Prerequisites

- Rust (see [rustup.rs](https://rustup.rs/))
- SQLite (default, or set `DATABASE_URL` for PostgreSQL)

### Running Locally

```bash
# Clone the repository
 git clone https://codeberg.org/silmataivas/silmataivas.git
 cd silmataivas

# Build and run
 cargo build --release
 ./target/release/silmataivas
```

The server will listen on port 4000 by default. You can set the `DATABASE_URL` environment variable to change the database location.

### Using Docker

```bash
docker build -t silmataivas .
docker run -p 4000:4000 -e DATABASE_URL=sqlite:///data/silmataivas.db silmataivas
```

## API Usage

All API endpoints (except `/health`) require authentication using a Bearer token:

```
Authorization: Bearer <user_id>
```

See the source code for endpoint details. (OpenAPI docs are not yet auto-generated in this Rust version.)

## Migration Note

This project was previously implemented in Elixir/Phoenix. All Elixir/Phoenix code, references, and setup instructions have been removed. The project is now a Rust binary only (no library, no Elixir code).

## Development

- Format: `cargo fmt`
- Lint: `cargo clippy`
- Test: `cargo test`

## Contributing

- Use conventional commits for PRs
- See the code for module structure and API details

---

For any issues or questions, please open an issue on Codeberg.

## TODO

### ✅ Project Completion Checklist for Weather Monitoring App

#### 🧱 Architecture & Code Quality

- [ ] Centralized error handling (e.g., `thiserror`, `anyhow`, `IntoResponse`)
- [ ] Organize code into service/domain/modules to improve separation of concerns
- [ ] Add rate limiting/backoff for OpenWeather API usage
- [ ] Write unit tests for core logic (e.g., user CRUD, weather checks)
- [ ] Add integration tests for full API endpoints
- [ ] Benchmark endpoint latency and cold-start performance

#### 🔒 Security

- [ ] Ensure proper SQL injection protection (`sqlx` should cover this, but verify inputs)
- [ ] Review CORS and CSRF protection for web endpoints
- [ ] Validate and sanitize all environment variables at startup
- [ ] Secure storage for SMTP/Ntfy credentials (env vars or secret store)

#### 🔭 Observability & Monitoring

- [ ] Add `/healthz` and `/metrics` endpoints (e.g., Prometheus)
- [ ] Use structured logging (`tracing` spans for request lifecycle)
- [ ] Consider log rotation or persistent log storage
- [ ] Alerting or notifications if cron job fails

#### ⚙️ CLI & Deployment

- [ ] Build CLI for DB/settings management (with help output and scripting support)
- [ ] Implement DB backup or export functionality (even for SQLite)
- [ ] Enable SQLite WAL mode and regular vacuuming
- [ ] Add install/setup instructions to CLI or README

#### 🧑‍💻 Web Interface (MVP)

- [ ] Add a minimal web UI (htmx, Yew, or static + API)
- [ ] Ensure UI is responsive/mobile friendly
- [ ] Add form to configure thresholds, ntfy/smtp, location, etc.
- [ ] Web UI: Add table or list of current weather rules

#### ☀️ Weather & Notifications Logic

- [ ] Only send notification on threshold **crossing**, not on every cron run
- [ ] Allow multiple thresholds per user (e.g., temp < 0°C and wind > 30km/h)
- [ ] Store basic history of weather checks (for debugging/trends)
- [ ] Abstract weather provider to allow future plug-ins (e.g., Tomorrow.io, Meteomatics)

#### 🧪 Testing & QA

- [ ] Add CI test for API correctness (user + notification config CRUD)
- [ ] Add e2e test for full flow: create user → set threshold → trigger alert
- [ ] Add test for OpenAPI schema consistency

#### 📦 Open Source Readiness

- [ ] Add detailed README with setup, architecture overview, and usage
- [ ] Add LICENSE file
- [ ] Add `CONTRIBUTING.md` with basic guide
- [ ] Add `.env.example` with defaults
- [ ] Add changelog or release notes for future versions

#### 🚀 Final Steps

- [ ] Deploy to production server
- [ ] Verify Docker Compose deployment with CLI and web UI
- [ ] Publish initial release/tag on Codeberg