MERN Stack & GraphQL - #5 MongoDB and Mongoose

Now that we have a functioning web server, it's time to move along with the database layer. For our chat application, we'll be using MongoDB, a popular NoSQL database designed to work with JSON-like documents. As you can imagine, there are plenty of database options out there to choose from. For one thing, you could always set up a local MongoDB daemon on your machine, and connect to it via localhost at port 27017. Most often though, you would not want to pollute your dev environment with 3rd party services like mongod, since they take up storage and resources. Alternatively, you could isolate your MongoDB dev server in a container using Docker. With a few commands, you can easily spin up, configure, and destroy as many containers as needed, while keeping them separate from your host OS. For quick prototyping, you could also use a DaaS, or a Database-as-a-service, such as mLab or MongoDB Atlas. They are easy to get started, and they both offer free tiers that you can use for development or testing. Once you sign up, you can spin off a new MongoDB instance, and use the hostname and port from your DaaS of choice to connect to it. Beware that server response times will vary depending on the network latency. Once the database is up and running, we can connect our app to it. MongoDB already comes with a native Node.js driver. To build a full-featured business model, we will also use Mongoose, a MongoDB ODM (Object Document Mapper) library that maps JSON schema to object models. We'll use it to connect to MongoDB as well. Oftentimes, your first shot at connecting will fail. Try inspecting the connection string to make sure it respects the expected format https://mongoosejs.com/docs/connections.html At the very least, you'd need the server host and port, as well as the database name. Unless the engine allows for unrestricted access, you'd also need to supply user credentials. Note that any special characters in the password must be URL encoded. Last but not least, to get away with the DeprecationWarning about the URL parser, use can set useNewUrlParser to true. Once connected, we'll kick things off with the User model to represent the users of our chat app. After we sync up the model with our GraphQL schema, we'll have an overview of the Mongoose schema options, such as "required" and "unique". In fact, "unique" will be our first of the many encounters with Mongoose gotchas. If you want to skip ahead and know exactly what I mean, head over to Mongoose FAQ section https://mongoosejs.com/docs/faq.html#unique-doesnt-work In the meantime, we'll hold off with validation, and will instead handle it separately. For the time being, we'll keep our models concise. Once again, there's a good chance we'll come back to those models and write custom validators for database-driven checks, such as querying the users collection for a unique email field. That would do it for this episode. In the next one, we'll get to wire up our User model with GraphQL resolvers, and start writing to and reading from MongoDB. Stay tuned! Intro to Mongoose on freeCodeCamp https://medium.freecodecamp.org/introduction-to-mongoose-for-mongodb-d2a7aa593c57 Getting started with Mongoose schemas https://mongoosejs.com/docs/guide.html