End-to-end Machine Learning — Dashboard frontend

This article is the first of a series of articles on how to build an end-to-end machine learning pipeline for a chatbot AI that relies on a user-defined knowledge base. You can read about the description of the use case and the other articles in the series here.

In this article, you will read about the dashboard frontend, the development details, and how to deploy the package to Google Cloud Run, a highly scalable service for containerized applications.

You can explore the code at my GitHub repository.

Technological framework: Vue.js

The frontend has been developed by making use of Vue.js, a progressive javascript framework for front end development.

Why Vue.js? Because it’s easy to use! Being a progressive framework, it saves you time and effort.

Two main Vue.js components are the views and the components. The views are used from Vue Router when switching between web pages as they generally function as pages, while the components are usually reusable elements and are generally used by the views.

The router defined for the dashboard frontend is depicted in Code snippet 1:

Code snippet 1: Vue.js router

Dashboard homepage

The dashboard homepage is the first page the user lands on. It is located at path “/”:

Figure 1: Home page

It is composed of a routing bar and a simple welcome message followed by three cards: one for the Knowledge Base (KB) page, one for the keywords page, and one for the training panel page.

The three cards are located in a single row and are contained in four bootstrap columns. Consider, for example, the card linking to the KB page shown in Figure 2:

Figure 2: Home page cardS detail

The code that made this card possible is shown in Code snippet 2,

Code snippet 2: Card html

where, when clicked, the router changes the view to the one corresponding to the path “/kb” that, as shown in Code snippet 1, corresponds to the Knowledge Base view.

The other cards are not shown here but the logic is the same as that shown in Code snippet 2.

Knowledge Base View

Figure 3: knowledge base view

KBView, the Knowledge Base view, is the page that gives the user an overview of all the FAQs. By clicking on one of the three buttons associated with each FAQ, the admin user can change the training status (whether a FAQ is used for training or not), access the details of a FAQ, or delete a FAQ. It is located at the path “/kb”.

The javascript code is shown in Code snippet 3:

Code snippet 3: KBView javascript overview

As can be seen, when the page is mounted four listeners are activated:

1. createNewFaq: associated with the component CreateFaqComponent, used for creating a new FAQ
2. deleteFaq: associated with the event of deleting a FAQ
3. changeTrainingStatus: associated with the event of changing the training status of a FAQ
4. faqDetails: associated with the user request to see the details of a FAQ

These listeners are deactivated before the KBView page is destroyed because of a change of view (if you want to know more about Vue.js lifecycle you can read this article). It is important to destroy the listeners because they are no longer needed after changing view and, also, because otherwise an error like “Navigating to current location (“/faq/new”) is not allowed”, name: “NavigationDuplicated” would occur.

The event createNewFaq is created by component CreateFaqComponent, that in KBView is the button located at the top-right:

Figure 4: CreateFaqComponent with hover activated

The code of CreateFaqComponent is shown in Code snippets 4 and 5:

Code snippet 4: CreateFaqComponent html code

Code snippet 5: CreateFaqComponent javascript code

The events deleteFaq, changeTrainingStatus, and faqDetails are generated by the FaqPreviewComponent, which is a component that previews a FAQ and emits the events managed by KBView. The Knowledge Base view shows the FAQs by means of code shown in Code snippet 6:

Code snippet 6: code detail for the generation of FaqPreviewComponents

The detail of a FaqPreviewComponent is shown in Figure 5:

Figure 5: FaqPreviewComponent

and the buttons associated to each FaqPreviewComponent are shown in Figure 6:

Figure 6: event buttons of FaqPreviewComponent

• Button 1: creates the event ChangeTrainingStatus. It is active (green) if the FAQ is used for training the machine learning model, otherwise is inactive (grey).
• Button 2: creates the event DeleteFaq, used for deleting the FAQ
• Button 3: creates the event FaqDetails. When pressed shows all the details (training phrases, answers) of the FAQ by changing view to FaqDetailView

The logic with which the events are managed is shown schematically in Figure 7:

Figure 7: KBView events logic

All the atomic requests are managed at the level of KBView by means of the event listeners. With this strategy, only the KBView component is responsible for the requests instead of enabling each of the FaqPreviewComponents to send REST requests to the backend.

FAQ Detail View

FaqDetailView is responsible for showing all the details of a specific FAQ. It is located at path “/faq?id=<ID>”.

Figure 8: FaqDetailView

This view is composed of four main components:

• MainQuestionComponent: Located on the top-left side of the page. Responsible for editing the definition of the main question.
• FaqCommandsComponent: Located on the top-right side of the page. Its functionalities are similar to those of KBView: changing training status, and deleting and saving the FAQ.
• SwitcherComponent: Located below the MainQuestionComponent. A switch that allows the training examples or the answers to be displayed.
• FaqLanguageExamplesComponent-s: One for each language managed by the chatbot. Each component is associated with only one language, contains a set of training examples in that language, and allows the deletion and addition of examples. In addition, it is possible to hide the training examples by clicking on the eye icon on the top-right side of the component.

Figure 9: Detail of the training examples, with the set of italian training examples hidden

The html code for the FaqDetailView is depicted in Code snippet 7:

Code snippet 7: FaqDetailView html code

Similarly to the event handling logic described in the KBView section, for this view there is also a single point of creation for REST requests.

Keywords

Keywords are displayed in KeywordsView, a component that has the sole objective of allowing the user to create, edit or delete keywords. The view is displayed in Figure 10:

Figure 10: Keywords view

Similarly to KBView, in KeywordsView there exists the component CreateKeywordComponent located at the top-right side of the page, responsible for creating a new Keyword.

Each keyword is contained in a KeywordComponent that allows the user to modify or delete the keyword it is associated to. Additionally, for KeywordsView, all the logic for REST request is managed at the level of the view by means of the event handlers that intercept the tokens emitted by the KeywordsComponents.

Deployment

The front end is deployed using Google Cloud Run, an highly scalable service for containerized applications.

In order to use this service it is necessary to build a container and the technology used is Docker. The docker file is shown in Code snippet 8:

Code snippet 8: front end Dockerfile

The docker container is created in two stages: a build stage and a production stage. In the first, the application is created and the required packages are installed; in the latter, instead, nginx is used to serve the pages.

Given the definition of the Dockerfile, Code snippet 9 is responsible for building the docker container and pushing it to the Google Container Registry, a repository of docker containers associated with the project.

Code snippet 9: build and push script

Once it is pushed to Google Container Registry we are ready to run the deployment with Google Cloud Run. The script is shown in Code snippet 10:

Code snippet 10: Google Cloud Run deployment script

Once the script has been executed, Google will manage 100% of the traffic and the scalability of the application.

Conclusions

We have seen how to use Vue.js to develop a simple dashboard front end and how to manage the events to have a single point of responsibility for REST requests. We have also examined how to build a container for the web application, how to push it to Google Container Registry, and how to deploy it with Google Cloud Run.

If you are interested in the description of the use case and the other articles in this series, click here.