DEV Community: Dillion Huston

Refactoring a FastAPI Journey and Route API for clarity and maintainability

Dillion Huston — Sun, 22 Feb 2026 13:16:12 +0000

RouteReality v1.3 is Live

I’m excited to announce that RouteReality v1.3 is now available. This release focuses on improving stability, cleaning up the core logic, and preparing the system for bigger features in the future. It’s more than just a version bump — it’s a step toward making RouteReality a more reliable and maintainable platform for community-driven, real-time bus tracking.

What RouteReality Does

RouteReality is an open-source real-time bus arrival prediction system. It combines static timetable data with live journey events reported by users. The goal is simple: to give people a clearer picture of when their bus is actually arriving, rather than relying solely on the static schedule. The more users interact with the system, the smarter and more accurate the predictions become.

How RouteReality is Different

Many Belfast-based bus trackers focus on tracking events after they happen, such as when a bus departs, arrives, or is delayed. These systems are mostly reactive.

RouteReality, on the other hand, is predictive and community-driven:

It predicts bus arrival times instead of just reporting past events.

It blends static timetables with live user reports for more accurate predictions.

It uses community input to improve accuracy over time, so the system learns from repeated journeys.

Predictions include a confidence measure, showing how reliable the estimate is.

It’s open-source and developer-friendly, making it easy for others to contribute or extend the system.

What’s New in v1.3

This update focuses on stability, reliability, and improving the foundations of the system.

Stabilization and Improvements

Added UI screenshots to the README to help new developers understand the app.

Improved handling of journey event types for a clearer journey lifecycle.

Expanded prediction payloads to include context such as recent event counts, source metadata, and historical data.

Introduced more robust logging and instrumentation throughout the prediction and event handling layers.

Naming and Refactor

Renamed key prediction fields (for example, static_dt is now reference_time) for better clarity and consistency.

Centralized prediction refresh logic to reduce duplicated code and improve maintainability.

Improved timetable loading and fallback logic for situations where static data is limited.

Bug Fixes

Fixed crashes caused by unsafe timetable unpacking.

Stabilized prediction confidence scoring when limited data is available.

Improved API error handling for invalid routes or stops.

This release sets the stage for v2, which will include features like authentication, personalized experiences, more sophisticated prediction models, and deeper community engagement tools.

You can view the full v1.3 release notes here:
https://github.com/dillionhuston/RouteReality/releases/tag/V1.3

The updated README also includes guides and screenshots to help you get started:
https://github.com/dillionhuston/RouteReality/blob/main/README.md

What’s Next

We’re already working toward:

User accounts and preferences

Prediction models that consider time-of-day patterns and historical trends

Improved mobile-friendly UI and performance

Stronger community reporting and feedback loops

A big thank you to everyone who has tested, reported bugs, and provided feedback. Your contributions are helping shape the future of RouteReality.

Happy building and coding!

Fixing the Ghost Bus Problem: How Weighted Averages Can Improve Real-Time Public Transit Predictions

Dillion Huston — Wed, 11 Feb 2026 19:25:57 +0000

Many users (myself included) have noticed a recurring issue with the Belfast bus system—timing discrepancies and "ghost buses" that don’t show up. Buses often arrive either too early, too late, or not at all. This issue has been ongoing since late December 2023, with over 10,000 metro services cancelled or missing in 12 months, causing frustration among commuters.

The Minister for Transport has even commented that "ghost buses" are "simply not acceptable."

The Data Problem

The crux of the issue is simple: static timetables don't align with reality. According to reports, 2,500 complaints have been made to Translink, with passengers frustrated by buses that “disappear” from digital displays, or app schedules that don't reflect cancellations at all.

These discrepancies lead to wasted time, missed connections, and decreased trust in public transport. The solution? A real-time arrival prediction model that uses historical data and user-reported events, rather than relying solely on static schedules.

Enter Weighted Averages

In statistics, weighted averages allow us to make certain data points more important than others. This is particularly useful in cases like the Belfast bus system, where the most recent data is likely the most accurate predictor of future events.

A weighted average works by assigning a weight (or "confidence score") to each data point, and adjusting predictions based on those weights. In this case, the more recent bus arrival times are given higher weights since they reflect the latest, most relevant information.

How It Works in Practice

For instance, imagine we have the following bus arrival times:

08:02

08:05

08:07

08:10

08:12

We assign weights like this (newer data gets higher weight):

08:12 = 5

08:10 = 4

08:07 = 3

08:05 = 2

