- [Instructor] Okay, welcome back. Now that we have a good understanding of what OpenShift is and of its many innovative and productive features, lets pause and quickly review the key architectural elements of the sample cloud native application that we'll soon deploy. If you're already familiar with the architecture having previously completed the "Building a cloud native application" course, then feel free to skip ahead to the next lecture where we began demonstrating the actual installation of OpenShift. 

Again, this lecture is primarily provided to ensure that you understand the messaging and networking requirements as later used and implemented within the OpenShift cluster when the deployment takes place. To begin with, let's discuss the frontend as exposed to and used by the end user. The application provides a typical web frontend and allows the end user to vote for their favorite programming language. When the application initially launches within the user's browser, three AJAX calls are made to the OpenShift hosted API service, one peer programming language to retrieve the particulars for that programming language. After the page has completed loading and is fully rendered, the end user can then click on any of the +1 voting buttons to vote for the preferred language. This results in another AJAX call back to the API service. 

The API simply reads and writes to the backend MongoDB database. The frontend has been developed using React, which for those who are unfamiliar with is I superbly designed JavaScript development framework library, which allows you to build component-based frontends. If again, you're interested in the finer details of how the frontend has been engineered, then the "Building a cloud native application" course hosted here on CloudAcademy is recommended viewing. 

Moving along, all three major components that make up the sample cloud native Vote App, the frontend, the API service and the MongoDB database have all been designed to be containerized, making them easily deployable into an OpenShift cluster as I'll soon demonstrate. So, again in summary, the three major components of the Vote App are, the frontend, a react based wave application which provides a voting interface, the IPI, a REST based API developed in GO. This provides typical create, read, update and delete API endpoints. All AJAX calls which originate from the frontend are directed a through this API. And the database, a MongoDB database setup as a replica set for redundancy purposes. 

The API reads and writes voting data to and from the database. Now to ensure that you understand the requirements for the OpenShift networking configuration that we'll soon apply, the following two sequence diagrams are provided to inform you of the inner workings and in particular how the internal messaging is used within the application. The first sequence diagram represents the messaging used when the application first loads. 

The browser starts by first loading the main application, HTML, JavaScript and CSS files. Then each of the programming language JavaScript components make individual AJAX calls back to the languages name API endpoint hosted within the OpenShift cluster, retrieving the programming language details keyed on the programming language name. The API in turn connects to the backend MongoDB database also hosted within the OpenShift cluster and reads the data for the programming language keyed on name. A response containing the programming language data is then sent back to the browser. 

Finally, the browser upon receiving the AJAX response renders the programming language details and completes the page rendering process, meaning the application is now ready to be used by the end user for voting purposes. With the application now loaded, the end user can begin voting. He or she does so by clicking on any of the three +1 voting buttons, which results in the messaging sequence as described here. Key points of this messaging flow are, clicking any one of the +1 voting buttons results in an AJAX call being sent back to the OpenShift cluster hosted API endpoint languages name vote, where name is the name of the language just voted on. 

The API in tune internally connects to the backend MongoDB database also hosted within the OpenShift cluster and performs a db.collection.updateone filtered on the programming language name and increments the vote field by one. An update success code is returned in the response and is passed all the way back to the originating AJAX caller. The browser then completes the sequence by incrementing the vote count for the programming language, the use of voted on. 

That completes this lecture, bringing you up to speed on the architecture and messaging implementation as used within the sample cloud native application. The architecture and messaging designs as just reviewed, will give you insights into why and how we go about deploying the application within the OpenShift cluster, particularly how the networking resources such as routes and services are configured and wired up. Go ahead and close this lecture and I'll see you shortly in the next one where I'll next describe the OpenShift configuration that I'll soon apply to host our sample cloud native voting application.