6 ms·

Show HN: Funcy – AWS Lambda strongly typed, best practice

9 points by bjohnm 2y ago

Hi, Please check out my new library funcy. It's really simplified AWS Lambda APIs in my projects, so I thought I would open-source it. It strongly-types all request parameters, has support for CORS, content-negotiation, security headers, etc.. out of the box and works via a very simply declarative interface with progressive disclosure. It's currently pre-release, let me know what you think :)

mlhpdx 2y ago
Is there no equivalent of Amazon.Lambda.APIGatewayEvents as provided for .Net?
- bjohnm 2y ago
  You'll notice in those models that body, path, query string, etc. are all strings. There is no validation of data type at runtime, and no strong typing to models at compile/transpile time. This library allows you do redefine the APIGatewayEvents style models so that they are specific to your types, with inbuilt validation. It also supports a full middleware pipeline under the covers for common concerns.
  - mlhpdx 2y ago
    Ah, that makes sense. Strangely enough, though I use a statically typed language for Lambdas I stopped using in in-built coercion to the type in the handler signatures somewhere along the line. These days I’m almost always skipping the extra dependencies (usually a shared library for the POCOs, and more) and just process the JSON object literally, and produce one as a result. It’s been a good thing I think on my projects; smaller, simpler code.
coronapl 2y ago
Really cool project! I’ve actually been searching for something like this. I’ve experimented with Hono and tRPC to achieve similar results, but it felt like overkill. I prefer to keep my Lambda functions small, with each one serving only a single API endpoint.
- bjohnm 2y ago
  Thanks! yeah I also used tRPC for a while, but it's not exactly what I wanted. I wanted a simple way to write REST APIs with Lambda without repeating myself with responsibilities that I don't believe should belong in the function handler code itself.
hughesjj 2y ago
Any chance this supports smithy?
- bjohnm 2y ago
  I'm not familiar with smithy, will take a look.

9 points by bjohnm 2y ago

mlhpdx 2y ago

Is there no equivalent of Amazon.Lambda.APIGatewayEvents as provided for .Net?

bjohnm 2y ago
You'll notice in those models that body, path, query string, etc. are all strings. There is no validation of data type at runtime, and no strong typing to models at compile/transpile time. This library allows you do redefine the APIGatewayEvents style models so that they are specific to your types, with inbuilt validation. It also supports a full middleware pipeline under the covers for common concerns.
- mlhpdx 2y ago
  Ah, that makes sense. Strangely enough, though I use a statically typed language for Lambdas I stopped using in in-built coercion to the type in the handler signatures somewhere along the line. These days I’m almost always skipping the extra dependencies (usually a shared library for the POCOs, and more) and just process the JSON object literally, and produce one as a result. It’s been a good thing I think on my projects; smaller, simpler code.

coronapl 2y ago

Really cool project! I’ve actually been searching for something like this. I’ve experimented with Hono and tRPC to achieve similar results, but it felt like overkill. I prefer to keep my Lambda functions small, with each one serving only a single API endpoint.

bjohnm 2y ago
Thanks! yeah I also used tRPC for a while, but it's not exactly what I wanted. I wanted a simple way to write REST APIs with Lambda without repeating myself with responsibilities that I don't believe should belong in the function handler code itself.

hughesjj 2y ago

Any chance this supports smithy?

bjohnm 2y ago
I'm not familiar with smithy, will take a look.