.filter(), and most importantly,
.reduce(). If you are unfamiliar with these concepts, go get a grasp on them first.
In my 20+ years of programming, I’ve encountered a near endless amount of opinions on everything from coding styles to programming paradigms to the great whitespace debate. Obviously, I have strong opinions on a number of these. But for me, the one that bothers me the most is this notion that “code is self-documenting.” 😾
I know what you’re probably thinking: “of course not all code is self-documenting, only well-written code is.” I don’t entirely disagree. I can generally look at someone else’s code and understand exactly WHAT it is doing. However, often it’s not obvious WHY they did it that way, or even why they did it in the first place. In my opinion, the programmer’s intent (the WHY) is just as important as the HOW when it comes to properly documenting software.
So whether you agree with me or not, let’s explore how to better document our software by writing cleaner code, following some general commenting etiquette, and commenting more effectively to make you and your team more productive. 👍
So you’ve decided to build a serverless application. That’s awesome! May I be the first to welcome you to the future. 🤖 I bet you’ve done a lot of research. You’ve probably even deployed a few test functions to AWS Lambda or Google Cloud Functions and you’re ready to actually build something useful. You probably still have a bunch of unanswered questions, and that’s cool. We can still build some really great applications even if we only know the basics. However, when we start working with new things we typically make a bunch of dumb mistakes. While some are relatively innocuous, security mistakes can cause some serious damage.
I’ve been working with serverless applications since AWS launched Lambda in early 2015. Over the last few years I’ve developed many serverless applications covering a wide range of use cases. The most important thing I’ve learned: SECURE YOUR FUNCTIONS! I can tell you from personal experience, getting burned by an attack is no bueno. I’d hate to see it happen to you. 😢
To make sure it doesn’t happen to you, I’ve put together a list of 🔒Serverless Security Best Practices. This is not a comprehensive list, but it covers the things you ABSOLUTELY must do. I also give you some more things to think about as you continue on your serverless journey. 🚀
I know the title is a quite a mouthful, but if you are trying to run tests on your Lambda functions that interact with AWS Services using the
aws-sdk node module, then you’ve probably run into an issue stubbing or mocking the requests. In this post we’ll learn how to stub different AWS Services with Sinon.JS so that you can properly test your scripts.
UPDATE: AWS Lambda now supports Node v8.10, so we can use
async/await instead of promises. The examples below still work with either v6.10 or v8.10, however, I recommend switching to
async/await as they are more compact than promises. Read my post How To: Stub “.promise()” in AWS-SDK Node.js to learn how to deal with the
.promise() method on aws-sdk services.
Let’s say you have a Lambda function that interacts with AWS’s SQS (Simple Queue Service). v6.10 of Node doesn’t support
async/await, so you will most likely use promises if you don’t want to transpile your code or deal with callback hell. This means you need to Promisify an instance of the AWS SQS service. This is easy enough with:
const AWS = require('aws-sdk') // AWS SDK
const Promise = require('bluebird') // Promise library
const SQS = Promise.promisifyAll(new AWS.SQS())
I’ve been writing and maintaining so many Node.js scripts lately that I’ve lost count. Node modules allow you to extend scripts to do just about anything you need. There are several Node.js modules that I find myself using over and over again in nearly every project I work on. Here are a few of my favorites that I’m sure will make writing your Node.js scripts easier and more bulletproof. All of these modules are well-documented and supported.
Update 9/2/2018: I wrote an NPM module that manages MySQL connections for you in serverless environments. Check it out here.
I work with AWS Lambda quite a bit. The ability to use this Functions-as-a-Service (FaaS) has dramatically reduced the complexity and hardware needs of the apps I work on. This is what’s known as a “Serverless” architecture since we do not need to provision any servers in order to run these functions. FaaS is great for a number of use cases (like processing images) because it will scale immediately and near infinitely when there are spikes in traffic. There’s no longer the need to run several underutilized processing servers just waiting for someone to request a large job.
AWS Lambda is event-driven, so it’s also possible to have it respond to API requests through AWS’s API Gateway. However, since Lambda is stateless, you’ll most likely need to query a persistent datastore in order for it to do anything exciting. Setting up a new database connection is relatively expensive. In my experience it typically takes more than 200ms. If we have to reconnect to the database every time we run our Lambda functions (especially if we’re responding to an API request) then we are already adding over 200ms to the total response time. Add that to your queries and whatever additional processing you need to perform and it becomes unusable under normal circumstance. Luckily, Lambda lets us “freeze” and then “thaw” these types of connections.
Update 4/5/2018: After running some new tests, it appears that “warm” functions now average anywhere between 4 and 20ms to connect to RDS instances in the same VPC. Cold starts still average greater than 100ms. Lambda does handle setting up DB connections really well under heavy load, but I still favor connection reuse as it cuts several milliseconds off your execution time.
Function composition lets us combine multiple functions into steps that transform our data as it flows through them. It’s like an assembly line where each step alters the data in some way. Technically you don’t need to use functional code to create a composable function, but when you do, the result is clean, elegant, easily reasoned, and beautiful code.