Choose F# Web Framework
Choose the web surface before scaffolding. Keep the application's F# domain model,
HTTP host, persistence, and deployment decision explicit instead of treating a
framework DSL as the whole architecture.
Source Check
Inspect the repository and its locked packages first. When a current framework
behavior matters, use its official documentation before generating code:
Selection
| Need |
Default fit |
Why |
| Small service using standard ASP.NET endpoint conventions |
Minimal APIs |
Least extra framework surface; keep idiomatic F# modules around the host. |
| Composable middleware-style functional handlers |
Giraffe |
HttpHandler composition over the ASP.NET Core pipeline. |
| Lightweight functional API or full-stack server toolkit |
Falco |
Direct routing and response helpers with ordinary ASP.NET Core integration. |
| Endpoint-routing / Minimal-API-shaped F# DSL |
Oxpecker |
F# endpoint handlers and middleware on ASP.NET Core Endpoint Routing. |
| Established convention-heavy F# MVC application |
Saturn |
Use only when its MVC/scaffolding shape is desired by the project. |
Do not select from popularity alone. Check existing package choices, team
experience, endpoint style, HTML/view needs, authentication, hosting, and how
much framework-specific API the project is willing to own.
Workflow
- Classify the application: API, HTML server app, webhook, internal tool,
background worker with health endpoints, or full-stack application.
- Inspect its existing ASP.NET Core host, package versions, test harness,
configuration, and deployment files.
- State the chosen framework and why the alternatives do not fit this project.
- Keep domain operations in F# modules independent of HTTP handlers.
- Use the matching framework skill for Giraffe, Falco, or Oxpecker. For Minimal
APIs use
dotnet:aspnet-core-service-workflow; for Saturn, inspect its local
conventions and official documentation before making framework-specific edits.
- Select the smallest useful test level and run
dotnet build plus the relevant
dotnet test command.
Boundaries
- SAFE Stack, Fable, Bolero, WebSharper, and browser-client architecture are
separate decisions; do not imply that a server framework selects a client.
- Keep F# compile order deliberate in
.fsproj files.
- Do not introduce a repository, service, or view-model layer merely to mirror a
framework's API. Name the concrete external dependency or reuse boundary first.
- For Azure architecture, provisioning, diagnostics, or deployment, hand off to
the official Microsoft Azure Skills plugin through the cloud deployment routing
workflow; do not duplicate its MCP or infrastructure guidance here.
Output
Return the application shape, selected framework, rejected alternatives, host and
domain ownership, test approach, Azure handoff if applicable, and exact validation
commands.
1---2name: choose-fsharp-web-framework3description: Choose an F# web application framework before implementation, comparing ASP.NET Core Minimal APIs, Giraffe, Falco, Oxpecker, and Saturn by application shape, composition model, dependencies, testing, and deployment boundaries.4---56# Choose F# Web Framework78Choose the web surface before scaffolding. Keep the application's F# domain model,9HTTP host, persistence, and deployment decision explicit instead of treating a10framework DSL as the whole architecture.1112## Source Check1314Inspect the repository and its locked packages first. When a current framework15behavior matters, use its official documentation before generating code:1617- [ASP.NET Core Minimal APIs](https://learn.microsoft.com/aspnet/core/fundamentals/minimal-apis)18- [Giraffe](https://giraffe.wiki/)19- [Falco](https://github.com/falcoframework/Falco)20- [Oxpecker](https://lanayx.github.io/Oxpecker/src/Oxpecker/)21- [Saturn](https://saturnframework.org/)2223## Selection2425| Need | Default fit | Why |26| --- | --- | --- |27| Small service using standard ASP.NET endpoint conventions | Minimal APIs | Least extra framework surface; keep idiomatic F# modules around the host. |28| Composable middleware-style functional handlers | Giraffe | `HttpHandler` composition over the ASP.NET Core pipeline. |29| Lightweight functional API or full-stack server toolkit | Falco | Direct routing and response helpers with ordinary ASP.NET Core integration. |30| Endpoint-routing / Minimal-API-shaped F# DSL | Oxpecker | F# endpoint handlers and middleware on ASP.NET Core Endpoint Routing. |31| Established convention-heavy F# MVC application | Saturn | Use only when its MVC/scaffolding shape is desired by the project. |3233Do not select from popularity alone. Check existing package choices, team34experience, endpoint style, HTML/view needs, authentication, hosting, and how35much framework-specific API the project is willing to own.3637## Workflow38391. Classify the application: API, HTML server app, webhook, internal tool,40 background worker with health endpoints, or full-stack application.412. Inspect its existing ASP.NET Core host, package versions, test harness,42 configuration, and deployment files.433. State the chosen framework and why the alternatives do not fit this project.444. Keep domain operations in F# modules independent of HTTP handlers.455. Use the matching framework skill for Giraffe, Falco, or Oxpecker. For Minimal46 APIs use `dotnet:aspnet-core-service-workflow`; for Saturn, inspect its local47 conventions and official documentation before making framework-specific edits.486. Select the smallest useful test level and run `dotnet build` plus the relevant49 `dotnet test` command.5051## Boundaries5253- SAFE Stack, Fable, Bolero, WebSharper, and browser-client architecture are54 separate decisions; do not imply that a server framework selects a client.55- Keep F# compile order deliberate in `.fsproj` files.56- Do not introduce a repository, service, or view-model layer merely to mirror a57 framework's API. Name the concrete external dependency or reuse boundary first.58- For Azure architecture, provisioning, diagnostics, or deployment, hand off to59 the official Microsoft Azure Skills plugin through the cloud deployment routing60 workflow; do not duplicate its MCP or infrastructure guidance here.6162## Output6364Return the application shape, selected framework, rejected alternatives, host and65domain ownership, test approach, Azure handoff if applicable, and exact validation66commands.