Thanks Dave, very keen to hear about that. I’ll get your local bottle shop (does that phrase translate to the US?) to ship the team friday drinks when you release it! 100 simultaneous requests isn’t a lot, I’ll easily breach that soon, and its unnecessary cost and complexity for Particle to handle it.
ps, for posterity, the team may be interested in this:
- You want AWS lambda to succeed/fail as appropriate, you shouldn’t massage this based on particle’s feelings as it will affect invocation request error reporting/alarms etc throughout the AWS toolchain
- You can massage status codes in the reply Integration Response within http gateway.
The interesting tricks that I spent about 10 hours on is:
- AWS will only allow one transformation per returned status object. Hence you can’t look for multiple strings (status":50\d / status":40\d) and come back to a common mapping. To keep particle you need to pretty much map anything but really really serious fatal flaws as 200. This means lambda errors and lambda successes, which come back differently from lambda.
- Even if you parseJSON the escaped JSON string in the body reply, you cannot then do conditional logic on a property (ie, 'myjsonstructure.elephants == 2). However if you returned an error via a proper javascript error object it doesn’t escape, its pure json. Then you can look at properties. So test the error object not the potential body return.
This looks really simple, but it wasn’t, and highly counterintuitive:
#set ($errorMessageObj = $util.parseJson($input.path('$.errorMessage')))
#set ($bodyObj = $util.parseJson($input.body))
#if($errorMessageObj.status == "")
$bodyObj
#{else}
$input.path('$.errorMessage')
#end