Okay, welcome back. In this lecture, we'll provide a quick review of the MongoDB database as used by the API. Note: unlike the previous two lectures, which concentrated on the front end API implementations and for which involved custom-developed source code, there is no source code for the database implementation since we're just performing an install and configuration of MongoDB. But before we continue lets now quickly review the choice of MongoDB for storing and persisting our programming language data as well as our vote counts.

MongoDB provides a feature-rich schemaless or NoSQL approach to storing data. The main benefit of using this type of database is you can store documents or objects in their native data structures without any translation or normalization required. It is for this reason that this type of database is ideal when creating APIs that deal with JSON-formatted data and is the main reason we're using it to manage the data that our API uses.

Additional benefits considered in choosing MongoDB for our backing database are: it's very easy to scale out the database using its replicaSet technology, for redundancy and performance reasons. In the Kubernetes Cluster demonstration given in the next course, we'll deploy and set up a MongoDB replicaSet. Its online documentation is excellent. It provides dynamic or flexible schemas. This accommodates prototyping and the evolution of data structures. Complex queries are supported although we aren't in need of using them for the sample application. And an official MongoDB Go driver is now available and supports connectivity from go-based applications and for which we'll use for our connectivity requirements from the API.

The MongoDB setup, configuration, and data structures as used by our sample application are simple and easy. We'll configure a single database named LangDB which contains a single collection named languages. An example document that will be stored within our languages collection is shown here. In this case, the document represents the programming language details for the 'go' language. The initial load for the sample database will be done using the following Mongo commands. After the initial load, the document data is mostly static aside from the vote field, whose values are incremented by 1 each time a user clicks on the respective +1 voting ballot.

The MongoDB service, or DMON, will be configured to start with the following parameters:

--bind_ip is set to 0.0.0.0. This is to allow all incoming connections, regardless of origin.

--replSet is set to rs0, which will be the name of our replicaSet when we deploy it in the next course into our Kubernetes Cluster.

--wiredTigerCacheSizeGB defines the maximum size of the internal cache.

You may have noticed that the off parameter has not been specified, meaning that authentication on connections is not required. This is, as previously mentioned, to make the demonstration deployment quicker and easier. In production, authentication is wisely encouraged and should definitely be configured and turned on. We'll explain more on this later when we get into the demonstration mode. As previously mentioned, in the next course, when we deploy our application into a Kubernetes Cluster, we'll configure the MongoDB database as a replicaSet with three nodes. The configuration will ensure that the data is replicated across the three nodes ensuring that the data is redundantly available. Okay, that completes this lecture on our choice of MongoDB for our back-end database and the features that it provides. 

Go ahead and close this lecture and we'll see you shortly in the next one where we'll being demonstrating how to build, package, and deploy our cloud-native application using microservices using Docker locally. In doing so, this will allow us to prepare and validate the solution before deploying it into a Kubernetes Cluster.