Daily News Report

Motivation

The fall of my sophomore year of college I wanted to rush AKPsi, the only business fraternity on campus. At the time, I was not very well-versed in honestly either Computer Science as well as Finance-y business stuff. So, being the genius I was, I spent a few hours planning this project and out and creating a very rough beta version instead of actually reading the news. The idea was, and still is, pretty simple: an automated email platform that would email out daily alerts for news articles so that I don't have to spend time scrolling various news sites for articles that may or may not be interesting.

Design Decisions

Phase 1: Naivety

There are two main versions of this project that I'll talk about here. The first one is what I consider to be the naive version. Naive not in the sense of the solution or the code generatedAlthough it certainly wasn't robust, as you'll see soon, but in the sense of my own skills as a programmer. This was my first time programming outside of the classroom and while at the time I thought this project was super cool, I've since outgrown that feeling.

The first version is very simple. The server is ran through FastAPI and has just a few endpoints. /register takes an email as input and a series of boolean flags that specify the type of news the user wants to receive. /update_preferences takes an email and then the same boolean parameters as the register endpoint, allowing users to update what they want to see. The nail in the coffin is that the medium in which these endpoints interact with the actual email service is a users.csv file that is public in the repo.

If I were to start fleshing out everything wrong with this design, it would take way too long so I'll narrow it down to the main points. The biggest flaw in this is that any malicious actor has the ability to screw around with other users' config in /update_preference, but also to theoretically crash the program by signing up hundreds of fake emails in /register. Additionally, the interface has terrible UX. The magic arguments corresponding to different news categories is insanely bad design and requires way too much effort from the user to even figure out what they're trying to turn off and/or on.

The actual email service is less problematic but still very simple. A local .env file does a lot of work here, keeping track of an API key to AlphaVantage as well as metadata to allow emails to be sent through a personal account. News, divided into General, Business, Sports, and Finance categories, is sent out to users if they subscribe to a given subtopic.

From an implementation perspective, you can definitely guess that the code quality was pretty terrible here. Super long function signatures, no python type definitions, bad project management, as well as an inefficient email algorithm that repeatedly and unnecessarily opens up multiple SMTP connections. Ultimately, I would say the idea was there, but the execution wasn'tWhich is totally reasonable too, I was a dud at the time.

Phase 2: Overhaul

This next phase, and where the project currently stands, addresses a lot of the issues from the first version while also adding some new ones and improving the code base. The first problem I wanted to tackle was the blatant publication of the users signed up and their according preferences for the news they want to see. Ultimately, this would be an easy decision in the form of a database user.db. Each user in this SQL databaseFor beginners, SQL is best used when you have very structured data. Since we don't need much fluidity for Users, SQL is the clear winner consists of:

users (
    id                 INTEGER PRIMARY KEY,
    email              TEXT UNIQUE NOT NULL,
    token_hash         TEXT,
    verified           INTEGER,
    verify_token_hash  TEXT,
    general_news       INTEGER,
    business_news      INTEGER,
    finance_report     INTEGER,
    sports_news        INTEGER
)

We pack everything we will possibly need to know, which admittedly isn't an insane amount of info, into the one user entry. You'll notice that some hashing and auth metadata has been added as well. The token_hash is the user's permanent auth token. Generated via the SHA-256 algorithm from the random key assigned to the user, this token ensures that no one can tamper with another user's data. Yet that doesn't solve the problem of someone else spamming new accounts for their friends. For that reason, we have the verified and verify_token_hash. verified has a simple usecase as it is a bit flag on if the associated user is verified, which they do via verify_token_hash. The flow is simple, a user is registers, they get a verification email sent to them with a key in plain-text. After receiving this, they simple need to hit the POST /verify endpoint, enter the key, and then the key will be hashed and checked to the verify_token_hash.

Other than that, a few misc items have been improved or changed. I added an /unregister endpoint and improved the algorithm for how the emails are sent out. Now, instead of pulling in the same email articles for every user, the emails are queried once and then distributed. Finally, I take a lot of pride in how I present my repositories and the development practices used, so I modernized the repo to use uv and implemented proper semver controls.

Here is the final design:That is, without the actual email system as that is not too interested

Results

To be completely honest, I stopped using this after a few weeks but it was really nice to have when I needed it. I think the best thing I got out of this project was the amount of enjoyment I felt from making something for myself that I actually got value in. This was one of the key moments that really made me love Computer Science, so I owe it that. With all of that being said, I enjoyed modernizing this project up to better reflect the quality I like to have in my repositories, but I assure you I'll come back every now and again to look at these old commits and go back to the times when I made this.