I’m in the early stages of a new project, which is going to be a Koa server (Node) utilizing the MongoDB Node driver. Fair warning: I may not use exactly correct terminology - I feel like I’m fumbling around in the darkness here as I learn how to put all the pieces together.
I’m wanting to ensure that my MongoDB connection opens when the server starts, and that it tidily closes during a shutdown sequence.
Right now, my server is structured as such:
app.js starts a Koa server, defines the middleware stack, and the Koa instance is exported as app (an object).
server.js imports app and listens on a port. I think this is where I should fire up the Mongo connection - but I can’t conceptualize how I would pass it to app for use.
Further, the middleware of app will make calls to handler methods in another directory to handle business logic (including DB interaction) - so it is not even app itself that is using the Mongo connection app's middleware calls functions that use the Mongo connection.
I hope I’ve made myself clear - I made every effort to. If what I’m describing seems weird, it may not be because I did a poor job describing it - it may be because this is my first run-through of building a backend from the ground up. All constructive criticism is appreciated.
Hey @Michael_Jay. You are making sense. I have not worked with Koa specifically. However I use express.js all the time. And what I do is launch the server in index.js initializing the server and with the app.listen() part. Then in a different file name dbConnection.js I have a function that connects to Atlas. This function could be imported and executed once your Koa server is listening on whatever port.
When you close the server down with SIGTERM or SIGINT then close the connection on the MongoClient which is returned from the connection function.
Here is a tutorial I found. Please note I did not fully read it or check it. However it talks about connecting to mongodb with koa.
Let me know if you need anymore help or a better explanation.
Thanks @Natac13. I completed the entirety of the MongoDB University Developer’s curriculum - but the entirety of the backend was pre-baked for the M220JS class. However, I did start looking back at what they did, and things are beginning to click.
That backend is set up such that the MongoClient calls “injectDB” methods on DAOs - so I think that’s how the client is passed to the persistence layer. I hadn’t paid much attention to the DAOs previously, but my backend was basically structured with a DAO layer anyway, so I’m trying to emulate what they did for this first project.
They don’t bother with closing the connection, and that Medium article doesn’t either. So I’ve still got some exploring to do there - but this is a learning process so I’m just trying to take it day by day.
I didn’t even know about SIGINT and SIGTERM (I’m currently a Windows user), so that’s something to chew on.
This is a re-posting of my answer provided on the MongoDB University. Hopefully the more experienced people from this forum can provide feedback.
I would say DAO because API is usually unaware of the schema.
The API represents your business logic.
The DAO represent the implementation of your business logic.
You should let the server enforced the schema because it will be enforced with manual updates. Which might be a bad idea because you won’t be able to fix implementation issues by manually do what was supposed to be done.
This being written. I personally stay away from schema enforcement. It is a unnecessary overhead when you are serious about unit testing.
