Clojurians Log v2

@gonewest818 Hey, just saw your messages on here. That project is a bit out of date.

Proxy was painful and never worked well for me

As to logging, you sometimes need to manually turn on cloudwatch for an API in the AWS API page.

I too have been looking at sls, the java startup time was painful as hell

There is a slight error in the wrapper library that I worked around a bit in the real app we were writing with this stack

but I didn't port back to the presentation yet

It makes exceptions harder to see.

If you look at the resource directory, you can see the AWS api spec we were using

for that presentation, and see how it does not use proxy, and that worked

But you do have to be careful with IAM being setup well for each item.

The sls (aka, Serverless) project does stuff with AWS Cloudformation that helps set that all up

But basically: This stuff is all extremely poorly documented, and it's like pulling teeth to get logging of what is wrong a lot of time

I strongly suggest looking into the tool https://github.com/jorgebastida/awslogs

it's very helpful in getting cloudwatch logs that have meaningful info

I also believe at the time of my demo...amazon dynamodb + lambda had a slightly different permission model. You may need to make the dynamodb table with a different IAM permission level than you have to make this all work

thanks @mj_langford. Now that I’m using lambada directly I’ve stopped following the template from your presentation, and I’ve got something that’s fairly different. I’m still using lein-clj-lambda to deploy code and manage the API gateway. I’m logging with timbre. Next on my list is integrating dynamodb via faraday.

It hasn’t been effortless, to say the least. I had to fork and modify lein-clj-lambda to increase the timeout on another AWS api call that was taking longer than expected to succeed. (and it took me a while to recognize that the call would succeed if given more time). I also had to fork faraday and update it’s delared dependency on the aws java sdk to match other libraries in my project.

and it took me some time browsing logs and reading docs to figure out how the API gateway {proxy+} integration passes the path, body, and query parameters along to lambda. I was surprised I couldn’t find a document that simply said “you’re going to get an event, it’ll be json, it’s going to have a dictionary, and in that dictionary the keys you need are ‘path’ and ‘queryStringParameters’.”