My Journey with Package Fiend
About a month ago, in May, 2020, I (Ben Keener) and my partners, Travis Bearden and Nehal Shastri, set out to create a centralized solution to package tracking. We sought to make it easier for you to keep track of items purchased online. We aimed to make this web app useful for everyone, but it would be most useful for people who often order items online or small businesses who need to keep track of many incoming and outgoing packages. Of course, to achieve this, we needed to break into parts.
Nehal worked on deployment and testing using TravisCI along with full-stack integration. Travis worked on the design of the website, along with implementing it and connecting it to the backend. I worked on the backend and setting up our deployed environment in AWS. Personally, I wanted to learn as much as I possibly could through this project. I wanted to tackle as many technologies and use as many APIs as made sense.
The idea for PkgFiend (read: Package Fiend) came to us during a brain-storming session. As a group, we wanted a project that would be useful and would make use of several external APIs. At the time, Travis had recently ordered a computer’s worth of parts to build a new machine to develop on. He expressed his need for a tool to make it easier to manage and monitor his deliveries (as that’s half the fun). Instantly we knew that this was a perfect portfolio project idea, it ticked all of the boxes. I love the idea of being able to harness data and present it in a very useful way. I think the way our team implemented the travel map for each package is the epitome of that.
Project Summary
Data Flow
The main flow of the program starts at the user’s browser. When a user visits our website, they are directed through our load balancer and provided an SSL certificate for an https connection. Upon requesting one of our tracking pages, the request will come through our dynamic API, which will make the needed requests to USPS, UPS, and FedEx, depending on the tracking numbers. The app server will also direct the client to the static routing service (Using Express.js) for static files. Lastly, when a user accesses their dashboard, they are authenticate through Passport.js on our app server, then the associated calls are made to the external APIs to update the user’s package information.
Technologies Used
Our group used a slew of technologies to complete our project the way we wanted:
Our app/web server runs on Node. We considered Deno and Typescript, but decided on Node since the support and userbase was already so widespread. We had decided that we wanted to use JavaScript, so Node was the logical option.
Within Node, we used Express.js for our page serving and web routing. This integrated well with Passport.js which we used for user login/authentication. Passport also enables us to (in the future) integrate with external login options like Facebook, Github, or Google fairly easily.
For our external API requests, we used Axios, a promise-based HTTP request library.
On our frontend, we decided to use pure HTML/JavaScript/CSS, without any frameworks, to expand our learning in those languages. However, we took advantage of an open-source map library called Leaflet, which allowed us to show where packages are/have been.
For our deployment, we went with an AWS solution called Elastic Beanstalk. This allowed us to deploy our Node app with very little configuration and offers scaling upon increased website demand.
To deploy to Beanstalk, we used TravisCI which allowed us to simply push to GitHub and TravisCI would package up our build and ship it to Beanstalk to be deployed.
To store our user data (username, list of packages, etc.) we used AWS’s DynamoDB. We wanted a NoSQL solution, since we had all worked with MySQL in the past and wanted to try something new
Features
The biggest feature of our product is the ability to track multiple packages at the same time. Our “tracking page” provides a simple dropdown to allow users to instantly switch between tracking numbers and get cool data for all of them! Most shipping providers don’t even have this feature on their own website!
A minor, but very important, feature of our project is the ability to add names to a package. When a user is logged in, they are able to add a name to a package to be able to easily understand which package is which without having to look at the ugly tracking number.
Another feature, but one most people don’t think about, is the ability to create an account and sign in. I was the primary developer of this feature (and I might do a writeup on my process implementing this sometime) and I learned a lot while doing it. A user can sign up with as little as a name, username, and password. The biggest concern for me while developing was security. I won’t go into too much detail on this, but I can confidently say that even if someone with malicious intent had access to all user data, they would not be able to extract the passwords.
Most Difficult Challenge
By far, the most difficult challenge for me was Elastic Beanstalk. Overall, the service is overwhelmingly simple and usually works without a hitch. At first, we had our deployment of our initial static site working flawlessly, however, the issue arose when we wanted securely have our keys available to the deployed version of our app. Our first solution was to add the keys at the build stage in TravisCI, however after a few tries, we realized that this was not going to work and switched to AWS Secrets Manager. What we didn’t immediately realize was that our Beanstalk environment had been corrupted through our numerous deployments. The problem seemed to have stemmed from the EC2 instances created by beanstalk, but I was never able to get to the exact root of the problem. After trying to debug the current environment, I decided to switch to a fresh Beanstalk environment.
The next issue I ran into in this process was not actually Beanstalk’s fault. In the process of TravisCI merging our branches, the one line of code that told our server to actually start listening to requests was moved to a spot that rendered it useless. This meant that the server was technically running without errors, but was not responding to any requests. I was able to get to the bottom of this problem after some rubber-ducking by downloading the deployed version of the app directly from Beanstalk and running it. After discovering the reason our server was not responding to requests, I added back the line of code we needed, deployed, and it worked! Thank goodness.
What I Learned
Overall, this project was an amazing learning experience, which was exactly what I wanted to get out of it.
Technical Take-Aways
I learned a lot about the AWS system and some of the features I had previously found daunting I am know able to implement and understand (almost) effortlessly.
I also learned a lot about data-flow within an app. One of the more difficult aspects of our app was connecting the frontend and backend features. One of the things I am most proud of is generalizing methods to simplify implementation in code. One example of this is in the way our app gets geolocation data for a location string. We used Google’s Geolocation API, but I realized that there was not always a need to ping it for every single package. A user would likely have many packages come through the same location (warehouse or destination), so there was no need to ask what the coordinates for that location are every single time. My solution to this was to build a cache with AWS. I generalized the code by making one method to be used by our API to get the location from a string, which looks super simple. Behind the scenes, this method would check if the string is cached or not, do a request if needed, and return the coordinates for the requested location. This meant that any function that needed coordinate data did not have to care if the location was cached or not, it could just ask for it.
What I Learned About Myself
Personally, I learned a lot about myself as a developer through this project. I found out that I really enjoy smaller, incremental projects with a simple main idea. Our project had a very simple and useful MVP which allowed us to quickly finish what we needed for the project and later add features as needed. This enables us to be in a great position to add new things in the future (which we do plan to do). I think the experience of this project will encourage me to look for jobs that allow me to work on projects set up in a similar way.
This project also confirmed the value of regular team meetings (standups). Sometimes just verbalizing what I’m working on to another team member allowed me to focus my energy on what really needed done. This method also allowed all team members to offer constructive criticism on things in-development, which greatly improved the quality of our product.
What I’d Do Differently
Honestly, I’m really happy with 99% of the decisions our team made as far as our tech stack, MVP, etc. and I don’t wish we had done much different at all. However, if I were to do this project again, I would change almost everything. This may seem contradictory, but the most valuable aspect of this project was, again, the learning, so if I were to do it again, I would pick new technologies and methods to be able to learn more about different areas of software engineering.
For a few specific examples, I would probably use Deno instead of Node, simply to learn Typescript and to focus on the security-centered environment that Deno offers. I would also probably choose a framework for the frontend such as React or Vue, since they are both very popular frontend options that I’d like to learn more about. I think our project also has room to be more mobile-optimized, so I would look for something to help me to do that from the start.
Closing
Our project is live and you can check it out at https://www.packagefiend.com and I’d encourage you to give it a try! If you want to see our super-cool landing page which summarizes the project with some sleek visuals, you can find that here. If you’d like to take a look at our code, you can find our GitHub repository here.
Thank you for getting all the way through (or skipping to the end)! My name is Ben Keener and I am a Full-Stack developer who loves learning and aspires to bring good ideas to life! If you’d like to give me feedback on PackageFiend, this blog post, or my bad puns, you can reach me in a number of ways: LinkedIn, Twitter, or GitHub.