Ever since software engineering became a profession, we have been trying to serve users all around the globe. With this comes the issue of scaling and how to solve it. Many times these thoughts of scaling up our software to unimaginable extents are premature and unnecessary. This has turned into something else altogether with the rise of serverless architectures and back-end-as-a-service providers. Now we’re not facing issues of how to scale up and out, but rather how to scale our database connections without creating heavy loads. With the reduced insight we have about the underlying infrastructure, there’s not much we can do except for writing and use to mitigate this issue. sturdy, efficient code appropriate tools Or is it? 🤔 How do databases work with serverless? With a traditional server, your app will connect to the database on startup. Quite logical, right? The first thing it does is hook up to the database via a connection string and not until that’s done, the rest of the app will initialize. handles this a bit differently. The code will actually run for the first time only once you trigger a function. Meaning you have to both initialize the database connection and interact with the database during the same function call. Serverless Going through this process time a function runs would be incredibly inefficient and time-consuming. This is why serverless developers utilize a technique called connection pooling to only create the database connection on the first function call and re-use it for every consecutive call. Now you’re wondering how this is even possible? every The short answer is that a lambda function is, in all essence, a tiny container. It’s created and kept for an extended period of time, even though it is not running all the time. Only after it has been inactive for over 15 minutes will it be terminated. warm This gives us a time frame of 15 to 20 minutes where our database connection is active and ready to be used without suffering any performance loss. Using Lambda with MongoDB Atlas Here’s a simple code snippet for you to check out. mongoose = ( ) connection = {} .exports = () => { (connection.isConnected) { .log( ) } .log( ) db = mongoose.connect(process.env.DB)
  connection.isConnected = db.connections[ ].readyState
} // db.js const require 'mongoose' const module async if console '=> using existing database connection' return console '=> using new database connection' const await 0 Once you take a better look at the code above you can see it makes sense. At the top, we’re requiring and initializing an object called . There's nothing more to it. We'll use the connection object as a cache to store whether the database connection exists or not. mongoose connection The first time the file is required and invoked it will connect mongoose to the database connection string. Every consecutive call will re-use the existing connection. db.js Here’s what it looks like in the handler which represents our lambda function. connectToDatabase = ( ) Model = ( ) .exports.create = (event) => { { db = connectToDatabase() object = Model.create( .parse(event.body)) { : , : .stringify(object)
    }
  } (err) { { : err.statusCode || , : { : }, : }
  }
} // handler.js const require './db' const require './model' module async try const await const JSON return statusCode 200 body JSON catch return statusCode 500 headers 'Content-Type' 'text/plain' body 'Could not create the object.' This simple pattern will make your lambda functions cache the database connection and speed them up significantly. Pretty cool huh? 😊 All of this is amazing, but what if we hit the cap of connections our database can handle? Well, great question! Here’s a viable answer. What about connection limits? If capping your connection limit has you worried, then you might think about using a back-end-as-a-service to solve this issue. It would ideally create a pool of connections your functions would use without having to worry about hitting the ceiling. Implementing this would mean the provider will give you a REST API which handles the actual database interaction while you only use the APIs. You hardcore readers will think about creating an API yourselves to house the connection pool or use something like GraphQL. Both of those solutions are great for whichever use case fits you best. But, I’ll focus on using off-the-shelf tools for getting up and running rather quickly. Using Lambda with MongoDB Stitch If you’re a sucker for MongoDB, like I am, you may want to check out their back-end-as-a-service solution called . It gives you a simple API to interact with the MongoDB driver. You just need to create a Stitch app, connect it to your already running Atlas cluster and your set. In the Stitch app, you make sure to enable anonymous login and create your database name and collection. Stitch Install the stitch npm module and reference your Stitch app id in your code then start hitting the APIs. { StitchClientFactory, BSON } = ( ) { ObjectId } = BSON appId = database = connection = {} .exports = () => { (connection.isConnected) { .log( ) connection
  } { client = StitchClientFactory.create(appId) db = client.service( , ).db(database) client.login() ownerId = client.authedId() .log( )

    connection.isConnected = connection.db = db
    connection.ownerId = ownerId
    connection.ObjectId = ObjectId connection
  } (err) { .error(err)
  }
} // db.js const require 'mongodb-stitch' const const 'notes-stitch-xwvtw' const 'stitch-db' const module async if console '[MongoDB Stitch] Using existing connection to Stitch' return try const await const 'mongodb' 'mongodb-atlas' await const console '[MongoDB Stitch] Created connection to Stitch' true return catch console As you can see the pattern is very similar. We create a Stitch client connection and just re-use it for every consequent request. The lambda function itself looks almost the same as the example above. connectToDatabase = ( ) .exports.create = (event) => { { { db } = connectToDatabase() { insertedId } = db.collection( )
      .insertOne( .parse(event.body)) addedObject = db.collection( )
      .findOne({ : insertedId }) { : , : .stringify(addedObject)
    }
  } (err) { { : err.statusCode || , : { : }, : }
  }
} // handler.js const require './db' module async try const await const await 'notes' JSON const await 'notes' _id return statusCode 200 body JSON catch return statusCode 500 headers 'Content-Type' 'text/plain' body 'Could not create the object.' Seems rather similar. I could get used to it. However, Stitch has some cool features out of the box like authentication and authorization for your client connections. This makes it really easy to secure your routes. How to know it works? To make sure I know which connection is being used at every given time, I use to check my logs. Dashbird’s invocation view Lambda Here you can see it’s creating a new connection on the first invocation while re-using it on consecutive calls. The service has a with a 14 day trial for unlimited features, so you can . if you want an extended trial or just . 😊 free tier check it out if you want Let me know join my newsletter Wrapping up In an ideal serverless world, we don’t need to worry about capping our database connection limit. However, the amount of users required to hit your APIs to reach this scaling issue is huge. This example above shows how you can mitigate the issue by using back-end-as-a-service providers. Even though is not yet mature, it is made by , which is an amazing database. And using it with is just astonishingly quick. Stitch MongoDB AWS Lambda To check out a few projects which use both of these connection patterns shown above jump over here: Building a Serverless REST API with MongoDB Building a Serverless REST API with Stitch If you want to read some of my previous serverless musings head over to or my profile join my newsletter! Or, take a look at a few of my other articles regarding serverless: How to deploy a Node.js application to AWS Lambda using Serverless Getting started with AWS Lambda and Node.js A crash course on securing Serverless APIs with JSON web tokens Migrating your Node.js REST API to Serverless Building a Serverless REST API with Node.js and MongoDB A crash course on Serverless with Node.js Hope you guys and girls enjoyed reading this as much as I enjoyed writing it. Hit that tiny heart for others to see this here on Medium. Until next time, be curious and have fun. Originally published at dev.to .

Amazon

A crash course on serverless-side rendering with Vue.js, Nuxt.js and AWS Lambda

Solving invisible scaling issues with Serverless and MongoDB

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

A crash course on Serverless APIs with Express and MongoDB

101 Stories To Learn About Cloud Infrastructure

10 Things in Engineering We Don't Spend Enough Time On

10 Things I Did To Increase CloudTrail Logs Security

10 reasons to give cloud computing a go

10 Lessons from 10 Years of AWS (part 1)

A crash course on Serverless APIs with Express and MongoDB

101 Stories To Learn About Cloud Infrastructure

10 Things in Engineering We Don't Spend Enough Time On

10 Things I Did To Increase CloudTrail Logs Security

10 reasons to give cloud computing a go

10 Lessons from 10 Years of AWS (part 1)

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps