Impulse is a platform that mitigates impulsive spending and brings consciousness to consumerism.
Note: The chrome extension's repo can be found here. The web app's repo can be found here
Michael Weinberger: The Frontend Wizard
Benyam Ephrem: The Mongod (aka the backend guy)
Richard Wang: Mr. Versatile (the man does everything)
School Year: All Freshman @ University of Maryland (class of 2021)
So first off I've got to say, thank you to my team. This is all our 2nd hackathon ever. I couldn't be more proud at how my teammates performed. I got mad when we made some naive choices, when we worked too slowly or rushed too much, but through and through we did this as a team together.
Second...it was just surreal to win. We sat there and after we saw that we didn't get the MongoDB award we lost a lot of hope. We knew we had done our best and tried as hard as we could so we got deflated. Then when the words "Impulse" were said I literally sat there wide eyed for like 3 seconds since I thought it was a mistake. Michael shrieked like a little girl and kept pounding my arm (you know you did Michael) and I snapped out of it. Walking up and having all the hundreds of eyes staring at you while taking a picture (all the while forcing a smile through the shock) just went by like a blur. Very thankful to Capital One for actually thinking that our project had merit enough to award us...it's just wild.
Third......this is just wild. Since I was a kid I was always that kid who thought too much and eventually found programming as an outlet. I'm not some superstar child prodigy but I just dabbled in it since 10th grade on and off. I remember being kind of a secluded kid and working in the dark of my bedroom while my mom would tell me to get off my laptop and do something else since I'd work hours on end learning and teaching myself programming. I still think I'm just an "ok" developer but it's just crazy to remember starting out so small with dumb little projects like FrameShift & TiltTheGaps.
I'm no genius or exceptional thinker. This is just what I've done and gravitated towards for a large part of my childhood. It just happened. It's just...what I've done. And seeing that playing around culminate to a cool achievement like this is really touching to me so yeah...that's what I had to say.
To add on to what Ben said, this is literally the second major hackathon that each member in our group has ever been a part of. I think that that is just insane. Not only that, but we are a group of 3 and we are all freshman... I think the craziest part of this entire process was that we started with a single idea. A single inspiration to solve a problem. My teammates and I all had this vision in our heads of something that we wanted to create. And we were able to build this to completion (despite there being a lot of hacking (lol) things together) to produce something that had value. Even if we had not won, this would have been an awesome experience.
This is one of the first times in my life that I have been directly recognized for something I have built from the ground up. For the past couple years, everything I had built was just for me. It was just to learn. But this time it was different. When we were demoing our project to people, people would come up to us and say, "Oh my god, that's so cool," "That's so well designed," or "I (or insert other family member here) would definitely use this product." It is just a different experience when someone else finds real value and awe in what you make. Winning this prize really shows me that when you can find a team of motivated and competent people, there really is nothing that is stopping you from building something amazing.
If anyone is actually reading this, props to you. You're probably thinking about how weird we are for writing these super long rants and readmes and that we are hyping this up way too much, and you're probably correct. Comments aside, this experience was super cool and definitely very rewarding. It was amazing how well our team worked together, and since we knew each other outside of the hackathon we knew each of our strengths and weaknesses and catered tasks around them. To think that at the start of this school year I did not know anything about Javascript, HTML, CSS, and didn't even know the difference between front-end and back-end, and then ending off the year by winning a category prize in a hackathon using entirely everything that I learned in the past year is truly amazing and inspires me to constantly learn more.
I remember at one point during the demos we had a guy come to our table, and when we talked about our project he seemed genuinely interested and asked a lot of questions to which we responded. We didn't know of it then, but that man was Vivek Kundra, the first Chief Information Officer of the United States under President Obama, and he ended up giving the keynote speech for the closing ceremony. Seeing someone so experienced and high up being interested and supportive in our idea was something that really inspired all of us to keep this going, and not stop with this small success. There are always more opportunities to learn and explore, and we hope to take advantage of as many as we can.
Best Financial Hack - Capital One
Best Use of MongoDB Stitch - MongoDB
Bring Consciousness To Consumerism.
Online one-click purchases often lead to buyers making impulse purchases that are unnecessary or that they may later regret. Our goal is to make buyers more aware and allow them to see how much they can save with conscious spending. We also give users the ability to compare their justifications for purchasing a product against how they feel about the purchase present day. Our goal is to mitigate a user's unconscious spending habits for a more fiscally responsible life.
Create an application that stops a buyer in the online purchasing process and requires them to answer a simple but important question. "Why Are You Buying This?" The user must enter up to a certain threshold of characters before they may continue on with the purchase process. BUT, if they stop mid-typing and decide to ditch the purchase they may click a button that says "This Is An Impulse Purchase" and abandon the purchase. Either way, the decision is tracked so that the user may later reflect on how many impulses they stopped and how many items they really needed and therefore bought anyway.
Even if the user catches very few impulses...that is still an improvement. The goal is to introduce a gap of thinking. A gap in which a user ponders their consumption habits and really thinks about what they want out of what they buy with their hard earned money.
This is a large idea so it needs to be narrowed down. Let's narrow it now to this:
Create an simple web portal for a user to sign up and view their dashboard that holds their consumption data and account settings. We will also need to create a chrome web extension so that we can execute actions on the DOM for stopping purchases and injecting our pop-up html, etc.
The initial version is a success if we can:
1.) Stop a user before purchasing and require them to provide a quick and painless justification for the purchase
2.) Collect that behavioral data and process it
3.) Present that data to the user so that they can learn about how they spend and where they can improve
Before we get into the technical explanation (to scare you away) of how this project was created, what is good about it, what is technically unstable about it, etc. We will look at some pretty screenshots:
The first thing we had to design was the main website. We need to implement user authentication, user authorization and data analytics. This site would be the central hub of impulse, containg a dashboard that generated analytics for each user based on their activity. This is what it looks like:
We also had to create a chrome extension that had two main components to it as well. The chrome extension needs a modal that acted as a middleman between the consumer and the ecommerce site. We wanted to pause the user's activity, and help them really think about what actions they were about to take. We also had to create the chrome extension pop up section that allow a user to login (so their information could be stored and pushed to the database).
Here is what the modal looks like:
Here is what the extension popup looks like:
So now I will be going through the project thoroughly and I will explain each component and how it works extensively. Let us keep in mind there is nothing ground breaking going on here. Only simple CRUD operations and the storing + moving of data and making it meaningful to the user at the end of the day. Despite this simplicity, we believe the project delivers on its intended goal and holds promise for expansion later on.
The hackathon is a very rushed and intense process so yes...the code isn't perfect. Much is repeated. Much could be refactored into modular functions. Some variables could be extracted into a file with global scope. And on and on and on...either way we tried our best to hit the deliverables and have a working application with decent structure.
I will be walking through the components and just be looking at the code and explain what is happening as I go.
The web portal runs on a Node.js and uses Express for serving static assets and managing endpoints that the chrome extension and web portal both use for access. We create a connection to the remote mongo database, partition off session data into its own data store so that it doesn't take up server RAM using connect-mongo, configure global middleware, add error handlers, and start the server. We also extracted all endpoints into their own routes file to make things easier to work with.
When designing the endpoints we had to decide if the Node server would just heavily serve the web portal (pulling db data, passing it in the model to the view, rendering the view) or be more system oriented (serve as a RESTful API that served JSON to authenticated users and both the extension and web portal would send requests to it for the data they need).
In short, we kind of did both just to get things working and up and running. It was hard to decide. So we started out with the former and later when designing the chrome extension (which we did 2nd) we realized that the latter was a better solution to avoid repeated code. The key here is that we know about this and kept in mind to make no operations too tightly coupled so later changes can be made easily.
Anyway, yes, so we have basic routes for rendering pages. We also have custom middleware that runs on the '/dashboard', '/sign-in', and 'sign-up' pages to ensure that:
1.) If a user is signed in they don't need to sign-up or sign-in. They can be redirected to the dashboard if they hit that endpoint.
2.) If they aren't signed in then they can't see the dashboard. Send them to the sign-in page.
For sign-up and authentication we would simple get the user to sign up with email and password. The password is hashed in a pre-save hook (hook that runs before the document is saved) with 13 rounds of Bcrypt (which takes about 1 second to make a pretty secure hash) and saved to the database. Upon signup the unique value on the mongo document '_id' is used to create a session cookie that is checked for to ensure authentication (middleware uses this global value). The 'userId' value is globally avaliable to all views for consumption via the res.locals object. For signing in we simply hash the password entered and compare it to what the database holds.
So for me (Ben) a challenge was working with MongoDB Atlas and deciding what the database schema would be. For previous projects I used services like mLab for MongoDB. I had to learn how to create a cluster, hook up the cluster to a Stitch Application, setting permissions, connecting to the cluster's shards and visualizing the db with RoboMongo...it was a pain because each component would have a different version of the MongoDB driver (between my terminal, the mongoose library, RoboMongo, etc.). But eventually I SSH'ed in and could ensure login worked, seed some documents with purchase data, and just view the database to work with it.
I kept the purchase data on the user document for simplicity but going back I might possibly reconsider that and move the purchase data into its own collection and map the documents to user documents. Then again it really depends on how much data we intend a user document to store and unnecessarily splitting the data into 2 separate but linked documents might just be overkill. It was just something that I had to mill over. Continuing on...yes, we also have the public folder that holds images, js, and stylesheets too.
For the frontend we had to decide between using Angular and EJS for dynamic templating. We just went with the lightweight solution of EJS since we would have a relitively simple dashboard with graphs and tables of course. I personally like Angular better since it is a more natural solution to dynamic web pages but EJS sufficed for our purposes.
Next we will talk about the Chrome Extension. This is the part that caused more of a problem since the whole team was pretty inexperienced in making chrome extensions and how the environment would behave. Here is a chart I made that describes this (as well as my whole existence spent programming):
The Google Chrome Extension was...well a chrome extension. The whole team had little to 0 experience making a chrome extension but we do know javascript and html so we thought it'd be a breeze!! Well...it was actually a lot harder than we thought.
Contexts and sharing data. So the chrome extension has two components: the main dashboard that pops up when the extension icon is clicked (extension component) and the html that is injected into the webpage (webpage component). Here is the problem...each component runs in a totally isolated context...aka a variable name 'var1' set to 1 in the webpage component does not exist in the extension component's context.
Since it is a separate context...there is literally another whole console for the extension component on top of the actual webpage's console. It took Michael and I nearly an hour and half to realize this was the root of our problems when we were working on setting up login (on the extension component) and data just wouldn't move between the files. We searched google chrome documentation for nearly 2 hours and exhaustively went through 10+ Stack Overflow article attempts at solutions as well as the official Google Chrome Extension docs on cross-extension messaging found here.
Nothing worked. No code worked. It was really frustrating.
So call us crazy, call us naive developers...so be it...in the spirit of a hackathon we decided to get creative and hack/enginner our own (I think funny) solution to sharing data between the two isolated components. So what we basically knew is that each of these components could talk to the Node.js server and hence have access to the database.
Michael proposed that we create a Auth database collection and when a user sign's in on the chrome extension we map the client's id to the '_id' on the user's document that is retrieved from a successful sign-in. Then when the webpage component wants to post data it can post it to the correct user id that is logged in by asking an auth endpoint (passing the client ip as a path param) what user id is authenticated on the client ip. When a user logs out or the extension closes the auth document is disposed of.
We both agreed that this was a very hacky solution to a problem that should be solved by some form of messaging inherent to the Google Chrome Extension API but decided to try it just for the challenge and the heck of it and it turned out that it worked pretty well.
But yes, it is not a stable way to auth a user (what if another user authenticates on the same ip...that'd be a one to many relationship which cannot be tolerated, what if a hacker knows the ip of someone logged in and can pull their id then manipulate another user's document? Then they can manipulate a document that is not theirs).
Either way with just a few more hours of researching this aspect of the application could be secured so it was just an experimental thing for us since this is not a production application or even near it.
Importing libraries and global variable scope naming problems. The biggest problem with this is how insidious it is. Javascript will hoist variables and functions leading to a clouding of the global namespace and if you are loose with your naming conventions it could come back to bite later.
You will not get a specific line that your code if failing on. You will only see something resolve as undefined and have no reason why and all you can do is move script files around and rename things until the problem resolves. This happened when we were loading the MongoDB Stitch minified js. It had variable names in it that when loaded after certain scripts led to the script being rendered useless and throwing an error internally.
We found that issue just from speculation and it turned out to solve the problem. On top of that when working with the Chrome Extension we could not make use of npm and require('') statements in the way we could easily import and manage libraries on our Node server. I don't personally know too much about importing libraries into js files so it was a challenge working with moving data around different files and working with libraries.
Getting MongoDB Stitch to work was definitely a challenge. There was a good amount of documentation reading and question asking that had to take place to get Stitch to work in our frontend but I don't attribute this to the platform as much as to our naiveness when it comes to working with frontend JS for a Google Chrome Extension.
For example we would hold the logged in user's "_id" in a global field as a string but it turns out the when executing a search against the "_id" field you must use an ObjectId object format of the string or else the search just won't come up with anything even if a document's "_id" field as a string matches the string being searched for.
We tried many libraries to convert the string into an ObjectId object but even after converting it still did not work for some reason so we just added another field to user documents that was a string representation of the "_id" field to search against.
So again, another tiny work around that can be solved easily with a more thought out patch that actually solves the core issue.
- Supporting more than just Amazon. Expanding support to other serviecs where impulsive purchases may take place online.
- Remove tiny bugs that are still in some places
Despite all of the technical challenges that we faced I am proud of my team and I. We had our arguments, we made our naive decisions, we insulted each other, we complimented each other, we had fun, and we created the idea that we had set out to create. There is nothing else like a hackathon environment where it is just pure focus at least for me. Just the human and the machine. A clean slate.
I used to believe that I knew everything but what I have realized overtime is that everyone has their great competencies. I am pretty competent with Node.js and MongoDB and have seen so many ways a server can crash that many bugs I just know instantly like it is common knowledge. But I'm weak at some aspects of frontend.
This is where Michael filled the gap. He is excellent at frontend and seeing where things can go wronng there and where solutions can be found. Richard is also very competent at this and is a critical thinker. These are things that I cannot do myself and can do much better working with individuals with said competence.
Basically, when we can find an intersection between these specials skills we have the recipe to create something elegant...something that matters. When team members support each other and see where one can excel and where they themselves fit in and contribute...it just creates an environment where everyone feels like they have a part and they matter just as much as the next person.
I could ask for nothing more than the teammates that I believe in and trust. And the trust that you give is as important as the trust you get in return.
And this is what I think we learned during Bitcamp. We learned to cooperate, we persevered through the insurmountable, grew as people, and had a good time doing what we have dedicated so much of our lives to.
Technology.
- Node.js - Event-Driver Server-side Platform used
- Express.js - Node.js web application framework used
- MongoDB - MongoDB for Database
- MongoDB Stitch - Backend as a Service for executing frontend db operations
- RoboMongo - MongoDB GUI for Database Seeding, Cluster Visualization, & Testing
- EJS - Dynamic Templating and Interpolation
- Bootstrap - Bootstrap for Frontend
- jQuery - Client-Side Document Object Model (DOM) Manipulations and Asynchronous JavaScript & XML (AJAX) Requests
- Chart.js - Frontend chart library
- npm - Package Manager
- WebStorm - WebStorm IDE
- Atom - Text Editor
- VSCode - Text Editor
- Flaticon - Icon assets
- The guys at the MongoDB booth. They were super friendly and helped us with some issues. We <3 you.
- Ben - You made a really sexy readme. Good job.