-
Notifications
You must be signed in to change notification settings - Fork 8
Frontend Documentation
This page contains documentation for the files in the /frontend/playground-frontend
directory of the Github repo. This page is regularly updated when new changes are added to these files.
The platform used to build the frontend is ReactJS with Bootstrap. Effort must be made to use common CSS classes and reusing React components for extendability.
For architecture design, the user may read Architecture.md located in the repo.
The current UI has four main navbar items:
-
Home
is the main and root page of this web application -
About
provides information on the motivation and technical stack used in this program -
Wiki
provides further information on the layers used and a demo video for new users -
Feedback
allows a user to send feedback to the DLP team via web form
Where the magic happens. This page is rendered by Home.js
which utilizes most of the components and hosts the primary function of the app.
Given a set of possible layers and parameters in settings.json
, the file generates the given UI that allows the user to drag and drop the intended layers, specify the arguments of the layers, and choose the additional parameters such as Epochs
number. These parameters and layer information are then passed to the backend's Flask route at /run
, waits for the backend to return a JSON message, successful or not, and then renders the results based on that JSON message.
In the good case scenario, all appropriate visualizations are rendered depending on the problem type. Some, like the following, are hidden in a Regression problem:
- Confusion matrix
- AUC/ROC plot
- Accuracy/Loss results
On the other side, if the train session fails for whatever reason, e.g., inputting invalid Linear layer in
and out
arguments, a truncated stack of the error message raised by the backend will be caught and given to the frontend where that error message will be displayed in lieu of the results.
The user may opt to receive an email copy of the results before they train their data. Both the email and feedback functions are handled by the backend through the /send_email
route.
While it is possible for the user to download their results through the web app, the accuracy/loss CSV and plots, AUC/ROC plot, and confusion matrix will be generated and downloaded by the frontend. This is slightly different than the model PT and ONNX files which will be downloaded directly from a directory backend_outputs
updated by the backend and accessible by the frontend. However, the emailed results will all be from the backend. The backend does generate a copy of the plots and those copies will be emailed to the user. This is why saving the results via email and downloading them through the UI will produce aesthetically different files, but they will all reflect the same data.
All visualizations are made on the frontend using Plotly and raw data passed from the backend. Essentially, the backend returns four items in a good case scenario:
-
success
(bool) - whether a train session has been successful -
message
(string) - error message if training failed -
dl_results
(JSON) - main data dictating the train and test accuracy/loss results -
auxiliary_outputs
(JS object) - additional data such as AUC/ROC plot and confusion matrix raw data
The PT and ONNX files are created by the backend and placed in a directory backend_outputs
accessible by the frontend.
Currently, there are three layers implemented in this playgroud—Linear, ReLU, and Softmax. A developer can easily add in a new layer to be used by the user through:
- Go to settings.js
- Put in (* = required):
-
display_name
*: Name of layer to be displayed to user -
object_name
*: Layer object to be passed into the backend, e.g.,nn.linear(...)
-
parameters
: An array of JS objects with at least the display name of the parameters for the layer object
-
The Learning Modules page is designed to teach users the basics of deep learning so that they can use DLP without needing to know any heavy math. It is built in a typical, slightly-gamified khan-academy style, featuring multi-modal content such as photos, quizzes, exercises, and text.
Content is first organized into modules, and then each module is divided into sections. Each section then consists of multiple content blocks, which can be of many different types. The types of content currently supported are listed below.
-
text
: This content type simply consists of a block of text. -
heading1
: This is a simple bolded heading -
image
: A png image -
mcQuestion
: A multiple-choice question, which can be answered by a user and marked correct or incorrect. -
frQuestion
: A free-response question, which can be answered by a user and marked correct or incorrect based on a case-insensitive exact text match. -
exercise
: A drag-and-drop environment similar to the primary DLP tool where users are presented with a simplified interface so that they can practice building models like they might build in the real DLP tool. Users can then be evaluated and given points based on the accuracy these models achieve.
Of the above components, mcQuestion
, frQuestion
, and exercise
contribute to points for a user. The modular nature of the way the modules are set up also ensures that new components can be added easily by making new React components, and then editing the LearnContent.tsx
file to account for the new components.
The content data itself is stored in the LearningModulesContent.tsx
typescript file. The content is organized as a typescript object containing the modules, sections, and content blocks in hierarchical fashion, with each module being indexed starting at 0, each section within each module also being indexed starting at zero, and each content block similarly being assigned an index. (Note that this means that three indices are required to specify a specific content block: module, section, content block). When the pages are rendered, React iterates through the content blocks in the specific section to render and dynamically creates the appropriate content react components.
Point data for users is stored in a DynamoDB table entitled userProgress
. There are two functions in driver.py
that facilitate the necessary frontend-backend communication for learning modules: getUserProgressData()
and updateUserProgressData()
. The first function takes in a userID
, which is fetched from the Firebase authentication system, and returns the requested user progess data or an empty object if no record exists. The second function takes in a userID
as well as a triplet of indices (module, section, content block) and increments the corresponding point value.
The user progress data for each user is organized in a very similar hierarchical fashion as to the learning modules content data. One important distinction to note, however, is that if a user has not earned any points in a particular module or section, that module or section will not exist in the json object in the table. This is done to prevent the need for setting up table entries before a user starts earning points as well as to save space in the database. A particular module/section will be created in the json when points are earned in it for the first time. This can be seen in code in the implementation of the updateUserProgressData()
function.
- Home
- Terraform
- Bearer-Token-Gen-Script
- Frontend-Backend Communication Documentation
- Backend Documentation (backend)
-
driver.py
- AWS Helper Files (backend.aws_helpers)
- Dynamo DB Utility Files (aws_helpers.dynamo_db_utils)
- AWS Secrets Utility Files (aws_secrets_utils)
- AWS Batch Utility Files (aws_batch_utils)
- Firebase Helper Files (backend.firebase_helpers)
- Common Files (backend.common)
-
constants.py
-
dataset.py
-
default_datasets.py
-
email_notifier.py
-
loss_functions.py
-
optimizer.py
-
utils.py
- Deep Learning Files (backend.dl)
- Machine Learning Files (backend.ml)
- Frontend Documentation
- Bug Manual
- Developer Runbook
- Examples to locally test DLP
- Knowledge Share