Serverless has become an amazing tool for various use cases. Data processors, chatbots, APIs, you name it is now developed using serverless archite...
For further actions, you may consider blocking this person and/or reporting abuse
Thanks, that was a good documentation of the steps needed, with explanation.
So when we deploy this in AWS, does a new MongoDB connection gets created for every request or should we implement the caching patter that you have documented in
dev.to/adnanrahic/solving-invisibl...
It's already cached. Check this comment. 😄
I'm glad you found this article helpful!
What I mean is, in your other couple of courses you have used the below code in db.js to re-use existing connection, but not in this course, so I am wondering how is it cached & re-used for subsequent requests.
Code I am referring to, from other courses:
const mongoose = require('mongoose');
let isConnected;
module.exports = connectToDatabase = () => {
if (isConnected) {
console.log('=> using existing database connection');
return Promise.resolve();
}
console.log('=> using new database connection');
return mongoose.connect(process.env.DB) // keep the connection string in an env var
.then(db => {
isConnected = db.connections[0].readyState;
});
};
You see the
isConnectedvariable?That's what's checking if the mongoose connection is established. If it's true then mongoose won't connect again. 😄
The logic with isConnected variable, that I mentioned in my previous reply is from your other posts, but in this post you seem to have no used this logic with isConnected variable in the db.js, so that's why I was confused.
So are you saying this isConnected logic is needed so that every request doesn't create a new connection?
I understand that this is a 2 years old post & you may not remember what is in the code of this post versus the other posts of your.
So, request you to please check & confirm if the db.js code mentioned in this post also uses cached connection & if yes how?
For your quick reference below is the db.js code in this post:
// ./lib/db.js
const mongoose = require('mongoose')
mongoose.connect(process.env.DB)
I saw the comment, but was a bit confused when I saw your other post on scaling issues with Serverless & mongoDB, where you had taken care of re-using the connection in the code & in this article there is no caching related code. So how is it cached without any explicit code? does the mongoose.connect take care of not creating a new connection when there is an open connection?
Thanks the info. I could able to get this working but I noticed that each call to the api is creating new connection to mongo and is not closed unless I explicitly close the mongoose connection at the end of each function call. Is this the correct approach to handle mongo connections in serverless?
It's not creating a new connection for every call. What's happening is that every time a lambda function is created the connection is pooled and kept alive for that instance. Every subsequent invocation that runs in that instance of the lambda function will re-use the already opened connection.
This is the preferred behavior of accessing databases with serverless functions. Cache the connection so it can be re-used as long as the function is alive. Once the function is destroyed, the connection will be closed.
Thanks Adnan. I had my offline serverless started without "--skipCacheInvalidation" which was causing to create new connection for every call.. Add the --skipCacheInvalidation resolved the issue.
But with --skipCacheInvalidation every time I need to manually restart the offline app to load my changes which is difficult for the development.. the document says that nodemon should be combined with it but not sure how to do that.. Appreciate if you could share how that is setup for development debugging..
Getting note is not defined at notesController.post having a hard time figuring out why that would be not defined
That's strange. Is it undefined because of bad request parameters or is Mongoose not posting to the database at all?
This always happens, I figured it out right after I sent that to you. It was a total brain malfunction on my part. Since I adapted your tutorial for an api using boards instead of notes I did a find a replace changing all of note to board but I didn't take into account the uppercase. I haven't had caffeine yet today, brain not working yet!
Anyways, I really enjoyed your tutorial! I don't find many I like but yours killed it. Thanks!
Sweet! Glad you liked it.
Thanks so much for the write-up. It is very informative, however I have been unable to get the code to function. What would be a good forum to ask troubleshooting questions?
Feel free to write here about the issues you're facing. Another thing you can do is to check the code in the repo and see what you're doing wrong.
A crash course on serverless APIs with Express and Mongodb
Quick and easy tutorial on how to create a serverless API and deploy it to AWS Lambda. Persistent data is stored in MongoDB on Atlas clusters. Check out the whole tutorial here.
I have used serverless and express. It works perfectly for most of the time but sometimes i get 502 bad gateway (internal server error). kindly help me to fix this.
How much does it cost monthly this implementation? I'm curios about starting on AWS because the pricing is sometimes a little confusing (I'm using Google Cloud currently)
It's rather cheap for hosting apps of this type. Here are a couple of calculators you can use to estimate the price of both Lambda and API Gateway. Have in mind you'll be paying for MongoDB Atlas separately. Here's their pricing calculator.
If you want to see how big of a difference having a serverless architecture is, read this Twitter thread by Troy Hunt.