On the project I’m working on with my friend Ingo, we decided to use aws lambda for a serverless app (well, Ingo decided and it’s been a great idea).
Basically, you write your app using claudiajs, and then deploy to the amazon infrastructure. Claudia uses the api gateway to send requests from a web address to your lambdas. It’s like deploying a node.js express app to heroku, except way cheaper (you pay nothing when the lambdas aren’t being triggered), and in theory — super scalable, AWS will just spin up as many lambdas as required.
Anyway, we’ve been having some problems with error logging with our app, the logs go to the aws logging service cloudwatch, but you have to dig around to find your requests that are failing. It’s a great logging service, but not a great error reporting service.
That’s where Raygun comes in. Raygun is an error tracking SaaS tool that was founded by two New Zealanders (one of whom, JD Trask was an advisor to my now defunct project SceneVR) - so I’m very partial to the service.
Raygun has a node.js api, and I hooked it up with process.on(‘uncaughtException’)… but I was having a problem that the errors, that showed up in cloudwatch, never showed up in raygun.
We’re using dynamodb (and rekognition and s3 and other AWS apis) extensively in our app, so we’re using the promise based version of their APIs.
In this case, we return a promise from our lambda request handlers. And what I discovered, is that as soon as those promises return, the lambda is shutdown, so any pending http requests (say the post to the raygun api) are cancelled, and your logs never end up in raygun (and thence in our slack channel with their awesome slack integration).
The way to fix this was to create a function that returned a promise that resolved when the raygun exception has been dispatched.
We then use this catchPromise() method as the last .catch() of our promise chain:
Here at the end of our promise chain, we .catch() any errors, and pass them to the error catching function. That function creates a promise that resolves when the raygunClient has completed.
Once I worked out that gotcha, raygun error logging worked perfectly, and we get our error messages posted to slack within 60 seconds of someone triggering them in the wild.
We’re currently just in alpha testing, so we’re only talking a handful of errors a day, but it’s been a great way to keep your finger on the pulse of the app.