SliceFx.Wasi.KeyValue 0.1.0-preview.7

SliceFx

One feature file per endpoint. Generated ASP.NET Core registration, checks, clients, and portability hints.

Website: https://sano-suguru.github.io/slicefx/

SliceFx is an experimental .NET framework for teams that like ASP.NET Core Minimal APIs but do not want route strings, DTOs, validation, filters, clients, and deployment checks to drift apart. A feature is one static class with its request, response, handler, validation, and filters in one place. The generator emits standard Minimal API registrations plus a route manifest for tooling, AOT-friendly startup, Lambda experiments, and WASI/WebAssembly dispatch.

Curious about the design choices? See Design decisions FAQ and Production readiness criteria.

Why use SliceFx?

SliceFx doesn't restrict any ASP.NET feature. For authorization, rate limiting, caching, CORS, and custom validation patterns see What you keep.

SliceFx is not a replacement for ASP.NET Core. It is a generated vertical-slice layer around Minimal APIs for teams that want explicit feature files, generated contracts, and portability checks without adopting a mediator stack or custom endpoint pipeline.

SliceFx compiles down to standard WebApplication.MapMethods calls — removing the source generator reference and expanding the generated output in place is the full exit path. For teams already on FastEndpoints or similar, SliceFx fills a different niche: compile-time portability classification across ASP.NET, Lambda, and wasi:http, not a richer filter and pipeline ecosystem.

Existing ASP.NET Core apps do not need a rewrite. Start with one endpoint, keep the rest of the app on controllers or handwritten Minimal APIs, and use the migration audit plus contract checks to evaluate the shape. See migrating from Minimal APIs and migrating from controllers.

Latest benchmark results

Each endpoint is a static feature file: request, response, validation, filters, and handler stay together. The source generator turns those features into ASP.NET registrations, route metadata for tooling, Lambda handlers, or wasi:http dispatch where the handler shape is portable.

dotnet run --project samples/SliceFx.Sample
curl http://localhost:5099/health

Project status

SliceFx is pre-1.0 experimental software. Preview packages use 0.x versions until the API is intentionally stabilized.

Release status: 0.1.0-preview.6 is the latest preview release. Install from NuGet:

dotnet add package SliceFx.Core --version 0.1.0-preview.6
dotnet add package SliceFx.SourceGenerator --version 0.1.0-preview.6

See the package table for satellite packages. NuGet package pages: SliceFx.Core, SliceFx.SourceGenerator, SliceFx.Cli.

SDK and analyzer policy: the repository targets .NET 10 with SDK 10.0.300 pinned in global.json and rollForward: latestFeature. Warnings and code-analysis diagnostics are treated as errors, but the analyzer recommendation set is pinned to 10.0-recommended so normal PR/main builds do not unexpectedly break when a newer SDK promotes analyzer rules. A separate analyzer canary workflow checks the latest .NET 10 analyzer behavior and reports drift for dedicated maintenance PRs.

WASI support (SliceFx.Wasi) is experimental and depends on an unstable upstream toolchain: componentize-dotnet, NativeAOT-LLVM preview packages, WASI Preview 2 / wasi:http@0.2, and Cloudflare's JS transpile/shim path when targeting Workers. Native WASI publish requires Linux x64 or Windows x64; macOS requires a Linux x64 Docker cross-build. "Experimental" means SliceFx.Wasi's own 0.x API may change; "unstable upstream toolchain" means those external build and deployment tools may break independently of SliceFx runtime code.

All adapters are opt-in. Reference only the packages you need; the source generator emits code only for the surfaces you reference. An ASP.NET-only app uses just SliceFx.Core and SliceFx.SourceGenerator.

Add SliceFx.Core and SliceFx.SourceGenerator at the same preview version:

dotnet add package SliceFx.Core --version 0.1.0-preview.6
dotnet add package SliceFx.SourceGenerator --version 0.1.0-preview.6

Hello, SliceFx

Program.cs:

var builder = WebApplication.CreateSlimBuilder(args);

builder.Services.AddSlice();
builder.Services.AddSingleton<IUserStore, InMemoryUserStore>();

var app = builder.Build();

app.MapSlices();
app.Run();

Features/Users/CreateUser.cs:

namespace SliceFx.Sample.Features.Users;

[Feature("POST /users", Summary = "Create a new user")]
public static class CreateUser
{
    public record Request(
        [Required, MinLength(2)] string Name,
        [Required, EmailAddress] string Email);

    public record Response(Guid Id, string Name, string Email, DateTime CreatedAt);

    public static async Task<Response> Handle(Request req, IUserStore store, CancellationToken ct)
    {
        var user = await store.AddAsync(req.Name, req.Email, ct);
        return new Response(user.Id, user.Name, user.Email, user.CreatedAt);
    }
}

The generator discovers [Feature] classes, emits AddSlice() / MapSlices(), wires Minimal API binding, and attaches validation. Prefer plain response records for portable endpoints. Use IResult when the feature intentionally needs ASP.NET-specific response helpers such as Results.NotFound() or Results.NoContent().