08:02 = 1

Now, we convert these times into minutes since midnight:

08:12 = 492 minutes

08:10 = 490 minutes

08:07 = 487 minutes

08:05 = 485 minutes

08:02 = 482 minutes

Next, we multiply each time by its corresponding weight:

08:12 (492m) × 5 = 2460

08:10 (490m) × 4 = 1960

08:07 (487m) × 3 = 1461

08:05 (485m) × 2 = 970

08:02 (482m) × 1 = 482

Sum them up:

2460 + 1960 + 1461 + 970 + 482 = 7333

Then, we sum the weights:

5 + 4 + 3 + 2 + 1 = 15

Finally, we calculate the weighted average by dividing the total sum by the total weight:

7333 ÷ 15 = 488.87 minutes past midnight, which is 08:08:52 (rounded to 08:09).

This weighted average gives us a more accurate prediction of the bus arrival time, based on real-time performance rather than relying on outdated, static schedules.

How This Solves the Ghost Bus Problem

Here’s where the magic happens: by using weighted averages to calculate real-time predictions, we move away from static timetables and instead create dynamic predictions that react to the real-time performance of buses.

Every time a bus arrives, that data point gets added to the system, and the system recalculates the expected time for the next bus. The more recent arrivals have a higher weight, meaning the predicted arrival time always reflects the latest performance.

For passengers, this means no more waiting around in the rain, unsure when (or if) their bus will arrive. Instead, they get a live ETA based on actual performance, not just scheduled times.

Why This Matters for Developers

The concept of weighted averages is straightforward, but its real-world application in transport systems shows the power of data-driven predictions. In a public transit scenario like this, relying on historical performance (rather than static timetables) makes a huge difference in delivering a better user experience.

The model could be further enhanced with machine learning to predict delays, cancellations, and bus frequency, factoring in variables like traffic patterns, weather conditions, or driver availability.

For developers working on similar projects, this kind of dynamic prediction model has wide-ranging applications—any system that relies on real-time data (e.g., ride-sharing, delivery systems, public transit apps) can benefit from this approach.

TL;DR

To fix the ghost bus problem in Belfast, we use weighted averages to predict bus arrival times dynamically. By giving more weight to recent bus data, we move away from static timetables and create more accurate, real-time predictions, ultimately improving the passenger experience.

Closing Thoughts

This solution illustrates a simple but effective way of using historical performance data to improve real-time predictions. It also opens up opportunities to build better, smarter systems that adapt to the real world, helping developers address similar challenges across various industries.

Check the project out here

Why Use Weighted Averages for Journey Arrival Predictions?

Dillion Huston — Sun, 08 Feb 2026 15:40:41 +0000

Release: V1.1 – 08-02-2026

Accurately predicting arrival times is harder than it looks. Static timetables rarely reflect reality, and user-reported data can be noisyand inconsistent. In V1.1, the prediction system takes a big step forward by introducing weighted averaging of recent user journey data, alongside a confidence scoring and improved fallback logic.

This release focuses on one core idea:

Recent, real-world behaviour matters more than theoretical schedules.

The Problem
Traditional arrival prediction systems rely heavily on static timetables:

They assume journeys behave the same every day
They don’t adapt to traffic, delays, or personal habits
They fail badly when conditions change

On the other hand, user-reported journey data is closer to reality. But it comes with its own issues:

Some data points are old
Some are outliers (missed stops, breaks, anomalies)
Sometimes there’s not enough data at all#
So the real challenge is:

How do you trust real-world data without letting bad or outdated data ruin predictions?

The Solution: Weighted Averages

Instead of treating all journey data equally, V1.1 introduces weighted averaging, where:

Recent journeys have more influence
Older journeys gradually matter less
Outliers are naturally diluted
Predictions adapt over time

This allows the system to learn without overreacting.

How Weighted Averaging Works (Concept)
Each past journey contributes to the prediction. But not equally.

Example weighting strategy:

Last journey: weight 0.5

Journey before that: weight 0.3

Older journey: weight 0.2

The predicted arrival time becomes:

(predicted_time) =
(journey_1 × 0.5) +
(journey_2 × 0.3) +
(journey_3 × 0.2)

If a user’s commute suddenly changes (roadworks, new route, traffic pattern), and a report is submitted. The new journey-event data quickly pulls the prediction in the right direction, without instantly removing historical context.

Real-World Explanation

Think about estimating how long it takes you to get to work.

You wouldn’t say:

