- [Instructor] Okay welcome back. In this lecture we will retest the full sample cloud native application within our browser. 

For starters, lets first grab the copy of the front end DNS name. Now jumping back into our browser, I'll paste it in and reload the application home page like so. Brilliant! This shows that the full cloud native solution is currently deployed and hosted within our many cubed based Kubernetes cluster as working end-to-end. The fact that the details reach programming language as selected here, have now been reigned in successfully. Indicates that the required networking traffic paths, starting from the browser, through the various resources deployed within the cluster, are valid and working. 

To confirm that the voting application is indeed working, let's open up developer tools, and then watch the Ajax calls being generated by the front end, and serviced by the API within the cluster when we reload the page. Here, we can filter on just the Ajax calls, by enabling the XML HTDP request filer. And now we can see the three individual Ajax requests being made, one per programming language. Each request is being sent to the API to request the details for the particular programming language. These details, if you recall, populated into the back end MongoDB database in a previous lecture. Selecting the go Ajax request, we can observe the actual API URL in HTDP headers for this request. We can say that it was sent using the get verb, and that the response code was a 200, which indicates success. 

Next, if we click on the response tab, we can see the raw data response. We can also click on the preview tab, and see a formatted view of the same response like so. Let's now take a look at the equivalent Java and Nodejs Ajax request. Next, we'll clear the network pane in preparation for clicking the vote buttons. Here, we'll vote on the go language, and this in turn generates a new Ajax request. Let's now view the headers for this request. And again, we can clearly see where it is headed towards, the API. We'll vote another three times on the go language to generate some more traffic. Note also how quickly the round robin trip takes. It's quite fast, considering the various hops the request has to make, not only to the cluster, but through the resources within the cluster itself. Let's also vote once on the Java programming language. And again, we can see another Ajax request generated. Finally, let's now jump back into the terminal and take a look inside the MongoDB database to ensure that the votes are being correctly counted and saved. 

We'll run the command kubectl get pods, and we'll pipe it to grep, and search on Mongo. Next, we'll jump onto this pod by executing the following command. kubectl exec -it, the pod name for this Mongo pod, and the dash command. This gets us onto the Mongo instance, where we can fire up the Mongo shell by typing in mongo. We then swap into the LangDB database, and then finally use the find method on the languages collection to view all of the documents stored within. Here we can clearly see that the current vote on the go document sitting at four, which is the expected vote count, and likewise, the vote count on the Java document is sitting at one. 

Let's go back to the browser and double check this. And yes, we can see that both vote counts are synchronized. This is an excellent result and it proves our current deployment is functional. Okay, that completes the full deployment of our end-to-end cloud native application into our Kubernetes cluster. But, are we finished? Well no, not just yet. In the next lecture, we'll introduce you to network policies where we improve the security of our deployment by applying rules as to how traffic can flow between pods.