Current Status and Roadmap for Lambda Annotations?

[dguisinger]

@normj I’m trying to get a sense of the current level of active development/support on Lambda Annotations.

It’s my preferred way to build Lambda functions in .NET. The ergonomics are a big improvement over raw handlers, and I rely on it heavily (I’ve even released an OpenAPI generator for Lambda Annotations projects).

I’ve noticed a number of long-standing issues and feature requests (path routing enhancements, serverless file suppression, etc.) that haven’t moved in a while. I’m currently at an architectural decision point where some additional routing flexibility (including potential ALB scenarios) would help, and I’m trying to understand whether that kind of work fits within the intended direction of the project.

Would contributions in that area be welcome, or is the project effectively in maintenance mode at this point?

[normj]

Hi @dguisinger, we are actually turning our focus back on annotations after needing to spend some time on other projects so this would be a great time for contributions. The current annotations feature is shepherding a PR we got for adding authorizer support.

Do you want to describe more what additional routing flexibility you need? And if you have any other annotations wish list features I would love to hear them.

[dguisinger]

Thanks @normj, glad to hear its not falling into maintenence mode.

We’ve been investing heavily in Lambda Annotations and have built two source-generator-based integrations on top of it (GraphQL/AppSync and OpenAPI), as well as using all of this in a large multi-repo/many microservice environment leading to some pain points.

1. Complete Http endpoint support

Right now Lambda Annotations supports HttpApi and RestApi. We would like to see an ALB endpoint and a FunctionUrl endpoint for maximum flexibility. {Proxy+} support would also be useful at times. What we would like to see is the ability to move back and forth with minimal code changes, allowing us to change the method of entry depending on architectual needs with maybe just a simple attribute change.

2. AppSync integration

We built a GraphQL/AppSync generator (soon to be made public) that allows C# to be the source of truth for resolver configuration and schema generation.
What we’d ideally like is the same clean method signature model annotations provides for API Gateway, e.g.:

GetProduct(string productId)

But today, to make that work with AppSync events, we must either:

• Perform non-trivial mapping in the resolver configuration, or
• Add transformation logic in our function code

There isn’t currently a way to reuse the parameter/header/context extraction model that RestApi / HttpApi provide for AppSync-style events.

3. OpenAPI integration and generator coordination

We also built an OpenAPI generator that sits on top of Lambda Annotations (https://lambdaopenapi.dev/).

One feature we wanted to support was automatically generating an endpoint that serves the OpenAPI document at runtime — similar to how ASP.NET exposes /swagger or /openapi.

However, Roslyn generators cannot see each other’s generated output. Without some kind of shared static registration point inside Lambda Annotations, we can’t cleanly “register” an additional route from another generator and have it participate in the routing pipeline.

If annotations exposed a stable registration surface for additional routes, that would enable much cleaner cross-generator integration.

4. Manifest / CDK integration and duplicate function control

We deploy exclusively with CDK.

In the AppSync integration, we generate a resolver manifest that includes LambdaAnnotations settings and feed it into CDK to build both Lambda functions and resolvers.

We’re considering something similar for the OpenAPI generator.

If annotations also emitted a manifest, it would be extremely helpful to have:

• A way to suppress Serverless Framework output
• A way to export a JSON-based function/route manifest
• A mechanism to exclude or categorize functions so multiple generators don’t accidentally define overlapping Lambdas

5. Documentation

Finally, more official documentation beyond the GitHub README would likely help adoption. It would also improve the ability of AI tooling to generate correct Lambda Annotations code, as currently there isn’t much structured material for it to learn from.

If any of this aligns with the direction you’re thinking, I’d be happy to explore contributing.

[normj]

This is great feedback! Thanks so much for passing it along.