Coming from ASP.NET Core

effx bridges enterprise frameworks and full-stack Effect. You write a familiar declarative surface (decorators or builder chains). The compiler reads it ahead of time and writes ordinary Effect that you can read, edit or keep. This page maps ASP.NET Core concepts onto that surface and says, row by row, what exists today (docs/decisions/0012-positioning-enterprise-on-ramp.md).

Pinned versions. ASP.NET Core claims cite learn.microsoft.com/aspnet/core at ASP.NET Core 10.0 (view=aspnetcore-10.0). As fetched on 2026-10-04 the .NET support policy lists .NET 10 as LTS in the active phase and .NET 11 as a release candidate. Two pages are not published for 10.0: the NSwag tutorial is cited at 8.0, and EF Core and Kiota live outside aspnet/core on Microsoft Learn. Effect claims cite the official clone at https://github.com/Effect-TS/effect/tree/b5a2d4c1d62c9620a68d72b7f20248c69ef7663b (github.com/Effect-TS/effect, commit b5a2d4c, package effect 4.0.0). effx claims cite a spec or a source path in this repository.

Read this first: what an attribute meansCopy Anchor Link

Concept mapCopy Anchor Link

HTTP surfaceCopy Anchor Link

Security and errorsCopy Anchor Link

The ASP.NET Core pages above describe their ProblemDetails type as based on RFC 7807 (web API controllers). RFC 9457 states "This document obsoletes RFC 7807" (RFC 9457).

Contract outputsCopy Anchor Link

Data and runtimeCopy Anchor Link

ToolingCopy Anchor Link

Gaps todayCopy Anchor Link

These are not planned unless a spec says so. Each cites why it is a gap.

• Persistence, SQL and migrations. Spec 0008 is proposed, not frozen, and STATE.md lists persistence as parked. @PersistentModel records facts only. Use effect/sql and a driver package by hand.
• Authorization evaluation. effx records the policy and requires a typed guard. It never resolves a credential, interprets a relationship, chooses a principal or issues a lease (spec 0006). Cedar and leases are deferred (ADR 0007). Spec 0006 also states that a required binding "is not proof that the handler called it".
• Automatic problem responses. There is no ProblemDetails type, no AddProblemDetails equivalent and no automatic 4xx mapping. The registry and the domain-error to problem conversion are application code until an explicit runtime mapping contract exists (spec 0005 §"Problem responses").
• Validation failure body. A request that fails decoding is an empty 400 by default. A ValidationProblemDetails style body needs HttpApiMiddleware.layerSchemaErrorTransform and your own error schema.
• Jobs, queues, scheduling. No annotation exists (packages/runtime/src/decorators.ts). The Effect modules in the table above are wired by hand.
• Caching and output caching. No annotation and no middleware generated.
• Realtime. No hub-style annotation. @Rpc is request and response over HTTP.
• Scaffolding and generators. No dotnet new template and no code generator for controllers or models. The CLI has four commands. It is not published.
• Testing harness. No generated or shipped fixture for WebApplicationFactory-style tests.
• Health checks. No Effect HTTP health-check module and no effx output. A /health route is hand-written (packages/effect/src/http/HttpRouter.ts:479).
• Staged filter pipeline. One HttpApiMiddleware wraps the whole endpoint. There are no resource or result stages.
• Custom annotations. A compiler extension registered in effx.config.ts gives a custom @Annotate name its meaning (Extensions, spec 0015). It adds IR and generated files; it does not add a runtime middleware or filter stage.

One endpoint, portedCopy Anchor Link

PATCH /users/{id}/email:

• The caller needs a permission to change an email address ([Authorize(Policy = "CanChangeEmail")]).
• The body { "email": "..." } is validated.
• 404 when the user does not exist and 409 when the email belongs to another user, both as problem responses.

using System.ComponentModel.DataAnnotations;

public sealed class ChangeEmailRequest
{
    [Required, EmailAddress]
    public string Email { get; init; } = "";
}

using Microsoft.AspNetCore.Authorization;

public sealed class ChangeEmailRequirement : IAuthorizationRequirement { }

public sealed class ChangeEmailHandler : AuthorizationHandler<ChangeEmailRequirement>
{
    protected override Task HandleRequirementAsync(
        AuthorizationHandlerContext context, ChangeEmailRequirement requirement)
    {
        if (context.User.HasClaim("permission", "users:change-email"))
        {
            context.Succeed(requirement);
        }

        return Task.CompletedTask;
    }
}

