Build Giraffe Web App
Use Giraffe's functional handler composition as the HTTP boundary, not as a
reason to place business rules in route declarations.
Source Check
Inspect the existing host, package lock or project references, handlers, tests,
and configuration first. Use the Giraffe documentation
and ASP.NET Core documentation when
repository evidence is insufficient.
Workflow
- Confirm that Giraffe is already selected; otherwise use
dotnet:choose-fsharp-web-framework first.
- Keep request parsing, authentication context, and response writing in narrow
HttpHandler functions. Compose reusable HTTP concerns with >=> only when
they have one clear request-pipeline responsibility.
- Put domain transformations and external-dependency contracts in separately
testable F# modules. Pass dependencies explicitly or resolve genuine host
dependencies at a clear ASP.NET Core boundary.
- Preserve ASP.NET Core ordering: routing, authentication, authorization,
static files, exception handling, and Giraffe middleware must remain aligned
with the application's existing host contract.
- Make response errors specific: route, failed input or dependency, and the
safe client-facing outcome. Do not leak secrets or internal exception details.
- Test pure domain behavior first, then handler or host behavior for route,
authorization, binding, status, and response regressions.
Validation
Use the narrowest project commands available, normally:
dotnet build <web-project.fsproj>
dotnet test <test-project.fsproj>
Do not run a live deployment or add a replacement middleware stack merely to
exercise one handler.
Boundaries
- Keep
.fsproj file order valid as modules are added.
- Use ordinary ASP.NET Core middleware and services when that is the existing
integration surface; do not reimplement them as Giraffe helpers.
- Route Azure hosting, identity, resource configuration, and deployment work to
the official Azure Skills plugin through
cloud-deployment-routing-workflow.
1---2name: build-giraffe-web-app3description: Build or modify a Giraffe web application in idiomatic F#, using composable HttpHandler functions, explicit ASP.NET Core integration, configuration, authentication, and focused endpoint tests.4---56# Build Giraffe Web App78Use Giraffe's functional handler composition as the HTTP boundary, not as a9reason to place business rules in route declarations.1011## Source Check1213Inspect the existing host, package lock or project references, handlers, tests,14and configuration first. Use the [Giraffe documentation](https://giraffe.wiki/)15and [ASP.NET Core documentation](https://learn.microsoft.com/aspnet/core/) when16repository evidence is insufficient.1718## Workflow19201. Confirm that Giraffe is already selected; otherwise use21 `dotnet:choose-fsharp-web-framework` first.222. Keep request parsing, authentication context, and response writing in narrow23 `HttpHandler` functions. Compose reusable HTTP concerns with `>=>` only when24 they have one clear request-pipeline responsibility.253. Put domain transformations and external-dependency contracts in separately26 testable F# modules. Pass dependencies explicitly or resolve genuine host27 dependencies at a clear ASP.NET Core boundary.284. Preserve ASP.NET Core ordering: routing, authentication, authorization,29 static files, exception handling, and Giraffe middleware must remain aligned30 with the application's existing host contract.315. Make response errors specific: route, failed input or dependency, and the32 safe client-facing outcome. Do not leak secrets or internal exception details.336. Test pure domain behavior first, then handler or host behavior for route,34 authorization, binding, status, and response regressions.3536## Validation3738Use the narrowest project commands available, normally:3940```zsh41dotnet build <web-project.fsproj>42dotnet test <test-project.fsproj>43```4445Do not run a live deployment or add a replacement middleware stack merely to46exercise one handler.4748## Boundaries4950- Keep `.fsproj` file order valid as modules are added.51- Use ordinary ASP.NET Core middleware and services when that is the existing52 integration surface; do not reimplement them as Giraffe helpers.53- Route Azure hosting, identity, resource configuration, and deployment work to54 the official Azure Skills plugin through `cloud-deployment-routing-workflow`.
gaelic-ghost