MEAN Stack Components: (Part 1- MongoDB)

The trending technology in web application development is MEAN Stack Development (MongoDB ExpressJS AngularJS NodeJS). One language development journey makes it distinct from the other technologies. We will be going to understand each component in MEAN in detail in the explicit parts. Let us know about MongoDB here:

The capacity to store and render the data is the most important part for most applications. In the MEAN stack, the database of choice is MongoDB, the M in MEAN. MongoDB fits into the stack incredibly well. Like Node.js, it’s renowned for being fast and scalable.

 Relational versus document databases:

If you’ve used a relational database before, or even a spreadsheet, you would be used to the concept of columns and rows. Typically, a column defines the name and data type and each row would be a different entry. Refer Table 1.1 for an example.

TABLE  1.1

MongoDB is not like that! MongoDB is a document database. The concept of rows is there however columns are omitted from the picture. Instead of a column defining what should be in the row is treated distantly. Each row is a document, and this document both defines and holds the data itself. Refer Table 1.2 for how a collection of documents might be listed (the indented layout is for readability, not a visualization of columns).

TABLE 1.2

———————————————————————————————————————————

Firstname:                          Middlename                      Lastname

“Steve”                                “Mark”                                 “Beven”

———————————————————————————————————————————

Firstname:                          Middlename                      Lastname            Nickname

“Brian”                                 “Paul”                                 “Clark”                 “Vicky”

———————————————————————————————————————————

This less-structured appearance implies that a collection of documents could have a huge variety of data inside. Let’s take a look at a sample document so that you will get a better idea of it.

MongoDB documents: JavaScript data store

MongoDB stores documents as BSON, which is binary JSON (JavaScript Serialized Object Notation). Don’t worry for now if you’re not fully familiar with JSON—check out the relevant section in appendix D here: https://www .manning.com/books/getting-mean-with-mongo-express-angular-and-node In short, JSON is a JavaScript way of holding data, hence why MongoDB fits so well into the JavaScript-centric MEAN stack! The following code snippet shows a very simple sample MongoDB document: { “firstName” : “Sachin”, “lastName” : “Ramesh”, _id : ObjectId(“45456hua78yh7asy78adhh78”) } Even if you don’t know JSON that well, you can probably see that this document stores the first and last names of me, Simon Holmes! So rather than a document holding a data set that corresponds to a set of columns, a document holds name and value pairs. This makes a document useful in its own right, as it both describes and defines the data. You most likely noticed the _id entry alongside the names in the preceding example of MongoDB document. The _id entity is a unique identifier that MongoDB will assign to any new document when it is created.

More than just a document database

MongoDB sets itself differ from other document databases with its support for secondary indexing and rich queries. It allows you to create indexes on more than just the unique identifier field, and querying indexed fields is much faster. You can also create some fairly complex queries against a MongoDB database—not to the level of huge SQL commands with joins all over the place, but powerful enough for most of the cases. From Table 1.2- each document in a document database defines and holds the data, in no particular order.

What is MongoDB not good for?

MongoDB isn’t a transactional database, and it should not be used as such. A transactional database can take a number of separate operations as one transaction. If any one of the operations in a transaction fails the entire transaction fails, and none of the operations complete. MongoDB does not work like this. MongoDB takes each of the operations independently; if one fails then it alone fails and the rest of the operations will continue. This is important if you need to update multiple collections or documents at the same time. For example, If you’re building a shopping cart, you need to make sure that the payment is made and recorded, also the order is marked as confirmed to be processed. So these two operations need to be tied together in one transaction. Your database structure might allow you to do this in one collection, or you might code fallbacks and safety nets into your application logic in case one fails, or you might choose to use a transactional database.

Mongoose for data modeling and more

Mongo DB’s flexibility about what it stores in documents is a great thing for the database. But most applications need some structure to their data. Note that it’s the application that needs the structure, not the database. So where to define the structure of your application data? In the application itself! To this end, the company behind MongoDB created Mongoose. In their own words, Mongoose provides “elegant MongoDB object modeling for Node.js” (https:// mongoosejs.com/).

Conclusively, MongoDB is a great choice of database for most web applications because it maintains the balance between the speed of pure document databases and the power of relational databases. That the data is effectively stored in JSON makes it the perfect data store for the MEAN stack. We will get to know about other components in the upcoming parts.