builder.Services.AddControllers();
builder.Services.AddProblemDetails();
builder.Services.AddScoped<IUserService, UserService>();
builder.Services.AddAuthorizationBuilder()
    .AddPolicy("CanChangeEmail", policy => policy.Requirements.Add(new ChangeEmailRequirement()));
builder.Services.AddSingleton<IAuthorizationHandler, ChangeEmailHandler>();
// Authentication scheme registration (JWT bearer, cookies, ...) is omitted.

using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("users")]
public sealed class UsersController : ControllerBase
{
    private readonly IUserService _users;

    public UsersController(IUserService users) => _users = users;

    [HttpPatch("{id}/email")]
    [Authorize(Policy = "CanChangeEmail")]
    [ProducesResponseType(StatusCodes.Status200OK)]
    [ProducesResponseType(StatusCodes.Status404NotFound)]
    [ProducesResponseType(StatusCodes.Status409Conflict)]
    public async Task<IActionResult> ChangeEmail(string id, ChangeEmailRequest request)
    {
        switch (await _users.SetEmailAsync(id, request.Email))
        {
            case SetEmailResult.Updated updated:
                return Ok(updated.User);
            case SetEmailResult.NotFound:
                return NotFound();
            default:
                return Problem(
                    statusCode: StatusCodes.Status409Conflict,
                    title: "Email already in use");
        }
    }
}

public interface IUserService
{
    Task<SetEmailResult> SetEmailAsync(string id, string email);
}

public abstract record SetEmailResult
{
    public sealed record Updated(UserSelf User) : SetEmailResult;
    public sealed record NotFound : SetEmailResult;
    public sealed record EmailTaken : SetEmailResult;
}

public sealed record UserSelf(string Id, string Email, string DisplayName);

Construct by constructCopy Anchor Link

What the port preserves, and what it does notCopy Anchor Link

Preserved (by construction or by cited source):

• The verb, the route and the single operation name.
• Request validation before application code runs. The handler cannot see an invalid email.
• A 404 and a 409 for the two domain failures, each as application/problem+json with the RFC 9457 members type, title and status.
• Both failures appear in the handler's type (E), in @Errors, in the endpoint's error option, in the OpenAPI document and in the generated client's error type. ASP.NET Core lists them in [ProducesResponseType] by hand.
• The access declaration is data in the IR (AccessContract, spec 0006). It is not code that the framework runs.

Not preserved:

• Access evaluation stays application code. [Authorize(Policy = "...")] runs in the framework before the action. In effx, Http.Access records the policy and the generated handler passes a lazy authorize() thunk. If the handler never calls it, nothing denies the request. Spec 0006: "A required typed binding is not proof that the handler called it"; the real gate is an end-to-end run of your own journey.
• No traceId and no ClientErrorMapping. For controllers, ASP.NET Core turns every error status code (400 and above) into a ProblemDetails body by default (web API controllers). effx returns a problem body only for the codes in Http.Problems.codes. A status without a code is not a problem body.
• Problem responses follow spec 0005. The registry, the body shape and the domain-error conversion are yours. The compiler diagnoses an unmapped error (EFFX2205) and a mapping to an absent code (EFFX2206) and nothing else.
• Validation failures are empty 400s. ASP.NET Core returns ValidationProblemDetails for invalid model state. Effect returns an empty 400 unless you add HttpApiMiddleware.layerSchemaErrorTransform.
• RFC 7807 versus 9457. The ASP.NET Core pages describe 7807. This port uses the 9457 media type and members.
• The email rule differs. The pattern is the application's own, not the [EmailAddress] attribute.
• Storage differs. examples/users uses an in-memory Ref<HashMap>, not EF Core; writes do not survive a restart (STATE.md, "Deferred / notes"). The uniqueness check is in Users.setEmail, not a database constraint.
• The 401 challenge is yours. ASP.NET Core's authentication middleware issues it. In effx the UserSecurity Layer you write decodes the credential and fails with AccessDenied.
• Not compiled here. Nothing on this page was built or run for this version of the page. The C# is illustrative and the TypeScript extension is assembled from compiled fixtures.

NextCopy Anchor Link