Cumpa Interactive Comment Tool is a web interface for testing cumpa chatbot and supporting communication of the testers and the researchers.
TODO: add illustration for the overall architecture including the comment tool, chat frontend, and notion.
This tool uses following libraries.
- Parcel: This is a webpage builder which makes it easy to integrate whole dependencies and use typescript.
- FastAPI: This is a python library facilitating a development of REST API server. It supports easy validation (not yet adopted in our code) and automatic document generation.
To see the automatically generated document, go to
http://localhost:${port}/docs - MongoDB: A NoSQL database used for the user model, conversation history, and comment management.
The frontend of this tool depends on the "dialogflow cx messenger" (API) provided by Google. This is a web chatbot integration (i.e., frontend wrapper) of Dialogflow CX, a dialog managment system working on Google Cloud. Based on this component, we added following custom functions.
a) Comment modal
In the titlebar of the chatting room, there is a button to leave comment. When a user clicks this button, a modal pops up. In this modal, user is supposed to leave comments related to the current conversation.
This modal is implemented as a WebComponent. When the comment button is clicked, the function openCommentModal in main.ts creates the new component and bind event listeners.
b) Save conversation logs
When user completes to leave a comment, the comment is saved in the database using the /comment endpoint served by our backend API.
The frontend collects current conversation history (It is updated every time user sends or recieves a message. See dialogflow_messegner/DialogflowMessenger.ts.) and send POST request to the endpoint.
TODO: add explanation about the SoundCard component.
All users' conversation will be logged to the database. This may follow this sequence:
- Users login.
- At some point (see various dialog events in frontend/src/dialogflow_messenger/DialogflowMessenger.ts), the conversation history is saved to the database. Maybe it can be represented as a request
POST /user/{uid}/logs.
Maybe it would be easier to use a mock-up user (e.g., 'U100') before making the login function.
User can see the contents of past conversation. This may follow this sequence:
- Load user id after login.
- Load user's past conversation history from the server. Maybe it can be represented as a request
GET /user/{uid}/logs. For example of reading data from an API, see frontend/src/main.ts. - Show user's past conversation based on the loaded data.
This feature requires reading the data from the mongodb Database. Also, this feature requires a login interface for each conversation. If we can preserve the login status of each user, it would be more convenient for users. Giving a unique id to each user and letting them input that ID to login will be an easy way because we don’t need to develop registration. We need to secure the ID.
Any request to the server will be handled by FastAPI routes. All routes are described or included in server.py In particular, separated routers are defined in the src/routes directory. A UserRouter(src/routers/user.py) is an example.
Upon the user's http request, such as POST /comment, the route function will be called.
It reads user's request, do something (e.g., read database), and returns the response.
- Schema
A MongoDB instance is connected to the system.
Table 1. Schema of the table ‘User’.
| key | example |
|---|---|
| _id (primary key) | --- |
| username | U10 |
| experiment_condition | Controlled |
Note that in future, we will use the key username as a primary key, which means a unique key that can be used to identify each item.
- Use
The direct access to this database will be done in src/database/database.py. Any route function which needs database access uses the functions defined in this file. This file uses motor(Tutorial), an asynchronous Mongo DB client API.
TODO: There remains some codes that access the MongoDB api out of this file. These codes should be migrated to this file.
TODO: add description about webhook
You can find the automatically generated API documentation in http://localhost:8000/docs after starting the server. The following description may not reflect the latest API.
/comment
This endpoint affords saving a user comment. The request format is a json as following. (See server.py)
{
"comment": str,
"conversationHistory": [
{
"user": { "text": str }
}
or
{
"bot": [
{
"type": "text",
"text": str
}
]
}
]
"sessionId": str,
"timestamp": {
"$numberLong": str
}
}
/user
See http://localhost:8000/docs to get informed.
TODO: Add another endpoint (maybe /user/{uid}/logs) for saving every conversation log for future report.
Enable venv and install the requirements.
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt(Optional) To install mongodb locally, follow this link.
# Before run the following, first start the docker daemon.
# Pull the MongoDB Docker Image
docker pull mongodb/mongodb-community-server:latest
# Run the Image as a Container
docker run --name mongodb -p 27017:27017 -d mongodb/mongodb-community-server:latestInstall the node modules.
cd frontend
npm installThe script run-daemon kill the existing server, build the frontend, and run the server.
The server prints its log to nohup.out in the same directory, using the utility nohup.
Before running this script, ensure that you have proper .env file in your project root. Below is an example .env file.
OPENAI_API_KEY=sk-#####
MONGODB_URL=mongodb://######
SERVER_PORT=8000
SERVER_HOST=0.0.0.0
Then run the script.
source run-daemonAfter executing the above script, you may want to use the live build for easier frontend development. For this, do the below in your shell.
cd frontend
npm run start