Our goal was to relieve the embarrassment that students have when asking questions. At the same time, this helps teachers make their lessons more effective real-time!

We wanted to prevent students who are simply scared from reaching out to ask any questions; and with online education on the rise, this issue has become more urgent and relevant. We introduce the idea of anonymity in questions and feedback to help both teachers in their teaching and improve the participation of students in an educational environment.

Our project structure idea was adapted from the intuition behind the popular educational game tool known as Kahoot. The idea was to use a simple code to connect to a classroom while maintaining anonymity from the eyes of the educator. Maintaining anonymity helps protect students privacy in cases where they do not want to reveal their positions to each other. We brought this same idea of anonymity to the idea of asking questions in both a physical and virtual classroom setting.

Do you want to continue being hesitant from asking questions in your virtual or physical classrooms? Or do you want to help revolutionize the world's current education system?

If you chose to help us revolutionize this system...

Help us promote edfusion to make it widely accessible to empower students of all kinds and improve the quality of your teachers.

What it does

Today, we present a profound project to stop all student confusion in academic lessons and lectures. At the same time we will be trying to improve the quality of the lessons and lectures given by educators.

Especially, today, with coronavirus spreading, students are more afraid to reveal their questions, answers, and thoughts openly over virtual meetings such as Zoom.

When was the last time you were too embarrassed to ask a question in class? Or if you are an educator, have you ever found students disliking your class or not participating enough?

You're not alone. Never feel these fears or insecurities again.

The answer is simple: edfusion

How I built it

We have 2 parts to this education system:

Student Web App Educator Desktop App

Student Web App


NodeJS has frameworks for both mongodb and expressjs. ExpressJS takes the data from MongoDB Atlas and passes it to HTML, CSS, JS static files. The data in the form of JSON is passed with HTTP requests using POST, GET, PUT, etc making this a REST API. NodeJS is simply run with npm start which ran nodemon in our case for providing immediate updates to the server. The Express server runs on a local port of 8080 to serve the files and access the routes for the api, but it is set to dynamically update to the cloud's process.env.PORT. The student web app is hosted entirely on heroku.

Educator Desktop App


MongoDB has a stream reader that notifies the codebase when there is an update in the database. Upon listening for database updates, the code must update the desktop UI. To do this, data is sent to the built in NodeJS backend in main.js which then communicates via ipc (unlike REST or HTTP from our webapp's API) to the renderer.js. This allows for JS to update dynamically based on changes to the backend. The front end ElectronJS technology is changing its graphs and charts with Chart.js. We also have a notifications UI to update questions which educators can interact with on a computer or SMARTBoard for physical/virtual lessons.

Challenges I ran into

Limiting Database Calls One of the biggest problems we ran across was getting live updates while limiting the amount of database calls we make. To do this, we had to listen to the database for a general update and find the specific part that was updated.

Closing Database Connections Another issue we ran across was the amount of unclosed database connections we had come across. We needed to close all the connections we had to MongoDB to avoid overloading it and crashing it several times.

Handling Notifications We ran across an issue of having multiple notifications appear for each teacher that decides to run a classroom creating a decentralized network which was unintended. We had to check for notifications and their relation to the teacher in order to prevent unnecessary notifications to other users.

Using Developmental Servers Another developmental struggle we had to overcome was running two node servers to test both the student app and the educator desktop app. One cannot work without the other, so both had to be running to navigate the entire application.

Accomplishments that I'm proud of

1. A working web app with animations We were able to construct a fully working web application that connects to and talks to the MongoDB Atlas. Within the landing page, we are most proud of the downward flow of the landing page. This brings more interactivity and attraction to our product.

2. A working desktop app with notifications Like the web app, we have various animations on the educators application. We also have working notifications so that teachers who teach with Zoom ScreenShare or a SMARTBoard can see questions live during a lesson. This can help clear confusion mid-lesson through a desktop notification.

3. Scalability The MongoDB Atlas allows for live usage of our webapp and desktop app. The student platform is able to communicate with the educators platform anywhere with a proper internet connection. Our education system can handle any amount of classrooms and students, allowing for widespread growth around the world. With paid expansion, we can grow the storage of the database to unimaginable limits allowing for more accessibility.

What I learned

Cloud Based HTTP We learned how to host and serve html files with an express server. JS files that work with html makes HTTP requests with the express.js to get data from the database. We had to put our files in a folder called public. We also had to setup our server start configuration in package.json. This would allow heroku to host our server. Heroku will not allow you to make calls to localhost, so you need to access its own port on the cloud with lines like process.env.PORT rather than an explicit local machine port.

MongoDB Pool Overflows Another thing that we learned is the importance of closing our connections via mongodb. We need to call mongo.close() at the end of each JS Promise. Otherwise, the pool will overflow with requests. This would cause the entire database to crash. We also found out that we could allow any ip address to access the mongodb rather than a single ip one. Finally, I realized with MongoDB Atlas, the data is accessible by everyone so handling data can be difficult sometimes from multiple users.

What's next for Education through edfusion

We believe this education system is nearly production ready. We have several things we want to do before deploying it to be used. There are several ideas for improvement as well.

A New Database One of the things that we plan to do is to replace the MongoDB database with an SQL structure with a much more affordable and scalable DB such as Google Sheets API and Google Drive API. In this way, storage is in the hands of the educators themselves to keep track of their own histories rather than relying on us, the developers.

More factors Additionally, we would like to add more factors to the webapp and desktop app such as a boring scale. In this way, teachers and educators will know how interesting their lectures actually are. Combined with knowing the questions, reviews, and confusion of their lectures, with a boring scale, lectures can be much more engaging.

Ratings for teachers Similarly, inspired by Rate My Professors, we can also post teacher improvements or qualities and reviews on websites so other students can decide whether they want to take the class. This education system can create a marketplace styled platform for learning about teaching options while helping students understand content and helping teachers understand how they can improve.

Clean Code edfusion also has lots of spaghetti code on the desktop side. We plan to clean all of it up to enable future developers to continue developing on this product.

UI edfusion was created with an initiative on having a strong user interface. We intend to continue improving our user interface in the following ways: making elements more material like, possibly adding sound effects, and adding more animations. With better UI, we can encourage feasibility in the usage of this education system while also making the learning much more engaging.

reCaptcha to Prevent Bots Although we initially planned to use reCaptcha to handle Selenium bots from trying to misuse the system to deploy numerous questions to the teacher, we found out that it takes time for Google to approve the reCaptcha security system for a site. Therefore, given the approval time, we could not implement it in our web app.

How to Use It


Three Simple Steps

Students are able to log into a classroom generated by an educator.

Log In:


Join a class


Students are able to ask questions anonymously. Students are also able to update their confusion percentage, which notifies the teacher of the class' confusion statistics.


When the class ends, students can rate the lesson and provide feedback.


Educators Three Simple Steps

Educators login to simply create a classroom for students to join. link

Educators may click on notifications to instantly resolve them or mute any disturbances. link




Educator Desktop App Login Credentials:

username: password: abc123

Share this project: