# Recipe WebApp - Software Requirements Specification

# Introduction
## Purpose of this document
This document outlines the project requirements and design decisions for the Recipe WebApp.

Written following the [SRS format guidelines](https://www.geeksforgeeks.org/software-engineering/software-requirement-specification-srs-format/).

## Scope
This document covers the requirements for a recipe recording and sharing web application.

The primary user base is family members and the developer. The app provides a way to record, access, and share recipes from anywhere. Key use cases include preserving a collection of family recipes for easy reference, and organizing recipes that are researched, AI-generated, or scanned from handwritten cards.

The application is self-hosted on a personal DigitalOcean Droplet server.

## Overview
A recipe recording and sharing Web App built with a Go backend API and React frontend.

# General Description
While the app includes standard recipe-sharing features such as an account system and a public space for viewing and sharing recipes, its distinguishing feature is offering multiple convenient ways to create recipes: manual entry, AI generation via prompt, and scanning handwritten images of existing recipes via OCR.

# Functional Requirements
1. **Preserve and present recipes on demand.** Users can browse all recipes, search and filter results, and view the full details of any individual recipe.
2. **Account system.** The system preserves user data and enforces permissions through user accounts.
3. **Create recipes.** Users can submit recipes (title, content, images) through multiple input methods: manual entry, AI prompt, or image scanning (photo capture/image upload).
4. **Delete recipes.** Authenticated users can remove their own recipes from the system. Deleted recipes are no longer accessible.
5. **Edit recipes.** Authenticated users can modify their own recipes. Changes are persisted for future access.

# Interface Requirements

## UI
- [REQ-UI-001] The system must allow a user to log in by providing a valid username or email address and their password via a secure form.
- Account interfaces: creation, editing, deletion, and admin management page.
- Recipe interfaces: creation, editing (including AI-assisted creation/editing), deletion, search/results page, and viewing.

## API
- [REQ-API-001] The frontend will submit recipe changes to the Recipe API in JSON format.
- [REQ-API-002] The Recipe API will return a response for recipe updates within 1 second.
- **Session endpoints:**
    - Creation (login), deletion (logout), validation
    - Authentication required for validation and deletion
- **Account endpoints:**
    - Creation (open to all), editing, deletion, retrieval
    - Authorization: only the logged-in user or an admin can edit/delete an account
    - Admin-only: listing all user accounts
- **Recipe endpoints:**
    - Creation (authenticated users), editing, deletion, retrieval (individual and listing/search)
    - Authorization: only the recipe creator or an admin can edit/delete a recipe
- **AI prompting:**
    - Submit a prompt to generate a recipe, which can then be saved via the recipe creation endpoint
- **Image-to-text:**
    - Submit an image to extract text via OCR, which can then be used to populate a recipe creation form

# Performance Requirements
The application is designed for small-scale deployment on a 2GB DigitalOcean Droplet.

**Frontend:**
- Runs in the browser performing standard operations: form handling, rendering images and text from the backend.
- Most frontend operations are expected to be near-instant.
- React enables flexible component loading strategies.

**Backend:**
- Runs as a Go service handling account management, session handling, and recipe CRUD operations.
- Concurrent request handling via Go's built-in goroutines.
- Target submission time: under 200ms.
- Target response time: under 1 second.

# Design Constraints
- Hosted on a DigitalOcean Droplet; the architecture is designed for small-scale server deployments rather than managed cloud services like AWS or Firebase.
- Tech stack is intentionally constrained to: Go (backend API with Gin framework), PostgreSQL (database), and React with Node.js (frontend).
- The frontend communicates with the backend through a proxied API endpoint (e.g., `www.website.com/api`), keeping the backend service unexposed to the public internet.
- Cross-platform: all components can be compiled and run on both Linux and Windows, though the production environment uses Linux.

# Non-functional Requirements

## Security
- JWT-based authentication with HMAC-SHA256 signing.
- Passwords stored as hashes, never in plaintext.
- API keys for third-party services (OCR) kept server-side via backend proxy pattern.

## Portability
- The frontend and backend run on both Linux and Windows.
- Application portability: recompile the Go binary for the target OS; run `npm install` for the frontend.
- Source code portability: Go cross-compilation handles platform differences.
- Data portability: config files and a database export are sufficient to migrate between servers.

## Reusability
- Component reuse via the Bootstrap UI library (frontend) and Gin framework abstractions (backend).
- Data schema defined using Go structs, reusable across the entire backend.

## Application Compatibility
- As a web application, the frontend is developed to support all devices and screen sizes.

# Schedule
- **Phase 1:** Project scaffolding, scalability foundations (logging, database initialization, testing), recipe search and display.
- **Phase 2:** Account system, login pages, session enforcement and permissions.
- **Phase 3:** Recipe creation features (image-to-text OCR, AI prompting), polish (error handling, mobile compatibility, UI/UX refinement).