BillSplit is an application designed to ease the process of splitting costs for groups of people who make group purchases. The application uses bills, groups, items, users, and purchases as its main underlying data objects. Users are able to create and join groups with other users, and add the purchases they have made to that group. These purchases are then used to create monthly bills which are sent out to all users of the given group. Added purchases can be approved or declined by all other group members to ensure no abuse of the billing process occurs, and users are able to view all previous purchases for their groups and themselves. Users can view analytics about their spending history and spending forecast, as well as their groups’ spending habits.
BillSplit uses a number of different technologies. Node.js was used to run the server-side code and utilizes asynchronous, non-blocking functions. This allows for the for the application to handle multiple requests concurrently, making it useful for having a large user-base. Express.js was used for the server routing for the reason that it was minimalist, flexible framework and could be customized easily. MongoDB was used for the database because of its fast reads and has Document-Oriented Storage, make the queries easy to read and understand. For the front-end technologies, BillSplit uses jQuerys’ AJAX library to make calls to the server asynchronous. Using asynchronous calls for the front end is important so that the application can load the rest of the application while longer calls are being completed.
BillSplit was largely a success for our group. We completed all of the features we intended to except for those involving third party tools. One of the major keys to BillSplit’s success was using AJAX for our asynchronous requests. Using AJAX over XHR was very useful for our application because it eased the amount of development and debugging needed to make asynchronous requests. Splitting up work between the development work and DevOps worked well since there was little overlap between the two, other than in testing, this much more work could be completed concurrently. Another big success for our team was our willingness to adapt to changes in architecture and technology. We realized quickly scss would be unnecessary, so we dropped it from our project, and when it became apparent that our purchase implementation in our class diagram wouldn’t work, we took the time to refactor our work to make future development much easier.
The first major design obstacle we faced as a group was our Milestone 2 planned implementation of the interactions between Items and Bills. We neglected to think through the structure needed to represent an individual purchase and its associated Item, cost, frequency, and quantity. As a result, we needed to add in an unplanned base class, Purchase, which encapsulated an individual instance of a purchase. As a result, we had to refactor our Bills to accept Purchases, instead of Items.We also struggled to reduce cohesion between our Bill, Group, and User objects. Both the Bill and Group objects are used directly to determine if a Bill should be displayed to the user or not, and both the Bill and User objects contain lists of purchases made by and for the given object. For the future, the bill payment schema in the database may produce a storage and request size bottleneck. To determine what payable bills are shown to the current user, BillSplit retrieves a list of all bills the user is associated with and checks the “paid” list associated with them, which resides in the group the the bill belongs to. The “paid” list is an object indexed by year and month, which grows in size and complexity as the user joins more groups. If the user is not on the “paid” list for the given month and year, the bill is shown to the user, which can be a very time consuming process if many bills have not been paid. This bottleneck could be eliminated in the future by creating a “paid bill” object that only contains the total bill price and date, and is not checked.
The most prominent technological difficulty we faced was the integration of Facebook and Paypal APIs we had initially intended to make a part of our app. We began the process of Facebook integration by uploading our app to Heroku, but ran into problems quickly as Facebook needed HTTPS to use their features and this made it a lot harder to debug locally. This made functionally integrating it and testing it to the point of confidence impossible as our Heroku deployment occured at the end of Milestone 3.5. We felt that Facebook was more useful to the app than Paypal, thus we didn’t attempt to use the Paypal API.
We also experienced many issues with DevOps and testing. The first issue we ran into (with regards to testing and DevOps) was getting integration tests to run. We were eventually able to get some integration tests to run, but once they were committed and tested within travis, they would always fail. This required many hours of troubleshooting and bug fixing to ensure that the tests could successfully run within Travis. The next issue with the DevOps was getting the build to be containerized. Although we had some prior experience with Docker, none of us had ever containerized such a complicated and multifaceted project. We were eventually able to containerize the app and the database by using a docker-compose file, but we were initially unable to get the two images to connect. After lots of trouble shooting, we eventually discovered that the reason the app could not connect to the database within the container was because of two reasons. The first reason was because we had to change the way we connect to the database, in order for it to successfully connect to the database within the container. After fixing that, we also discovered that there was a typo with one of the directories that we were referencing when building the docker image. However, in the end we were successful in creating integration tests and containerizing the app using the Docker.
Although our three-person group was relatively small, effective communication and planning for our app was difficult considering the time constraints on development that we had. Our first big group communication issue was planning: there were multiple times throughout the project where someone wasn’t clear on what needed to be worked on next. We also struggled to communicate changes and features we made as individual developers to one another. This could have been improved by smaller branches and more frequent pull requests, as well as more clear requirements of what needed to be accomplished by a specific task or change. An easy way to do this would have been an established TAC (testable acceptance criteria) for each issue that outlined exactly what it must accomplish, which could then be tested by the other two team members.
From a development and planning perspective, the largest learning experience for the team was the realization that we failed to think through our architecture from a user story perspective prior to creating our class diagram. As soon as it came time to develop our add purchase functionality, we realized we were missing a key data abstraction - the purchase object itself. As well, a better enforced review process would have likely sped up development as bugs would have been caught more quickly and a full understanding of all of the system’s components would have been easier to achieve for all team members.
With regards to DevOps and testing, there were many interesting takeaways. The first and most significant takeaway was how useful having a good testing framework was for development purposes. For our project we created unit tests and integration tests that covered almost all parts of our project. Initially, we thought since this was a relatively small-medium scale project (3 people working part time for a few months), that these tests would be more of a formality, rather than actually being useful. However, this was far from the case. The testing framework we had was very successful in detecting when we broke previously working code with new commits, and also helped ensure that each piece of our project works well together. Having these tests automated within Travis also gave us the peace of mind to ensure that our code was always up the the quality standard that we specified. Moreover, it was these tests that helped use justify our QAS. Although it was sometimes painful and time consuming to create and configure these tests, it was well worth it. In fact, if we were to continue with this project, we would put even more time towards creating more tests so that we could cover more aspects of the project. Docker was also quite useful within the scope of the project. Having the app containerized was very useful for testing purposes, since we could test a “clean” image at any time from any of our machines if we wanted to test anything. Moreover, had we gone forward with this project, using Docker would have allowed us to easily deploy this project in many different ways.
Future work on BillSplit can be broken into three distinct bodies of work: current functionality improvement, internal feature development, and external tool usage.
For current functionality improvement, we’d first like to improve the mechanism used to send bills to users and pay them. New bills automatically display in the “Pay Bills” page when they are due, but the user does not receive any direct notification of the new bill until they check the page. Unless the user is aware of the 1st of the month due date we’ve implemented for all bills in the app, the bill could be missed. To address our availability QAS, we would also like to implement an availability testing script on our Heroku app to ensure it is up and running. To begin, it could be as simple as a script running on the server that pings the webpage, but we would eventually like to expand it to include automatic Selenium-based system tests that run nightly.
Adding additional app features would also improve the BillSplit user experience. A useful feature would be custom bill due dates, as bills are currently automatically generated and sent out at the end of each month. We could leverage our frequency enum to accomplish this, allowing users to bill daily, weekly, monthly, or yearly, and set specific dates for bills, such as the bill being due on the 15th of every month. A purchase date field in our “Add Purchase” page would also be useful to allow users to add purchases to past bills if needed.
Finally, to make BillSplit more feasible as a real world app, we’d like to integrate PayPal and Facebook to improve our notification and bill payment process. The Facebook API can be used to send notifications for purchase approval and bills that are due to users for users who signed in using Facebook when creating an account. This would also improve our app security for those users as Facebook’s user confidentiality systems are undoubtedly stronger than ours. The PayPal API could be used to automatically generate payable bills that are sent to owing users, via email or messenger (if it becomes available in Canada).