MVC Architecture – Introduction and Application

I advise that “first viewers” of this technical blog series begin with the initial posting at url: Introduction and Chapter Guide.
As initially stated:  …..each new post will describe configuring a subsequent step(s) in the (initially stated)agenda. I expect to be adding new posts for this series semi-weekly.
Whereas the stated agenda for this entry was to include:
Foundational Installations of:
1)    server – nginx
2)    Bower: requirements
a.     requirements
i.       GIT
ii.     NODEjs
iii.    nam
b.     managed updates/dependencies for
i.       angularjs
ii.     CSS
iii.    Bootstrap
I decided to postpone the aforementioned technical description and for relevance describe how the Model-View-Controller  (M-V-C) concept operates within my application and the MVC advantages.
The Concept of M-V-C is to provide separation between the view (HTML), Model (data management such as backend DB) and Controller (javascript that controls interaction between the View and the Model). I like the following description and graphic of the separation of M-V-C responsibilities. Thanks to
MVC is popular because it isolates the application logic from the user interface layer and supports separation of concerns. The controller receives all requests for the application and then works with the model to prepare any data needed by the view. The view then uses the data prepared by the controller to generate a final presentable response. The MVC abstraction can be graphically represented as follows.
A chief advantage of the M-V-C architecture is that data exchange between the View and backend (Model) is handled by Angularjs on the client machine… not on the server. The View HTML of a M-V-C presentation is loaded once, and depending on which functions of the Angularjs controller are executed locally: parts of the HTML may be seen, hidden, executed or not executed. This obviously makes for a less busy server and possibly speedier execution depending on the capability of the client machine.
As an example, my application initially starts an HTML page (or View”)  “sandbox4beta”, (Flask’s port: 5000)
app = Flask(__name__)
@app.route(“/”)
def main():
    return render_template(‘sandbox4beta.html‘)
The above referenced HTML page includes an Angularjs directive boolean “ng-if=”PhaseOne“, followed by selectable button actions.
 <div ng-if=”PhaseOne”>
       <h3 align=”left”>Re-push all B-H prefixes? Or search for a B-H prefix in the Data Base?</h3>
        <button class=”w3-btn w3-large w3-blue” ng-click=”Repush()“>Repush ?</button>
         <button class=”w3-btn w3-large w3-blue” ng-click=”DBaseSearch()“>Database Search ?</button>
 </div>
So, depending on the state of parameter PhaseOne,  the HTML page will allow the user to visualize and optionally select buttons “Repush” or “DBaseSearch” each of which will invoke a function in the  Angularjs Controllerscript.  The Angularjs script functions as the “Controller” of the M-V-C architecture and   communicates between the View (HTML) and the Model (Data I/O handler program).  I want to mention that two different Angular directives could have been used in this Boolean evaluation, with some significant differences: ng-if will only include the HTML section between div markups in the Document Object Model (DOM) if the ng-if Boolean evaluates true. ng-show will only show the View section between div markups if the ng-show evaluates true, BUT any autonomously executable code following the ng-show will be executed regardless whether the code is displayed (or not) in the View to the user. The concepts of DOM and how Angularjs interacts with it and listens for HTML events through the DOM will be described more in later posts.
Excerpts of one of the aforementioned functions “Repush” in the Angularjs Controllerincludes:
$scope.Repush = function () {
        .
        .
            $http({
                method: ‘POST’,
                url: ‘/repush’,
The Angularjs function directs an HTTP post to the location “/repush”​in the Main program  (which functions as the “Model” in the M-V-C architecture.  The “Model” functionality of the Main program is responsible for handling data I/O, including sending data to the ExaBGP listener.
From  “Main”:
@app.route(“/repush”)
for record in cursorPos:
        .
        .
       next_entry = “announce route ” + ” ” + record[‘prefix’] + ” next-hop” + ” ” + record[‘nexthop’]
       stdout.write( next_entry + ‘\n’)
So from the above, we see the interconnection between Model (Data I/O), View (HTML) and Controller (Angularjs). Now we have a good jumping off point into the construct of my application. The hallmark of a well written M-V-C application can be viewsimplicity.  The initial view upon directing the client browser to the application port follows:
Its apparent from the above simple home page that there are but two initial choices:
1)      repost all black hole routes in the NoSQL database to the BGP listeners, or
2)      Search the DB for a particular prefix
a.      that may be added and announced to BGP listeners, or
b.      if it exists in the DB; removed and withdrawn as a black hole BGP route
The subsequent views represent the view based on possible user selections.    Note: No additional HTML code or pages are loaded after user selections. The View references Angularjs directives that may result in different sections of the original HTML page to be seen, hidden, executed or not.
Without further delay, the user options and View response cases are illustrated in the pages below:
Case 1:   Repush all NoSQL based black hole prefixes to BGP listeners.
The user selects the “Repush” button
The DB repush occurs immediately and provides an indication of how many prefixes (the entire DB) were withdrawn as black hole routes to BGP listeners. The user may select the button that will return to the home view.
Case 2: Search the DB for a prefix (to either subsequently add/advertise or remove/withdraw)
Note that in the following view, the portal checks the prefix input as being a qualified ipv4 prefix. Not until the user has entered a qualified prefix will the view identify the IP address as “valid” and allow the user to search the DB for the prefix.
Case 2: Search the DB for a prefix (cont…)
In the following view example; the user has typed a valid ipv4 address and the view will allow a search of the DB.
 Depending on whether a prefix has been discovered or not discovered in the DB; the user may add the non-present prefix (causing an announcement) or remove a present prefix (causing a route withdrawal.
Make note of the continuing simplicity of the view.  Views in the M-V-C architecture are generally “single page”, absent of loading additional HTML pages. Angularjs directives may specify if a segment of the original view should be seen or not seen, based on conditions within the Angularjs directives (such as ng-if, ng-show or ng-hide).
Case 2a: Prefix not found in the DB
The prefix is not in the DB, and therefore is not being advertised as a black hole route. The user may choose to add the previously entered prefix into the DB and cause its advertisement
The user selected to add the prefix and has the option of adding the entries as below:
Case 2a: Prefix not found in the DB (cont….)
After selecting to add the prefix to the DB (therefore advertising it to listeners), the view announces success and that the user may choose to return to the home view.
Case 3: Prefix found in the DB
Should the prefix be found in the DB, the user may choose to have it removed and withdrawn as a black hole route.
Case 3: Prefix found in the DB
After selecting to remove the prefix from the DB and withdraw the black hole route, the view announcement success.
So, after this M-V-C functional description; I’ll pick up in the next post with describing  the necessary installation of HTML/Angularjs/Bower/Flask/Python/mongoDB software, supporting automation in the Cloud.