“Google Maps says 30 minutes, so it’s always 30 minutes.”

You’d think:

Yesterday it took 38 minutes (traffic)
The day before it took 35

Last month it was closer to 28

Naturally, you’d trust yesterday more than last month.

That’s weighted averaging. We humans do it instinctively.

Example in Practice
Let’s say a user reports these recent arrival times:

Journey Arrival Time
Most recent 37 mins
Previous 35 mins
Older 29 mins

With weights applied:
(37 × 0.5) + (35 × 0.3) + (29 × 0.2)
= 18.5 + 10.5 + 5.8
= 34.8 minutes

Instead of blindly predicting 29 (timetable) or 37 (last journey), the system predicts ~35 minutes, which is far more realistic.

What’s New in V1.1?

Added:
Weighted averaging of recent journey data
Confidence scoring for arrival predictions

Clear UI distinction between:
Predicted times
User-reported events and times

Changed
Prediction logic now prioritises recent user data over static timetables
Improved fallback behaviour when data is sparse or unavailable

Fixed

Edge cases where no recent journey data exists
Improved journey creation process
Better error handling for invalid or malformed data

Why does this matter?

This approach makes the system:
More adaptive
More honest about uncertainty
More reflective of real-world behaviour

It builds user trust over time and creates a more accurate model

Instead of pretending predictions are always correct. V1.1 embraces probability, confidence, and learning — which is exactly how good systems should behave.

Deploying RouteReality: The Real Challenges of Running a Live, Real-Time Bus Prediction System

Dillion Huston — Tue, 03 Feb 2026 18:12:33 +0000

RouteReality: Building a Community-Powered Bus Tracker for Belfast
When I first launched routereality.co.uk, the goal was simple: give Belfast and Northern Ireland bus users better, more accurate arrival predictions than the official sources provide. Unlike apps that rely solely on scheduled timetables or delayed GPS feeds, RouteReality is fully community-powered.

Users check predicted times, wait at the stop, and tap to report when the bus actually arrives. Every report feeds back into the system, refining predictions for everyone in real time.

Today, the site runs 24/7, covering 100+ routes and 17,000+ stops, with live updates constantly streaming in from real users across the country. But building and deploying a system like this one that people depend on every day was far from straightforward. Here are the main problems I encountered along the way, and how they shaped the project.

1. Keeping Real-Time Data Accurate When Users Are Always Reporting

The core of RouteReality is user-submitted arrival reports. In theory, more reports = better predictions. In practice, the live nature of the system creates immediate challenges.

Timing mismatches and outliers — People report arrivals at slightly different times due to boarding the bus, network delays, or simply tapping a second too early/late. Early on, a few bad reports could mess with predictions by minutes. I had to implement outlier detection (ignoring reports more than ~3 minutes off the median) and time window clustering to group reports for the same bus instance.

Duplicate or spam reports — With users constantly using the site, especially during peak commute hours, the same bus stop could receive multiple reports in seconds. Without careful deduplication logic (based on user session, location hints, and timestamp proximity), predictions would jump erratically.

Sparse data in the early days— When the user base was small, many stops had zero or one report per day. Predictions defaulted to timetable estimates, but users expected better. Bootstrapping accuracy required careful fallback logic and incentives to encourage early reporting.

**2. Scalability and Performance Under Constant User Load
**Unlike a static site, RouteReality has users actively querying predictions and submitting reports at all hours. The system needs to handle concurrent reads/writes without lag, especially during busy periods.

Database pressure — Storing millions of timestamped reports requires a time-series-friendly setup. Early prototypes using a standard relational DB choked on write-heavy loads. Moving to a more scalable store (with proper indexing and partitioning by route/stop/day) prevented slowdowns.

Server costs and monitoring — Running 24/7 means no off-hours for heavy maintenance. Unexpected spikes in traffic (e.g., bad weather driving more bus usage) could spike costs or cause brief slowdowns. Setting up real-time monitoring dashboards became essential to catch issues before users noticed.

Live Deployment Nightmares: No Room for Downtime Deploying updates to a live system with constant user activity is unforgiving. Even a 30-second outage frustrates someone waiting at a rainy stop.

Zero-downtime deploys — Early deploys caused brief interruptions as the server restarted. Implementing blue-green deployments or rolling updates eliminated that pain, but required more infrastructure setup.

*Bug fixes under pressure *— A subtle bug in report aggregation once caused predictions to drift by 5+ minutes for a popular route during evening rush. Users noticed immediately and reported it (ironically helping debug). Hotfixes had to be rolled out without breaking ongoing sessions.

