The biggest issue I discovered over time with the previous method of Lambda design in F# was in difficulty controlling the HTTP Result codes returned by my functions. I believe the previous strategy required you to do quite a bit of custom data mapping in API Gateway, such that APIGW could parse some part of your response to deduce the HTTP Result Code to be returned to the client, which sounded quite undesirable to me.
A better (in my opinion, and depending on your use case) way to design your lambda functions is using what AWS calls “Lambda Proxy Integration” which I think is somewhat recently added.
This feature is enabled in the API Gateway on (I believe) a per-Resource-and-HTTP-Verb basis. You click a resource, then click a verb, then click on “Integration Request” and you should see a checkbox labeled “Use Lamba Proxy Integration” to enable this feature. (and of course deploy the changes)
Once this is enabled (and you add package Amazon.Lambda.APIGatewayEvents), you can write lambda functions more like:
let handler(request:APIGatewayProxyRequest, context:ILambdaContext) : APIGatewayProxyResponse =
... // do the things
with the kicker being that AWS no longer controls the (de)serialization, so as an alternative you can deserialize the request.Body in any way you please (and you can remove that assembly-level attribute that I mentioned in the previous message). Also if you google the full names of either of these request/response types and just quickly peruse their source, you can see that they both give you control over the full complement of HTTP Artifacts, accessing the headers in the request and setting them in the response. Controlling the HTTP result codes, and so on. The whole Lambda experience begins to feel much more like working with typical web frameworks.
In fact, to take it one step further, there’s this
which, IF I’m reading it correctly (and that’s a BIG “if,” because I’ve never done/used this before), it looks like you can indeed integrate a conventional web framework into Lambda, with a bit of configuration, such that the web application handles all of the routing to the various code functions, just like it would if the web framework and attendant code were running in a non-Lambda context.
So my guess is that this would allow you to dump an entire existing (or new) web app into a single lambda, with a single small bit of API Gateway configuration, and then just keep pushing code as your project expands and grows, but without (as far as I can see) needing to touch the initial AWS part of the configuration much ever, if at all. This would truly be a god-send for infrastructure haters such as myself.
One other thing I just thought of - I’ve written all of this under the assumption that you’ll be using API Gateway to trigger Lambda. Saw a list recently showing that AWS had added proxy integrations for maybe 6-8 other AWS services that can trigger your Lambda as well. Presumably the steps would all be the same, save for different nuget packages, and different object types in your “handler” function’s signature.
Hope this helps. It’s a little bit confusing/overwhelming to start, but I’ve come to really like Lambda quite a lot, and F# has been a fabulous pairing for it.