Trailhead Tracker - Update 3 - Project Complete.
Even More Roadblocks
Picking up where I left off: I successfully got AWS to accept and provide my SSL certificate to the proxy. The next morning, I was ready to finalize the project and eagerly tested the server using Postman.
200 - OK!
The response code indicated success, and Postman returned exactly what I was looking for: point sum, badge count, current rank—everything. It felt like a huge win, and I couldn't help but celebrate a bit too loudly (to my partner’s annoyance, and maybe even the baby’s).
With that success, I turned to test the website, expecting the same result.
Instead—CORS errors.
Why now? I had set up the proxy to avoid this exact issue. I double-checked my setup, but nothing stood out as the culprit. Frustration started to creep in again..
One More Try
I was tempted to stop right there. Troubleshooting had been exhausting, and at this point, I just wanted it over with. Paying for AWS support even crossed my mind. Still, I decided to take one last close look at the CORS errors to see if I had missed something obvious.
In the developer console, I noticed two key details:
- The preflight request returned status 204.
- The POST request returned status 200.
Both were working to some degree, so I dug into the response headers. That’s when I spotted it:
A duplicated header.
The "allowed origin" was listed twice—https://phantomdevops.com. Both Flask and Nginx were setting conflicting CORS policies. I decided to remove the CORS-related settings from Flask, leaving Nginx to handle it entirely.
As soon as I saved the changes, everything seemed to break.
The proxy stopped responding. The /health endpoint returned 404. Postman failed completely. I reverted both Flask and Nginx configurations to their previous states, but nothing changed. Something else was causing the issue.
After following the error logs, I found the upstream Nginx configuration was missing the host IP in the .conf file, leaving only the port. This wasn’t something I had ever touched, but I corrected the IP, and everything started working again.
The Final Test
With everything back online, it was time to test the API function again.
This time—it worked.
The tracker successfully populated data on the website. I quickly added visuals to organize the output and created a progress bar to make it more user-friendly.
After about 40 hours of work, countless bugs, and a lot of trial and error, the Trailhead tracker was finally complete.
Lessons Learned
Looking back, this project taught me a lot about the process of building and debugging applications.
- Photos Are Essential. Screenshots of key moments would make posts like this far more engaging and informative.
- Documentation Is Key. Keeping a detailed log of changes would have saved me so much time when things went wrong.
- Version Control Matters. Having a reliable way to track changes can prevent unnecessary stress when troubleshooting.
This project also gave me a new appreciation for developers. Whether they’re full-stack engineers, game designers, or freelancers, it’s clear how much effort goes into creating even seemingly simple solutions.
For a first project, this was a significant challenge. But finishing it proved that even complex tasks can be manageable with persistence.
I’ve gained valuable experience and perspective, and I’m looking forward to applying these lessons to whatever comes next.