*Testing in production-like conditions *— Local tests missed real-world issues like network latency on mobile data, varied device clocks, or users in poor signal areas. Gradual rollouts and feature flags became my best friends.

Lessons Learned and What's Next
Launching RouteReality taught me that real-time, user-dependent systems are as much about people as technology. Community engagement is the biggest variable. The more people report, the better it gets, but getting that branch started requires patience and careful tuning.

Despite the challenges, the system is live, improving daily, and already helping commuters in Belfast and beyond. Future plans include better outlier handling, optional location-based reporting (with privacy controls), and deeper analytics to spot patterns (e.g., chronically late routes).

If you're a regular user, thank you for every report. It directly makes predictions more accurate for everyone. And if you haven't tried it yet, head to the journey page and start reporting. The more we all contribute, the better RouteReality becomes.

Always cross-check with official Translink sources, as RouteReality remains an independent community project.

Posted February 2026

Deploying My First Task Automation App — Lessons Learned and Tips for Beginners

Dillion Huston — Tue, 25 Nov 2025 21:36:24 +0000

Hey everyone!
I just shipped my first real project to production: https://dillonhtask.netlify.app/

It’s a small but practical task automation app. Right now the live version focuses on sending email reminders, while the local version (on GitHub) includes an extra feature that automatically cleans up old files. More features are in the pipeline — this is just v0.1!

The main goal wasn’t to build the next Todoist killer. It was to finally go through the entire process of taking something from “works on my machine” → actually live on the internet, and document all the face-palm moments along the way.

Spoiler: there were many.

What the App Does Right Now

Online: Send yourself (or others) email reminders at a scheduled time
Local-only (for now): Auto-delete old downloads/temp files
Planned: More automations, proper backend, cron jobs, webhooks, notifications, etc.

Even in its current tiny form, I already use the reminder feature daily.

The Painful (But Invaluable) Problems I Hit

1. “It Works on My Machine” Syndrome

Everything was perfect locally. Deployed to Netlify → half the CSS and all images 404’d.

Root cause: I was using relative paths like ../assets/logo.png. They work when you open index.html directly, but break when served from a sub-route.

Fix: Switch to root-relative paths → /assets/logo.png (note the leading slash).

Lesson: Production doesn’t care about your local file system. Always test the production build locally (npm run build && serve -s build).

2. The Dreaded SPA Refresh 404

Clicking a React Router link? Fine.

Direct visit or page refresh on /settings? 404 city.

Why: Netlify (like most static hosts) tries to find a real file at that path. There isn’t one — it’s client-side routing.

Fix: Add a _redirects file inside the public/ folder (or at the build output root):