DI binding note: On the ASP.NET path binding is plain Minimal API — any registered service (concrete or interface) resolves from DI automatically, identical to raw Minimal API. Annotate concrete service params with [FromServices] (keyed services with [FromKeyedServices(key)]) only if you want the handler portable across ASP.NET, WASI, and Lambda — the portable-dispatch generator cannot probe the DI container at compile time. See docs/guides/parameter-binding.md and samples/SliceFx.Sample/Features/Users/PromoteUser.cs.

Filters and validation

Feature filters are standard ASP.NET Core IEndpointFilter types:

[Feature("DELETE /users/{id:guid}", Summary = "Delete a user")]
[Filter<RequestLoggingFilter>]
[Filter<RequireApiKeyFilter>]
public static class DeleteUser
{
    public static async Task<IResult> Handle(Guid id, IUserStore store, CancellationToken ct)
    {
        var user = await store.GetAsync(id, ct);
        if (user is null) return Results.NotFound();
        await store.RemoveAsync(id, ct);
        return Results.NoContent();
    }
}

AddSlice() registers referenced filters and matching validators as scoped services, and [Filter<T>] applies filters in declaration order. Supported DataAnnotations rules are generated and run first; closed ISliceValidator<TRequest> implementations are discovered when TRequest is a Slice request parameter and run automatically before feature filters for rules that need code. A request type can have one Slice validator; orphan validators fail the build so validation is never skipped silently.

For production authorization policies, prefer ASP.NET Core Authorization. Slice filters are best for explicit per-feature endpoint filter behavior.

Read more:

• Filter declarations
• Filter configuration
• Return-type guidance
• ASP.NET features and escape hatches

What you keep

SliceFx generated code is pure Minimal API expansion — the full ASP.NET surface stays available.

Features you keep on every endpoint:

• ASP.NET Core Authorization — [Authorize], policies, fallback policy, RequireAuthorization()
• Output caching — CacheOutput() via route group
• Rate limiting — RequireRateLimiting() via route group
• CORS — RequireCors() via route group
• Exception handling middleware and IProblemDetailsService
• [Filter<T>] endpoint filters with full IEndpointFilter access
• OpenAPI integration — builder.Services.AddOpenApi() / app.MapOpenApi()
• Standard Minimal API binding — [FromRoute], [FromQuery], [FromHeader], [FromForm], [FromServices], [FromKeyedServices]

Escape hatches for common needs:

For more detail see ASP.NET features and escape hatches.

What works today

The C# typed client reuses C# request/response types rather than generating DTO copies. Use nested feature DTOs when the client can reference the feature assembly; use non-nested DTOs in a shared contracts project when Blazor or another .NET client should reference contracts without referencing server features. The TypeScript client emits interfaces from built metadata. Routes returning SliceResult<T> generate Task<T> methods; routes returning the non-generic SliceResult generate Task (void) methods.

Adoption evidence

Portability

Most projects use all three portability classes in the same codebase — the classification tells tooling where a feature can run, not whether it is well-written.

The source generator classifies each feature endpoint at build time. slicefx routes reports the result; the same data drives typed-client generation, WASI route tables, and Lambda function-per-feature eligibility.

aspnet-only features are standard Minimal API endpoints with the complete ASP.NET ecosystem available — they are not penalized or degraded.

WASI and edge are optional

You do not need WASI or edge hosting to use SliceFx. The default path is still a normal ASP.NET Core app.

Edge usually means running code closer to users on platforms such as Cloudflare Workers or Fermyon Spin instead of only in one central server region. WASI is a standards-based way to package server-side code as a WebAssembly component that those hosts can run. In SliceFx, WASI support proves the portability story: if a feature returns plain request/response records and avoids ASP.NET-only response helpers, the same feature shape can be dispatched outside ASP.NET through a generated route table and SliceFx.Wasi.

That path is intentionally experimental. SliceFx.Wasi depends on preview tooling, has stricter JSON and validation rules, and does not run arbitrary ASP.NET endpoint filters. The practical deployment target today is one wasi:http component with generated in-process route dispatch, not one WASM component per feature. The practical benefit today is visibility: slicefx routes tells you which endpoints are portable, which are partially portable, and which intentionally stay ASP.NET-only.

OpenAPI

Slice endpoints work with ASP.NET Core's standard OpenAPI support out of the box. Add Microsoft.AspNetCore.OpenApi, call builder.Services.AddOpenApi(), and map app.MapOpenApi() in the ASP.NET host:

builder.Services.AddSlice();
builder.Services.AddOpenApi();

var app = builder.Build();
app.MapSlices();

if (app.Environment.IsDevelopment())
{
    app.MapOpenApi();
}

The Slice route manifest is a separate build-time artifact for portability classification, client generation, and slicefx openapi manifest projections. It complements rather than replaces the ASP.NET Core OpenAPI document. See docs/guides/openapi.md.

Tooling and adapters

Build & run

dotnet build
dotnet run --project samples/SliceFx.Sample

Then:

curl http://localhost:5099/health
curl -X POST http://localhost:5099/users \
  -H "Content-Type: application/json" \
  -d '{"name":"Alice","email":"alice@example.com"}'
curl -X DELETE http://localhost:5099/users/{id} -H "X-API-Key: secret"

License

MIT. See LICENSE.