Dishire — How It Works
This page explains how the Dishire prototype operates internally, focusing on system structure and how LLMs are integrated into the service flow.
1. System Overview
Dishire is a lightweight web-based prototype that generates meal recipes based on user context, available ingredients, and basic preferences. The system consists of three main layers: a React frontend, a FastAPI backend, and an external LLM API.
Rather than relying on a single LLM call, the prototype explores a multi-step generation flow to evaluate controllability, latency, and prompt design trade-offs.
2. Overall Architecture
- Frontend (React): collects user input and displays generated recipes.
- Backend (FastAPI): builds prompts, manages session state, and orchestrates LLM calls.
- LLM API: generates recipe components based on structured prompts.
- Database (PostgreSQL, prototype-level): stores minimal user profile constraints.
3. Multi-step Recipe Generation Flow
Recipe generation is divided into multiple stages. Initial steps generate only the high-level direction (title, description, difficulty), allowing users to quickly decide whether the recipe fits their needs.
Subsequent steps generate ingredients, tools, instructions, and tips, all while sharing session context to maintain coherence.
4. Prompt Template Design
Dishire uses a combination of static prompt templates and dynamic input injection. The output structure is fixed, while user-specific constraints are injected into placeholders.
This partially dynamic approach balances response stability with personalization flexibility.
5. LLM Call Strategy & Limitations
The multi-step approach did not significantly reduce token usage or latency compared to single-call generation. In some cases, single calls produced more natural recipes.
However, the multi-step design provided valuable insight into controllability, UX flow, and future personalization possibilities.