text
/*    /index.html   200
That single line tells Netlify: “For every route, serve index.html but keep the 200 status” → React Router takes over.
3. Pointing Netlify at the Wrong Folder
My project looked like this at one point:
textproject/
├── src/
├── public/
├── build/
├── random-old-crap/
└── who-knows-what/
Netlify kept deploying an empty site because the publish directory was wrong or the build folder name changed between frameworks.
Fix: Cleaned everything up and explicitly set:

Build command: npm run build
Publish directory: dist (Vite) or build (Create React App)

4. Thinking Ahead: Environment Variables
The app doesn’t have a backend yet, but I already added .env variables on Netlify for future email API keys, etc.
Why bother now? Because adding them later means redeploying and potentially exposing secrets if you forget.
My Exact Deployment Checklist (Works Every Time Now)

npm run build locally → verify it works with serve -s build
Push to GitHub
Netlify → “New site from Git”
Connect repo
Settings:
Build command: npm run build
Publish directory: dist (or build)

Add _redirects file if it’s an SPA
Deploy → profit

Total time once everything is clean: ~60 seconds.
Biggest Takeaways (Especially for Beginners)

Deployment is a skill on its own — treat it as such
Local ≠ Production. Always test the actual build output
Use root-relative paths for assets (/assets/...)
For SPAs on Netlify/Vercel: you need a rewrite/redirect rule
Clean project structure saves hours of debugging
Set up environment variables early
Automate nothing until you’ve deployed something

What’s Next?

Bring the file-cleanup feature online (needs a tiny backend)
FastAPI + JWT backend
Scheduled tasks (Cron-like)
GitHub Actions integration
More automations (RSS → email, price tracking, etc.)

This was a “small” project, but it taught me more about real-world development than any tutorial ever did.
If you’ve deployed something recently and hit weird bugs (especially the infamous refresh 404), drop your war stories in the comments — I’d love to hear how you solved them! 🚀
P.S. Here’s the live app again: https://dillonhtask.netlify.app/
#webdev #beginners #deployment #react #netlify

SHA-256 File Hasher & Duplicate Finder in Python

Dillion Huston — Sat, 25 Oct 2025 17:07:11 +0000

I’ve just finished a modular Python project I’m really excited about — a SHA-256 File Hasher & Duplicate Finder. This tool is designed to help developers, sysadmins, or anyone dealing with lots of files to quickly detect duplicates and manage storage efficiently.

It’s fully object-oriented and comes with a clean API, making it easy to integrate into other Python projects or use as a standalone tool. Whether you’re scanning a single file or an entire folder recursively, it computes SHA-256 hashes efficiently and keeps track of duplicates for you.

I built this to be lightweight, reliable, and zero-dependency, so you don’t need to install any extra packages. It’s a great example of combining practical Python scripting with clean software design — something that’s useful, shareable, and a nice addition to your GitHub portfolio.

If you’re learning Python, building projects, or just want to tinker with file management tools, this project is perfect to explore, experiment with, and contribute to.

I’m also growing a Python & dev community on Discord where beginners and experienced programmers can hang out, share projects, get help, and collaborate. I’d love for you to join — whether you want to test the tool, discuss Python, or just meet like-minded devs.

Join here: https://discord.gg/cBuEjejr

If you have ideas for improvements, want to contribute, or just want to chat about Python projects, this is the place! Let’s make it a friendly, active community for learning, sharing, and building cool things together.

Check out the GitHub repo here: https://github.com/dillionhuston/SHA-256-File-Hasher

Can’t wait to see what you all think — and I hope to see you in the Discord server! 🚀

From Kiddie Projects to Production-Ready APIs: My FastAPI Journey at 18

Dillion Huston — Wed, 13 Aug 2025 11:43:36 +0000

From Kiddie Projects to Production Ready APIs: My FastAPI Journey at 18

I’m 18 and from West Belfast. I started like most self-taught devs — small Python scripts, half-finished tools, and code that kind of worked if I didn’t touch it too much.

Lately I’ve been getting more serious. I built a proper backend system using FastAPI, with file uploads, JWT authentication, background tasks, and a full deployment setup.

Not here to pitch anything. Just sharing what I built, what went wrong, and what I learned.

Why I moved from Flask to FastAPI

I used Flask for a while. It’s great for small projects, but once I started adding real features like auth, file handling, and background jobs, things got messy.

FastAPI felt more structured without being overcomplicated. A few things stood out:

Request validation with Pydantic was way cleaner
Async support was baked in from the start
It auto-generates API docs, which was actually useful for testing
Strong type hints made my editor smarter and saved me from dumb mistakes

What I built

Here’s what’s working right now:

Auth system using JWT
File uploads with SHA-256 hash checks
File listing and secure downloads
Background task scheduling with Celery and Redis
Docker-based deployment to a Hetzner server using Coolify
Basic test coverage using pytest

The whole thing runs through FastAPI with async endpoints. It’s not perfect but it works well, and it’s clean enough to share.

What went wrong

Nothing crazy, but I definitely hit some walls.

Dependency injection in FastAPI took a while to wrap my head around
Testing async routes was different than what I was used to with Flask
Uploading large files without blocking the whole server needed some extra work
Docker config took more trial and error than expected

Most of it came down to learning by doing. I broke it, then fixed it.

What I’d tell other devs

Don’t overthink things early on. Build something useful, then polish it later.

Start using type hints early. They don’t seem important until your project gets bigger, then they save you from major headaches.

If something feels overcomplicated, break it down and rebuild it. That’s how I learned most of this stuff.

And don’t wait until you're an “expert” to put your code out there. You learn more when other people can see what you’re working on.

What’s next

I’m planning to:

Create an API key system for public usage
Improve the admin tools
Write a proper setup guide for others to use the project

Final thoughts

This is the first time I felt like I built something solid end to end. I’m not in uni, I’m not working at a tech company, and I’m not using AI to do the work for me.

Just writing code and building something that solves a real problem.

If you’re working on something similar or want feedback on your own backend, feel free to drop a comment.

Here’s the repo if you want to check it out:

https://github.com/dillionhuston/Task-Automation-API

Tags:

fastapi python backend selftaught devjourney programming

Adding SMTP Email Notifications to FastAPI Using smtplib and Environment Variables

Dillion Huston — Sun, 03 Aug 2025 15:05:04 +0000

In my Task Automation API, I added email notification support using Python’s smtplib. The setup is minimal, uses no extra packages, and leverages environment variables to securely manage SMTP credentials.

Here’s a breakdown of the implementation, inspired by this commit:

View commit on GitHub

Email Sending Function with smtplib

import smtplib
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart
import os

def send_email(recipient: str, subject: str, body: str):
    sender = os.getenv("SMTP_SENDER")
    password = os.getenv("SMTP_PASSWORD")
    smtp_server = os.getenv("SMTP_SERVER")
    smtp_port = int(os.getenv("SMTP_PORT", 587))

    msg = MIMEMultipart()
    msg["From"] = sender
    msg["To"] = recipient
    msg["Subject"] = subject
    msg.attach(MIMEText(body, "plain"))

    with smtplib.SMTP(smtp_server, smtp_port) as server:
        server.starttls()
        server.login(sender, password)
        server.sendmail(sender, recipient, msg.as_string())

Environment Variables Setup

To keep secrets out of the codebase, define these in your .env file or server environment:

SMTP_SENDER: Your email address
SMTP_PASSWORD: SMTP password or app-specific password
SMTP_SERVER: SMTP host, e.g., smtp.gmail.com
SMTP_PORT: Port number, usually 587

How I Use It

After a user schedules a task, once and it’s validated, I call send_email to notify them:

send_email(
    recipient=current_user.email,
    subject="File Upload Successful",
    body=f"Your file {file.filename} was uploaded and verified."
)

Why This Approach?

No external dependencies
Secure configuration with environment variables
Easy to extend for HTML emails or attachments later

Wrap Up

Adding SMTP email with smtplib is a lightweight, effective way to send notifications in your FastAPI app. This pattern fits nicely in automation workflows like mine.

Check out the full commit for details:

GitHub link

If you need help integrating emailing or environment management in your project, let me know.

Leveling Up My Task Automation API: Models, Routes, and Scheduling

Dillion Huston — Fri, 01 Aug 2025 12:10:05 +0000

Hey DEV community, I’m excited to share some fresh updates I pushed to my Task Automation API in this commit. This one’s all about getting the task model, routes, and scheduling logic in shape, setting the stage for a solid task management system. If you liked my HTTP status codes post, you’ll dig this dive into building a practical API. Let’s break it down.

What’s New in This Commit?

This commit (114bbb8) lays down the foundation for managing tasks. Here’s the quick rundown:

Task Model: Upgraded it with clean, reliable fields.
Routes: Added endpoints to schedule, list, and cancel tasks.
Scheduling Logic: Got tasks saving to the database smoothly.
Task Types: Set up support for reminders and file cleanup.
Validation: Used Pydantic to keep scheduling times on point.

Let’s take a closer look at what’s cooking.

1. Task Model Upgrade (`app/models/tasks.py`)

I gave the TaskModel in app/models/tasks.py a serious tune-up to make it robust and ready for action. Here’s what changed:

UUID for IDs: Switched to uuid.uuid4() for unique task IDs to avoid any overlap.
Better Fields: Refined user_id, task_type, schedule_time, and status with SQLAlchemy, adding constraints like nullable=False for required fields.
Timezone Support: Added a utcnow() function to ensure schedule_time uses UTC, keeping things consistent across timezones.

Here’s the updated code:

import uuid
from sqlalchemy import Column, String, ForeignKey, DateTime
from sqlalchemy.orm import relationship
from sqlalchemy.ext.declarative import declarative_base
from datetime import datetime, timezone

Base = declarative_base()

def utcnow():
    return datetime.now(timezone.utc)

class TaskModel(Base):
    __tablename__ = "Tasks"
    id = Column(String, primary_key=True, index=True, default=lambda: str(uuid.uuid4()))
    user_id = Column(String, ForeignKey("users.id"), nullable=False)
    task_type = Column(String, nullable=False)
    schedule_time = Column(DateTime(timezone=True), nullable=False, default=utcnow)
    status = Column(String, nullable=False, default="scheduled")

This model is now set to handle tasks.

2. New Routes for Task Management (`app/routers/tasks.py`)

I added some key endpoints in app/routers/tasks.py to make the API functional:

Schedule a Task (POST /schedule): Lets users create and schedule tasks, validated with Pydantic’s TaskCreate schema.
List Tasks (GET /list_files): Pulls up all tasks for the logged-in user. (Heads-up: list_files is a naming oops—I’ll rename it to list_tasks soon.)
Cancel a Task (GET /cancel/{task_id}): Updates a task’s status to “cancelled” to ditch it.

Here’s the code:

from fastapi import APIRouter, Depends, HTTPException, status
from app.routers import get_current_user, get_db, TaskModel, Session, User
from app.schemas.Tasks import TaskCreate, TaskResponse, TaskStatus, TaskType
from app.utils.task import schedule_task

router = APIRouter()

@router.post("/schedule")
def schedule_logic(
    task: TaskCreate,
    db: Session = Depends(get_db),
    user: dict = Depends(get_current_user)
):
    try:
        new_task = schedule_task(db=db, user_id=user.id, task_data=task)
        return TaskResponse.model_validate(new_task)
    except Exception as e:
        raise HTTPException(status_code=400, detail=str(e))

@router.get("/list_files", response_model=list[TaskResponse])
def list_tasks(
    db: Session = Depends(get_db),
    user: dict = Depends(get_current_user)
):
    tasks = db.query(TaskModel).filter(TaskModel.user_id == user['id']).all()
    return tasks

@router.get("/cancel/{task_id}", response_model=TaskResponse)
def cancel_task(
    task_id: int,
    db: Session = Depends(get_db),
    user: dict = Depends(get_current_user)
):
    task = db.query(TaskModel).filter(TaskModel.id == task_id, TaskModel.user_id == user['id']).first()
    if not task:
        raise HTTPException(status_code=400, detail="task doesnt exist or cant be found")
    task.status = "cancelled"
    db.commit()
    db.refresh(task)
    return task

These routes are locked down with authentication and handle database operations cleanly. I’m also using HTTP status codes (like 400 for errors), tying back to my HTTP status codes post for clear error communication.

3. Scheduling Logic and Task Types

The commit includes scheduling logic (in app/utils/task.py, not shown in the diff) that saves tasks to the database. I also added support for two task types:

Reminders: For notifying users at a specific time.
File Cleanup: For deleting files (still in progress).

Pydantic validation ensures scheduling times make sense, so no one’s trying to schedule a task for last week.

4. What’s Next?

This commit gets the API in a good spot, but there’s more to do:

Task Execution: Need to implement the actual logic for reminders and file deletion.
Fix Naming: list_files should be list_tasks—my bad.
Better Errors: Plan to make error messages more specific.
Scheduler Integration: Looking at tools like APScheduler or Celery to run tasks on schedule.

Why This Matters

This commit is a big step toward making the Task Automation API a practical tool for managing tasks, whether it’s reminders or cleaning up files. It’s built with FastAPI and SQLAlchemy, keeping things clean and scalable. If you’re into APIs or automation, this might spark some ideas for your own projects.

Check out the full commit here. Got thoughts or suggestions? Drop them in the comments—I’d love to hear what you think!

Happy coding!!

Building a User Authentication and File Management API with FastAPI

Dillion Huston — Sun, 27 Jul 2025 14:41:07 +0000

Over the past two weeks, I’ve been working on a backend API project using FastAPI. The goal is to build a solid foundation for user authentication and a file management system.

Week 1: User Authentication System

Initialized a FastAPI project with virtualenv and managed dependencies in requirements.txt.
Configured environment variables with python-dotenv for things like SECRET_KEY and DATABASE_URL.
Created the User model using SQLAlchemy with fields including id, email, hashed_password, and status flags.
Implemented JWT-based authentication including user registration, login, and token refresh.
Built user endpoints (/register, /login, /me) for managing user actions.
Added dependency injection for database sessions and authentication in the routes.
Wrote basic tests for authentication endpoints.

At the end of week one, the API supports user registration and login, returning JWT tokens for authorized access.

Week 2: File Management System

Added a File model linked to users, storing file metadata such as filename, hash, and upload date.
Created file endpoints to upload, list, and delete files (/upload, /list, /delete/{file_id}).
Handled file uploads with python-multipart, storing files on disk using unique filenames.
Computed and stored SHA-256 hashes for uploaded files to ensure integrity.
Restricted file access based on user authentication, enforcing ownership rules.
Implemented validation for file size and allowed extensions.
Started writing tests for the file management functionality.

What’s next?

Moving forward, I plan to:

Enhance file validation and error handling.
Add support for user roles and permissions.
Integrate background tasks for file maintenance using Celery.
Improve test coverage and add documentation.

Try it out

The project is open source and available on GitHub: Task Automation API

Feedback and contributions are welcome.

If you’re interested in backend APIs, FastAPI is a great framework that makes building async, secure APIs straightforward. This project is a good way to practice authentication, file handling, and database relationships.

Thanks for reading!

What I’ve Been Working On Lately: Networking Tools and JWT Auth

Dillion Huston — Sat, 05 Jul 2025 12:36:16 +0000

Over the last few weeks, I’ve been keeping things simple and focused: building small networking tools and working on secure backend authentication with Flask. Thought I’d share a quick update for those of you following my journey (shoutout to all 812 of you).

Networking Tools

Most of my recent project time has gone into understanding networking at a deeper level — not just from a textbook or video, but by building tools that interact with the network directly.

Here’s what I’ve worked on so far:

A basic port scanner written in Python
A script to send ARP requests and identify devices on the local network
Learning how data moves through different layers of the TCP/IP stack
Writing code that deals directly with packets and interfaces

This kind of low-level work has helped me build a stronger intuition for how systems talk to each other — something that really improves everything else I do in backend development.

JWT Authentication with Flask

On the web backend side, I’ve been working on setting up JWT (JSON Web Token) authentication in a Flask API.

Things I’ve been learning and implementing:

Issuing and verifying tokens securely
Protecting routes and controlling access based on token roles
Structuring the app with Flask blueprints, SQLAlchemy, and proper config separation

This is laying the groundwork for future tools and APIs I want to build — where users can log in, store data securely, and interact with the backend in a clean, secure way.

Let’s Talk

If you’ve been following my posts, I’d love to hear from you:

Want me to share one of the tools? Let me know.
Curious how I’m handling JWT or structuring the API? Ask and I’ll post more details.
Also happy to chat if you’re working on anything similar — whether it’s low-level networking or backend auth systems.

Thanks for following along. More updates coming soon.

What Are HTTP Status Codes and Why Do They Matter?

Dillion Huston — Sun, 25 May 2025 14:08:38 +0000

If you’ve ever built a web app or worked with an API, you’ve probably seen things like 404 or 500 pop up. These numbers might seem like errors — and sometimes they are — but they’re actually just how servers communicate what’s going on.

In this post, we’ll walk through what HTTP status codes are, what the common ones mean, and why you should care about them as a developer.

So, what is a status code?

Whenever your browser or app sends a request to a server (like loading a webpage or submitting a form), the server sends back a response. Part of that response includes a status code — a three-digit number that gives a quick summary of what happened.

For example:

200 means “everything went fine”
404 means “the thing you asked for doesn’t exist”
500 means “something broke on the server”

These codes are standardized and fall into five categories.

The different types (quick overview)

1xx – Just letting you know

These are informational. You’ll rarely see them directly, unless you’re digging deep into HTTP-level stuff.

2xx – Success

These are good. They mean the request worked.

200 OK – Basic success.
201 Created – Something was successfully created (like a new user).
204 No Content – Success, but there’s no data to send back.

3xx – Redirects

The server is telling the client to look somewhere else.

301 Moved Permanently – The resource has moved and it’s not coming back.
302 Found – Temporary redirect.
304 Not Modified – The client already has the latest version, no need to download again.

4xx – You messed up (client error)

These usually mean there’s something wrong with the request.

400 Bad Request – Malformed request.
401 Unauthorized – You need to log in.
403 Forbidden – You’re logged in, but not allowed to access this.
404 Not Found – The resource doesn't exist.
429 Too Many Requests – Slow down, you’re sending too many requests too quickly.

5xx – We messed up (server error)

These mean the server failed to handle the request.

500 Internal Server Error – A general error on the server.
502 Bad Gateway – The server got an invalid response from another server.
503 Service Unavailable – The server is temporarily overloaded or down.

Why should you care?

If you’re building or using an API, handling status codes properly helps everything run more smoothly. It gives your frontend clear information about what went wrong (or right), and it makes debugging a lot easier.

For example, if your app gets a 403, you know it’s a permission issue. If it gets a 500, it’s probably something on the server that needs fixing.

It also helps when writing error handling code — you don’t want to treat every error the same.

How to practice

If you want to get better at this, try writing a simple API in something like Flask, Express, or Django. Send different types of requests and play with returning different status codes.

It’s one of those small things that makes you look like you know what you’re doing — and it’ll save you time when things break.

Let me know if you want a follow-up post on how to handle these codes in your own app logic, or how to structure proper error responses.