From 35a3a8dbedc374ccb6b12c5c43ecaccbbfee0663 Mon Sep 17 00:00:00 2001 From: John Lancaster <32917998+jsl12@users.noreply.github.com> Date: Tue, 16 Jun 2026 23:46:05 -0500 Subject: [PATCH] reformatted to be more skill-like --- skills/nicegui/SKILL.md | 435 +++++------------- skills/nicegui/references/architecture.md | 92 ++++ .../references/source-documentation.md | 35 ++ 3 files changed, 241 insertions(+), 321 deletions(-) create mode 100644 skills/nicegui/references/architecture.md create mode 100644 skills/nicegui/references/source-documentation.md diff --git a/skills/nicegui/SKILL.md b/skills/nicegui/SKILL.md index fc9d48f..e5fd42f 100644 --- a/skills/nicegui/SKILL.md +++ b/skills/nicegui/SKILL.md @@ -1,56 +1,61 @@ --- name: nicegui -description: Build and scaffold production-ready NiceGUI + FastAPI app architecture. +description: 'Design and scaffold a production-ready NiceGUI + FastAPI application architecture. Use for multi-page app planning, package boundaries, optional DB/LangGraph/docs integration, and implementation checklists.' +argument-hint: 'What should this app include (pages, DB, AI, docs, constraints)?' --- # NiceGUI -Build a production-ready, multi-page NiceGUI application that follows modern FastAPI project layout and architecture practices. +Design a production-minded NiceGUI + FastAPI architecture with clear boundaries, optional extensions, and a concrete implementation checklist. -## Goal +## When to Use -Create a clean, maintainable app structure where: -- FastAPI is the underlying ASGI app. -- NiceGUI is mounted/initialized in a way that aligns with FastAPI best practices. -- Each page is implemented as a separate module in `pages/`. -- The project is easy to test, extend, and deploy. +- You need a reusable architecture plan before implementing a NiceGUI app. +- You want FastAPI app-factory structure and lifespan wiring. +- You need optional guidance for database, LangGraph workflows, or mounted static docs. +- You want output that is concise, structured, and implementation-ready. -## Requirements +## Inputs to Collect -- Prefer Pydantic settings with a `.env` example. -- Consider adding structured logging configuration. -- Use a `src/`-style layout with clear package boundaries. -- Use an app factory (`create_app`) and avoid global side effects at import time. -- Register NiceGUI pages from modules in `pages/`. -- Keep UI logic in page modules and shared UI helpers/components in a separate package. -- Include at least these pages: - - Home (`/`) - - Dashboard (`/dashboard`) - - About (`/about`) -- Include a health endpoint (`/healthz`) on the FastAPI side. -- Provide minimal test examples for FastAPI routes and page registration. -- Use FastAPI lifespan for startup/shutdown resource management. +Collect these inputs up front. If not provided, make safe defaults and state assumptions. -## Recommendations +- Product scope and primary user journeys. +- Required pages and route map. +- Whether persistent data is required. +- Whether AI orchestration (multi-step, streaming, approvals) is required. +- Whether generated docs should be mounted in-app. +- Runtime/deployment constraints (single service vs split services, environment requirements). -- Consider a shared navigation/header component and left drawer used by all pages. -- Consider including dev tooling basics (formatting/lint/test commands). -- Prefer clear separation of concerns: - - `db/` for engine/session/base/models/repositories (if needed) - - `api/` for HTTP endpoints - - `ui/` for NiceGUI pages/components - - `services/` for business logic -- If you need database access, a solid pattern is to use FastAPI + SQLAlchemy best practices: - - Use one engine per application process (do not create per request). - - Prefer a request-scoped session dependency using `yield`. - - Keep transaction boundaries explicit (commit/rollback) in service/repository flows. - - Avoid sharing a session across concurrent tasks. - - Consider production-minded pool settings (`pool_pre_ping=True` and sensible recycle/timeout values). - - Prefer Alembic for schema migrations. +## Outcome -## Suggested Project Structure +Produce: -Base structure (no database required): +- A concise architecture explanation. +- How core services, UI pages, and UI components fit together. +- Explicit decision on DB ownership or involvement. +- Explicit decision on AI workflow (or no AI). +- A checklist implementation plan organized by package and domain. + +## Procedure + +1. Frame the baseline architecture. +2. Choose optional extensions (DB, AI, docs) using decision points below. +3. Map modules, dependencies, and key boundaries. +4. Define key functions/classes and configuration surfaces. +5. Produce phased checklist with rollout or migration notes when relevant. +6. Run completion checks before returning. + +### 1) Baseline architecture + +Use a src-layout with FastAPI as the ASGI app and NiceGUI registered via composition. + +- App factory pattern: `create_app()`. +- Lifespan for startup and shutdown resource management. +- `api/` for HTTP handlers, `services/` for business logic. +- `ui/pages/` for page modules, `ui/components/` for shared UI. +- Health endpoint on FastAPI side: `/healthz`. + +Recommended base shape: ```text . @@ -61,6 +66,7 @@ Base structure (no database required): │ └─ app/ │ ├─ __init__.py │ ├─ main.py +│ ├─ bootstrap.py │ ├─ config.py │ ├─ logging.py │ ├─ api/ @@ -69,319 +75,106 @@ Base structure (no database required): │ ├─ services/ │ │ ├─ __init__.py │ │ └─ example_service.py -│ ├─ ui/ -│ │ ├─ __init__.py -│ │ ├─ components/ -│ │ │ ├─ __init__.py -│ │ │ └─ nav.py -│ │ └─ pages/ -│ │ ├─ __init__.py -│ │ ├─ home.py -│ │ ├─ dashboard.py -│ │ └─ about.py -│ └─ bootstrap.py -└─ tests/ - ├─ test_health.py - └─ test_pages_registration.py -``` - -### Conceptual boundaries for the base structure - -- `main.py`: application entrypoint only; wires `create_app()` and process startup concerns. -- `bootstrap.py`: app composition layer; owns app factory, router registration, page registration, and lifespan wiring. -- `config.py`: configuration boundary; centralizes settings parsing and typed config objects. -- `logging.py`: observability boundary; centralizes logging format/levels/handlers so modules do not configure logging ad hoc. -- `api/`: transport boundary for HTTP endpoints; validate/shape request-response objects and delegate business work to `services/`. -- `services/`: use-case/business boundary; orchestrates domain behavior and dependencies, independent of UI rendering. -- `ui/pages/`: route-level UI boundary; one module per page, focused on layout/event handling for that page. -- `ui/components/`: reusable presentation boundary; shared UI widgets/composition utilities with no business side effects. -- `tests/`: behavior boundary; verify public behavior (health endpoint, page registration, service outcomes), not private implementation details. - -### Dependency direction to keep clear - -- Prefer this dependency flow: - - `main/bootstrap` -> `config/logging` + `api` + `ui/pages` + `services` - - `api` -> `services` - - `ui/pages` -> `ui/components` + `services` - - `services` -> pure helpers/clients (and later `db/` if enabled) -- Avoid reverse imports (for example, `services` importing from `ui/pages` or `api`). -- Keep page modules and API handlers as thin adapters; keep business decisions in `services/`. - -## Extending This Pattern with a Database (Optional) - -If database access is needed, extend with: - -```text -. -├─ alembic.ini -├─ alembic/ -│ ├─ env.py -│ └─ versions/ -├─ src/ -│ └─ app/ -│ └─ db/ +│ └─ ui/ │ ├─ __init__.py -│ ├─ base.py -│ ├─ session.py -│ ├─ models/ +│ ├─ components/ │ │ ├─ __init__.py -│ │ └─ example.py -│ └─ repositories/ +│ │ └─ nav.py +│ └─ pages/ │ ├─ __init__.py -│ └─ example_repo.py +│ ├─ home.py +│ ├─ dashboard.py +│ └─ about.py └─ tests/ - └─ test_db_session_dependency.py + ├─ test_health.py + └─ test_pages_registration.py ``` -### Recommended database layering +### 2) Decision points -- Keep `db/` focused on persistence primitives: - - `session.py`: engine + session factory + dependency helpers - - `models/`: ORM table mappings only - - `repositories/`: query/persistence operations only -- Keep transaction orchestration in `services/`, not in UI pages. -- Keep `ui/pages/` free of SQLAlchemy details; pages call services. -- Keep API handlers thin and delegate data work to services/repositories. +#### Database needed? -### Session and transaction pattern to request +- If no: keep `services/` pure and skip persistence layers. +- If yes: add `db/` package with engine/session/model/repository layering. +- Prefer one process-level engine and request-scoped sessions via `yield`. +- Prefer Alembic migrations for schema changes. -- Use one engine and one sessionmaker per process, initialized at app startup. -- Use a `get_db_session()` dependency with `yield` for request-scoped sessions. -- In write flows, always use context managers for commit/rollback safety. -- In read-only flows, avoid unnecessary transactions and keep queries narrowly scoped. -- Do not share a session across concurrent tasks; open a new session per task/unit of work. +#### AI workflow needed? -### Migration and schema workflow +- If no: keep `services/` focused on app logic only. +- If yes: add `ai/` package (state, nodes, graph, runtime, contracts). +- Keep graph internals out of `ui/pages/` and API handlers. +- Use stable thread/session IDs for resumable flows. -- Treat Alembic migrations as the source of truth for schema evolution. -- Prefer: - - `alembic revision --autogenerate -m "..."` - - review migration script - - `alembic upgrade head` -- Avoid relying on `metadata.create_all()` for production schema management. -- Include a lightweight startup check that logs current migration state (without mutating schema). +#### Mounted docs needed? -### Configuration and runtime concerns +- If no: skip docs mounting. +- If yes: mount generated static site under configurable route (default `/docs`). +- Keep docs mounting in composition layer, not page modules. -- Read `DATABASE_URL` from settings (`pydantic-settings`) and keep secrets out of source control. -- Configure pool options appropriate for environment (for example: `pool_pre_ping`, timeout/recycle tuning). -- Keep SQL echo/debug logging disabled in production by default. -- Consider a readiness probe (`/readyz`) that verifies DB connectivity when your deployment needs it. +### 3) Page and component registration -### Testing guidance for DB-enabled projects +- Require at minimum page modules for `/`, `/dashboard`, `/about`. +- Prefer explicit registration pattern: + - `ui/pages/__init__.py` exports `register_pages()`. + - Each page module exports `register_page()`. +- Shared shell components (header/nav/drawer) live in `ui/components/`. -- Unit test repositories against a disposable test database. -- Integration test `get_db_session()` lifecycle and rollback behavior on failures. -- Add migration tests that validate model changes are represented in Alembic revisions. -- Add API/service tests for critical read/write paths (including uniqueness and constraint errors). -- Keep DB tests isolated and deterministic (fresh schema + transactional cleanup per test module/session). +### 4) Dependency direction rules -## Extending This Pattern with LangGraph (Optional) +Prefer: -If your app needs multi-step AI workflows, tool-calling loops, or human-in-the-loop approvals, a clean extension is to add a dedicated LangGraph domain layer. +- `main/bootstrap` -> `config/logging` + `api` + `ui/pages` + `services` +- `api` -> `services` +- `ui/pages` -> `ui/components` + `services` +- `services` -> helpers/clients (and `db/` when enabled) -### Recommended architecture shape +Avoid reverse imports from services into API or UI modules. -- Keep LangGraph logic out of `ui/pages/` and out of HTTP route handlers. -- Add an `ai/` package (or similar) and keep graph definition, state schema, tools, and orchestration there. -- Call the graph from `services/` so your UI and API both use the same orchestration entry points. -- Continue using FastAPI lifespan for shared resources (models, clients, stores/checkpointers). +### 5) Testing minimums -### Suggested project extension +- Test FastAPI health route behavior. +- Test page registration wiring. +- If DB enabled: session lifecycle and rollback behavior tests. +- If AI enabled: graph happy path and interrupt/resume coverage. +- If docs enabled: mounted docs route returns index page. -```text -. -└─ src/ - └─ app/ - ├─ ai/ - │ ├─ __init__.py - │ ├─ state.py # TypedDict / Pydantic state schemas + reducers - │ ├─ nodes/ - │ │ ├─ __init__.py - │ │ ├─ llm.py - │ │ ├─ tools.py - │ │ └─ review.py # optional interrupt/human-review nodes - │ ├─ graphs/ - │ │ ├─ __init__.py - │ │ └─ assistant_graph.py - │ ├─ runtime.py # compile() + checkpointer/store wiring - │ └─ contracts.py # input/output DTOs between services and graph - ├─ services/ - │ └─ ai_service.py # invoke/stream/resume wrappers - └─ api/ - └─ ai.py # optional HTTP endpoints for run/stream/resume -``` +### 6) Styling architecture -### Idiomatic LangGraph practices to request +- Keep structure and layout in Python modules using NiceGUI class composition. +- Keep visual polish in shared CSS files, loaded once at startup. +- Prefer semantic reusable classes over ad hoc per-page styling. -- Define explicit graph state schema (`TypedDict` or Pydantic) and use reducers for append/merge behavior where needed. -- Compile graphs with persistence primitives appropriate to environment: - - dev/testing: in-memory checkpointer/store - - production: durable checkpointer/store -- Always pass a stable `thread_id` in `configurable` for resumable sessions and conversation continuity. -- For interactive UX, prefer event streaming APIs and project-specific streaming adapters in service code. -- Use `interrupt()` for human approvals/reviews; resume with `Command(resume=...)` using the same `thread_id`. -- Keep interrupt payloads JSON-serializable. -- Place non-idempotent side effects after interrupts (or isolate them in separate nodes), because interrupted nodes re-run from the start. -- If using tools, prefer LangGraph’s `ToolNode` (or an equivalent centralized tool-execution node) for consistent execution/error handling. -- Keep graph nodes deterministic and narrow in scope (single responsibility per node). -- Add observability with LangSmith tracing for graph runs, transitions, and latency debugging. +## Completion Checks -### Integration guidance for NiceGUI + FastAPI +- Uses app factory and FastAPI lifespan. +- Pages are modularized (not single-file UI). +- Health endpoint exists on FastAPI side. +- Dependency direction is clean and one-way. +- Optional DB/AI/docs decisions are explicit and reflected in structure. +- Output includes architecture summary and package-organized checklist. -- UI pages should call `ai_service` methods, not graph internals. -- If the UX needs live token/progress updates, expose streaming from service -> UI in a transport-appropriate way. -- For approval workflows, surface interrupt payloads in UI, collect user response, then resume via service with `Command(resume=...)`. -- Keep graph invocation boundaries typed (request/response contracts) so changes in graph internals do not leak into page modules. - -### Testing recommendations for LangGraph additions - -- Unit test node functions as pure transformations where possible. -- Integration test graph routes (happy path, tool path, interrupt/resume path). -- Add tests ensuring `thread_id` reuse resumes correctly and new IDs start fresh sessions. -- Add regression tests for state-schema evolution and serialization compatibility. - -## Extending This Pattern with a Static Docs Site via Zensical (Optional) - -If the app should also host a static documentation site, mount the generated docs output directory under a configurable route (default: `/docs`). - -### Recommended docs workflow - -- Initialize docs in the project root: - - `uv run zensical new .` -- Keep source markdown in Zensical's `docs_dir` (default: `docs/`). -- Build docs as part of release or startup pipeline: - - `uv run zensical build` -- Serve the generated static output from Zensical's `site_dir` (default: `site/`). - -### Config to include in app settings - -- `docs_enabled: bool = true` -- `docs_mount_path: str = "/docs"` -- `docs_site_dir: str = "site"` -- Optional for local/dev convenience: - - `docs_require_build: bool = false` (if true, fail startup when `site/` is missing) - -### FastAPI/NiceGUI integration pattern - -- Keep docs mounting in the app composition layer (`bootstrap.py`), not in page modules. -- Use FastAPI static serving to mount the built directory (for example via `StaticFiles(..., html=True)`). -- Ensure `docs_mount_path` is normalized (leading slash, no trailing slash) and does not conflict with app/API routes. -- If docs are disabled or build artifacts are missing, log a clear warning and continue (unless `docs_require_build=true`). - -### Suggested project additions - -```text -. -├─ zensical.toml -├─ docs/ -│ ├─ index.md -│ └─ ... -├─ site/ # generated by `uv run zensical build` -└─ src/ - └─ app/ - ├─ config.py # docs_enabled/docs_mount_path/docs_site_dir - └─ bootstrap.py # mount static docs route -``` - -### Deployment notes for docs mounting - -- In CI/CD, run `uv run zensical build` before packaging/deploying the app image. -- If `project.site_dir` in `zensical.toml` is changed, keep `docs_site_dir` in app settings aligned. -- If hosting behind a reverse proxy with a path prefix, verify docs links and static assets with the final external base path. -- Add a test asserting requests to `docs_mount_path` return the built index page when docs are enabled. - -## Implementation Notes - -- Prefer an explicit page registration function pattern, for example: - - `register_pages()` in `ui/pages/__init__.py` - - Each page module exports `register_page()` -- Keep imports one-way to avoid circular dependencies. -- Keep page modules cohesive: route declaration + page layout for that route. -- Prefer FastAPI lifespan hooks where appropriate for startup/shutdown behavior. -- Prefer type hints throughout. - -### Styling architecture notes - -- Prefer class-first UI composition for structure and layout using normal NiceGUI mechanics (`.classes(...)` on containers/components). -- Keep structural concerns in Python page/component modules (layout grids, spacing systems, responsive breakpoints, alignment). -- Keep cosmetic concerns in static CSS files (colors, gradients, shadows, border polish, typography fine-tuning, transitions). -- Avoid large inline `style(...)` strings except for one-off dynamic values that must be computed at runtime. -- Centralize CSS entrypoints in a small, predictable set (for example `ui/static/css/base.css`, `ui/static/css/theme.css`, `ui/static/css/components.css`). -- Include CSS once at app bootstrap/startup so pages share the same style contract; avoid per-page ad hoc includes. -- Prefer semantic class names for reusable patterns (`app-shell`, `page-section`, `card-surface`) and utility classes only for local layout tweaks. -- If using design tokens, define them as CSS custom properties in `:root` and reference them from component classes. -- Keep page modules focused on structure and behavior; reusable visual patterns should live in shared UI components plus shared CSS. - -### Database-specific notes (only if your app needs a DB) - -- Prefer settings via `pydantic-settings` and read `DATABASE_URL` from environment/dotenv. -- Configure the SQLAlchemy engine once at app setup level; avoid creating engine/sessionmaker in endpoint functions. -- Provide `get_db_session()` via `yield` so sessions are consistently closed. -- Prefer a repository/service boundary to keep SQL details out of page modules. -- Prefer Alembic for schema changes and include commands for `revision --autogenerate` and `upgrade head`. -- Avoid `metadata.create_all()` in production startup flow; reserve it for optional local/dev bootstrap paths. -- Consider a light DB readiness check in health reporting (or a dedicated `/readyz`) when relevant. -- Ensure logs do not leak secrets (for example, avoid unsafe SQL echo in production). - -## Output Format - -The goal of the output is to produce an output +## Output Contract Return: -- A concise, high-level architecture explanation. -- An explanation of how the different parts of the concept will fit into this structure - - What are the core services? - - What are the main ui pages? - - What are the main ui components? - - Whether a database will be involved and whether the app owns the database - - Whether any AI will be used and what the workflow looks like -- A concrete implementation plan in the form of a checklist, organized into sections by concept which should roughly mirror the structure of sub-packages. - - Key functions/classes - - Configuration/settings available - - Migration or rollout notes (if relevant) + +- Concise high-level architecture. +- How core services, pages, and shared components fit. +- DB involvement and ownership stance. +- AI workflow stance and runtime flow. +- Checklist plan by package and domain: + - key functions/classes + - settings/config surfaces + - rollout/migration notes (when relevant) ## Guardrails -- Do not put all pages in a single file. -- Never use globals, implicit or otherwise. +- Do not collapse all pages into one file. +- Do not use globals or implicit global side effects. - Keep code minimal but production-minded. -- Being clear and concise is a higher priority than being verbose. - Prefer clarity and maintainability over clever abstractions. -## Source Documentation (recommended references) +## References -- FastAPI lifespan events: - - https://fastapi.tiangolo.com/advanced/events/ -- FastAPI settings and environment variables: - - https://fastapi.tiangolo.com/advanced/settings/ -- FastAPI dependencies with `yield` (session lifecycle pattern): - - https://fastapi.tiangolo.com/tutorial/dependencies/dependencies-with-yield/ -- FastAPI SQL databases tutorial (when using a DB): - - https://fastapi.tiangolo.com/tutorial/sql-databases/ -- SQLAlchemy engine configuration and pooling (when using a DB): - - https://docs.sqlalchemy.org/en/20/core/engines.html -- SQLAlchemy session basics and lifecycle guidance (when using a DB): - - https://docs.sqlalchemy.org/en/20/orm/session_basics.html -- Alembic tutorial and migration environment (when using a DB): - - https://alembic.sqlalchemy.org/en/latest/tutorial.html -- Pydantic settings management: - - https://pydantic.dev/docs/validation/latest/concepts/pydantic_settings/ -- NiceGUI pages/routing and FastAPI integration: - - https://www.nicegui.io/documentation/section_pages_routing -- NiceGUI security best practices: - - https://www.nicegui.io/documentation/section_security -- LangGraph overview: - - https://docs.langchain.com/oss/python/langgraph/overview -- LangGraph quickstart: - - https://docs.langchain.com/oss/python/langgraph/quickstart -- LangGraph workflows and agents: - - https://docs.langchain.com/oss/python/langgraph/workflows-agents -- LangGraph persistence (checkpointer vs store): - - https://docs.langchain.com/oss/python/langgraph/persistence -- LangGraph memory concepts: - - https://docs.langchain.com/oss/python/concepts/memory -- LangGraph streaming: - - https://docs.langchain.com/oss/python/langgraph/streaming -- LangGraph interrupts / human-in-the-loop: - - https://docs.langchain.com/oss/python/langgraph/interrupts +- Architecture and integration details: [NiceGUI architecture reference](./references/architecture.md) +- Source documentation links: [NiceGUI source documentation](./references/source-documentation.md) diff --git a/skills/nicegui/references/architecture.md b/skills/nicegui/references/architecture.md new file mode 100644 index 0000000..bee1ab4 --- /dev/null +++ b/skills/nicegui/references/architecture.md @@ -0,0 +1,92 @@ +# NiceGUI Architecture Reference + +This reference expands the workflow in the main skill file and is loaded only when needed. + +## Baseline package boundaries + +- `main.py`: process entrypoint only. +- `bootstrap.py`: app composition, router wiring, page registration, lifespan orchestration. +- `config.py`: typed settings and env parsing. +- `logging.py`: centralized logging setup. +- `api/`: HTTP transport layer; delegates to services. +- `services/`: business/use-case logic. +- `ui/pages/`: route-level NiceGUI pages. +- `ui/components/`: shared UI building blocks. + +## Required baseline behavior + +- FastAPI is the base ASGI app. +- NiceGUI pages are modular and registered from page modules. +- Minimum pages: `/`, `/dashboard`, `/about`. +- FastAPI health route: `/healthz`. +- Lifespan handles startup/shutdown resources. +- No global side effects at import time. + +## Optional extension: Database + +Use only if persistence is required. + +Suggested additions: + +```text +src/app/db/ +├─ __init__.py +├─ base.py +├─ session.py +├─ models/ +└─ repositories/ +``` + +Guidelines: + +- One engine and one sessionmaker per process. +- Request-scoped session dependency using `yield`. +- Explicit transaction boundaries in service/repository flows. +- Avoid shared sessions across concurrent tasks. +- Use Alembic as schema source of truth. + +## Optional extension: LangGraph AI + +Use only for multi-step AI orchestration or human-in-the-loop workflows. + +Suggested additions: + +```text +src/app/ai/ +├─ state.py +├─ nodes/ +├─ graphs/ +├─ runtime.py +└─ contracts.py +``` + +Guidelines: + +- Keep graph internals outside API/UI modules. +- Invoke graph through `services/ai_service.py`. +- Use stable thread/session IDs for resumable sessions. +- Keep interrupt payloads JSON-serializable. + +## Optional extension: Mounted static docs + +Use only when generated docs should be served in-app. + +Suggested settings: + +- `docs_enabled` +- `docs_mount_path` +- `docs_site_dir` +- `docs_require_build` (optional) + +Guidelines: + +- Mount docs in composition layer (`bootstrap.py`). +- Normalize mount path and avoid route conflicts. +- Warn on missing build artifacts unless strict mode is enabled. + +## Suggested output quality criteria + +- Clear architecture summary with assumptions. +- Explicit decisions for DB, AI, and docs. +- Package-scoped implementation checklist. +- Minimal test plan aligned to enabled features. \ No newline at end of file diff --git a/skills/nicegui/references/source-documentation.md b/skills/nicegui/references/source-documentation.md new file mode 100644 index 0000000..3b7f22f --- /dev/null +++ b/skills/nicegui/references/source-documentation.md @@ -0,0 +1,35 @@ +# Source Documentation + +Use these links for framework-specific details. + +## FastAPI + +- FastAPI lifespan events: https://fastapi.tiangolo.com/advanced/events/ +- FastAPI settings and environment variables: https://fastapi.tiangolo.com/advanced/settings/ +- FastAPI dependencies with yield: https://fastapi.tiangolo.com/tutorial/dependencies/dependencies-with-yield/ +- FastAPI SQL databases tutorial: https://fastapi.tiangolo.com/tutorial/sql-databases/ + +## SQLAlchemy and Alembic + +- SQLAlchemy engine configuration and pooling: https://docs.sqlalchemy.org/en/20/core/engines.html +- SQLAlchemy session lifecycle basics: https://docs.sqlalchemy.org/en/20/orm/session_basics.html +- Alembic tutorial: https://alembic.sqlalchemy.org/en/latest/tutorial.html + +## Pydantic + +- Pydantic settings management: https://pydantic.dev/docs/validation/latest/concepts/pydantic_settings/ + +## NiceGUI + +- NiceGUI pages/routing and FastAPI integration: https://www.nicegui.io/documentation/section_pages_routing +- NiceGUI security best practices: https://www.nicegui.io/documentation/section_security + +## LangGraph + +- LangGraph overview: https://docs.langchain.com/oss/python/langgraph/overview +- LangGraph quickstart: https://docs.langchain.com/oss/python/langgraph/quickstart +- LangGraph workflows and agents: https://docs.langchain.com/oss/python/langgraph/workflows-agents +- LangGraph persistence: https://docs.langchain.com/oss/python/langgraph/persistence +- LangGraph memory concepts: https://docs.langchain.com/oss/python/concepts/memory +- LangGraph streaming: https://docs.langchain.com/oss/python/langgraph/streaming +- LangGraph interrupts and human-in-the-loop: https://docs.langchain.com/oss/python/langgraph/interrupts \ No newline at end of file