DEV Community: Dhanush K

Building My First Web Backend Project: A URL Shortener with FastAPI and SQLite

Dhanush K — Mon, 28 Sep 2026 17:06:00 +0000

After completing my Personal Expense Tracker, I started my fourth project: a URL Shortener.

This was also my first web backend project, so this project was a step beyond the CLI applications I had built previously.

The goal was to learn how a backend application connects a web interface, server-side logic, and a database together.

For this project, I used Python, FastAPI, SQLite, Jinja2, HTML, and CSS.

What Does a URL Shortener Do?

A URL Shortener converts a long URL into a shorter URL.

For example:

https://example.com/some/very/long/path/to/a/page

can become:

http://localhost:8000/aB72xK

When someone opens the shortened URL, the application uses the short code to find the original URL in the database and redirects the user.

The basic flow is:

Long URL
   ↓
Generate short code
   ↓
Store short code + original URL
   ↓
Display short URL
   ↓
User opens short URL
   ↓
Find original URL
   ↓
Redirect

From CLI Applications to a Web Application

My previous projects were mainly command-line applications.

With this project, I wanted to understand what happens when a user interacts with an application through a browser.

The basic architecture became:

Browser
   ↓
FastAPI
   ↓
SQLite
   ↓
FastAPI
   ↓
Browser

This was one of the most useful parts of the project because I could see how the different pieces fit together instead of learning them individually.

Why FastAPI?

I had already started learning the fundamentals of FastAPI before beginning this project.

I had worked with API routes such as:

GET
POST
PUT/PATCH
DELETE
Path parameters
Query parameters
Request models

For the URL Shortener, I wanted to take the next step and use FastAPI to build an actual web application.

Instead of returning JSON for everything, I used FastAPI to serve HTML pages and process form submissions.

Using Jinja2 for the Interface

For V1, I intentionally decided not to use JavaScript.

Instead, I used Jinja2 for server-side rendering.

The flow is simple:

HTML Form
   ↓
FastAPI receives the request
   ↓
Process the URL
   ↓
Generate short code
   ↓
Store in SQLite
   ↓
Render the template again
   ↓
Display the shortened URL

This gave me a better understanding of the traditional server-rendered web application approach.

I also learned how FastAPI can serve static CSS files separately from the Jinja2 templates.

Database Design

The database is intentionally simple.

The application uses a single urls table:

urls
├── short_code
└── original_url

The short_code is the primary key.

For example:

short_code:   aB72xK
original_url: https://example.com/some/long/url

When the user visits /aB72xK, the application searches for that short code and retrieves the corresponding original URL.

If it exists, the application redirects the user.

If it doesn't exist, the application returns a not-found response.

Generating the Short Code

For V1, I kept the implementation simple.

The application generates a 6-character code using letters and numbers.

The generated code becomes the identifier for the stored URL.

I didn't try to build a complex algorithm for generating short URLs because the main learning goal was understanding the complete backend workflow.

Keeping the V1 Scope Small

One thing I wanted to follow with this project was scope control.

There are many things that could be added to a URL shortener:

Analytics
URL expiration
Custom short codes
User accounts
URL management
Click tracking
Authentication

But I didn't want V1 to become unnecessarily complicated.

Current V1 Scope

The completed V1 includes:

URL shortening
6-character short code generation
SQLite storage
URL redirection
Simple HTML + CSS interface
Jinja2 server-side rendering
Empty-input handling

That's enough for the application to demonstrate the fundamental URL-shortening workflow.

What I Learned

This project connected several concepts I had been learning separately.

I practiced:

Building a web application with FastAPI
Connecting FastAPI with SQLite
Designing a simple database
Separating database operations into a database class
Generating identifiers
Handling redirects
Using Jinja2 templates
Processing HTML form submissions
Serving static CSS
Structuring a small web application
Deploying a backend application

The biggest takeaway for me was understanding the relationship between the browser, backend, and database.

Project Structure

url-shortener/
├── main.py
├── database.py
├── requirements.txt
├── templates/
│   └── index.html
├── static/
│   └── style.css
├── .gitignore
├── LICENSE
└── README.md

V1 Complete

With the core workflow working, I consider V1 complete.

I intentionally stopped here instead of continuously adding features.

The project is small, but it represents an important step in my learning path: moving from CLI applications into web backend development.

This was my first web backend project, and it gave me practical experience with how a browser-based application communicates with a backend and database.

Final Thoughts

Project #4 started with a simple question:

How does a shortened URL actually work?

Building it helped me understand the answer from the backend side.

A short URL isn't simply a smaller version of a long URL. It's a short identifier that the application stores and uses to find the original URL.

For me, this project was less about building a feature-rich URL shortener and more about learning the fundamentals of web backend development.

Project #4 — URL Shortener: V1 Complete.

Links

Live Demo: https://url-shortener-k5ed.onrender.com/

Source Code: https://github.com/xDK0d3r/url-shortener

A Different Perspective

I also wrote about this project on CoderLegion, where I focused more on the development process, project architecture, and the decisions I made while building the V1.

If you're interested in a different perspective on the same project, you can read it here:

Read my CoderLegion article →

Personal Expense Tracker V2 — Edit, Validation & Error Handling

Dhanush K — Sun, 13 Sep 2026 07:12:53 +0000

I’ve completed V2 of my Personal Expense Tracker 🚀

This project started as a way to practice Python OOP, SQL, and SQLite by building something practical instead of only studying theory.

V1 focused on getting the core CRUD operations working.

With V2, I focused on making the application more reliable and user-friendly.

🆕 What I Added in V2

✏️ Edit Expenses

Users can now modify an existing expense.

The edit flow allows changing:

Amount
Category
Description
Date
Cancel the operation

This also gave me more practical experience working with SQL UPDATE statements and designing application flow around user choices.

🛡️ Input Validation

I also added validation for user input.

The application now handles things such as:

Invalid menu choices
Invalid amount input
Negative or zero amounts
Invalid category selection
Empty descriptions
Invalid dates
Impossible dates such as 2026-02-30

For example, instead of allowing invalid input to crash the program, the application asks the user to provide a valid value.

⚠️ Error Handling

While implementing validation, I also started thinking more carefully about where errors can happen and how the application should respond.

One important lesson was that input validation is not just about preventing crashes.

It is about defining what the application considers valid input and controlling the flow when the user provides something unexpected.

🧠 What I Learned

V2 taught me more than just how to add an edit feature.

I learned about:

Designing validation rules before implementing them
Using try/except for user input
Separating application flow from business logic
Handling different types of invalid input
Thinking about edge cases
Designing better CLI user interaction
Keeping the project scope under control

One thing I learned during this version is that not every possible improvement needs to be implemented immediately.

There are still things I could add, such as more advanced database error handling and additional checks, but I decided to stop V2 at the scope I originally defined.

That is also part of learning software development: knowing when a version is complete.

🏗️ Current Architecture

The project currently follows a simple separation of responsibilities:

main.py
   ↓
ExpenseManager
   ↓
Database / storage.py
   ↓
SQLite

main.py handles the CLI/application flow, ExpenseManager handles the application logic, and storage.py handles database operations.

📌 V2 Status

V2 is now complete.

The project currently supports:

✅ Add expenses
✅ View expenses
✅ Edit expenses
✅ Delete expenses
✅ Category selection
✅ Input validation
✅ Date validation
✅ Basic error handling

The main goal of this version was not to build a huge application.

It was to take the working V1 and make it more reliable while strengthening my understanding of Python, OOP, SQL, SQLite, and application design.

🔗 Project

📌 GitHub Repository: Personal Expense Tracker

I’ll continue improving the project in future versions when there is something meaningful to learn or add.

Thanks for reading! 🚀

Personal Expense Tracker — V1 Complete: Building the Core Working Stage

Dhanush K — Wed, 02 Sep 2026 17:56:33 +0000

I’ve completed V1 of my Personal Expense Tracker, a small learning project built with Python and SQLite.

This project was created primarily to learn by building rather than following a tutorial step by step.

The goal of V1 was not to build a production-ready expense tracker.

The goal was:

Build the core application flow, understand the responsibilities of each layer, and make the fundamental functionality work end-to-end.

With that goal achieved, I consider V1 complete.

Why I Built This Project

I wanted to strengthen my understanding of:

Python OOP
Classes and objects
Object responsibilities
SQL and SQLite
CRUD operations
Database design
Separating application responsibilities
How different layers communicate with each other

Instead of learning these concepts separately, I decided to combine them into one small practical project.

That's why I consider this primarily a learning project.

The objective was not to create a feature-rich application immediately, but to understand the fundamentals by actually building something.

What I Built

The application is a command-line Personal Expense Tracker.

The core V1 functionality includes:

Adding an expense
Viewing expenses
Deleting an expense
Storing expenses in SQLite
Using SQLite-generated IDs
Separating the application into different responsibilities

The database currently contains an expenses table:

Column	Type
`id`	INTEGER PRIMARY KEY
`amount`	REAL
`category`	TEXT
`description`	TEXT
`date`	TEXT

Application Architecture

One of the main things I wanted to learn was how to organize responsibilities in an application.

I structured the project into three main layers:

main.py
   ↓
ExpenseManager
   ↓
Database
   ↓
SQLite

`main.py` — UI Layer

main.py is responsible for interacting with the user through the CLI.

Its responsibilities include:

Displaying the menu
Taking user input
Calling the appropriate operation
Displaying results

The UI does not directly handle SQL operations.

`expense_manager.py` — Application Layer

ExpenseManager acts as the middle layer between the UI and storage.

It coordinates application operations and communicates with the database object.

For example:

main.py
   ↓
ExpenseManager.add_expense()
   ↓
Database.insert_expense()

This helped me understand the difference between the application's operation and the actual persistence of data.

`storage.py` — Persistence Layer

The Database class handles communication with SQLite.

Its responsibilities include:

Creating the database connection
Initializing the database
Creating the table
Inserting expenses
Retrieving expenses
Deleting expenses

This keeps database-related responsibilities separate from the UI.

Understanding Object Relationships

Another important part of this project was understanding how objects can work together.

The application creates a database object and passes it to ExpenseManager.

Conceptually:

main.py
   │
   ├── creates Database
   │
   └── creates ExpenseManager
             │
             └── uses Database

The manager receives the database dependency instead of creating its own database internally.

This was one of the OOP concepts I wanted to understand through practical implementation.

Why V1 Is Complete

There is an important distinction between:

"V1 is complete"

and

"the project is finished."

V1 is complete because its intended scope has been achieved.

The core application flow works:

User
 ↓
CLI
 ↓
ExpenseManager
 ↓
Database
 ↓
SQLite

An expense can be added and stored, stored expenses can be retrieved and displayed, and expenses can be deleted.

The different layers can communicate with each other correctly.

That is the foundation I wanted to establish in V1.

What I Learned From V1

The biggest lesson wasn't simply learning SQLite syntax or Python syntax.

It was understanding responsibility.

I learned to think about the application as separate parts with different jobs:

UI
→ communicates with the user

Manager
→ coordinates application operations

Storage
→ communicates with the database

Along the way, I gained practical experience with:

Python classes
Constructors and attributes
Methods
Object relationships
Passing dependencies between objects
SQLite tables
Primary keys
CRUD operations
SQL queries
Multi-module Python projects
Debugging
Git and GitHub

What I Didn't Focus On in V1

I deliberately didn't try to make V1 handle every possible invalid input or edge case.

Comprehensive validation and robust error handling were not the main goals of this version.

Instead, I decided to make the core functionality work first and move robustness-related improvements into V2.

This gives the project a clearer progression:

V1
Core Working Stage
       ↓
V2
Robustness + Additional Core Operation

What's Coming in V2?

Now that the core working stage is complete, V2 will focus on improving the application's robustness and functionality.

The planned V2 work includes:

Validation

Validating user input
Validating expense IDs
Handling invalid values
Handling invalid menu input

Error Handling

Handling invalid user input gracefully
Handling invalid/non-existent expense IDs
Handling database-related errors
Providing better user-facing error messages

Edit Expense

V2 will also introduce an Edit Expense operation.

The core expense operations will then become:

Create
Read
Update
Delete

or simply:

CRUD

This will make the expense management functionality more complete.

V1 → V2

The project's progression can be summarized as:

V1
│
├── Add Expense
├── View Expenses
├── Delete Expense
├── SQLite persistence
├── Layered architecture
└── Core application flow
        │
        ▼
V2
│
├── Edit Expense
├── Input validation
├── ID validation
├── Error handling
└── CLI refinement

I intentionally want to keep these stages separate.

V1 proves that the foundation works.

V2 will make that foundation more robust and complete.

Final Thoughts

This project started as a learning exercise to understand Python OOP and SQLite by building something practical.

Completing V1 gave me more than just another project for my GitHub repository.

It helped me understand how a small application can be divided into responsibilities and how those components communicate with each other.

I'm treating V1 as a completed learning milestone, not as the final state of the application.

The core working stage is done.

🔗 Project

📌 GitHub Repository: Personal Expense Tracker

Now it's time to build on that foundation.

V1: Complete.

Core working stage: Achieved.

Next: V2 — Validation, Error Handling & Edit Expense.

I Spent 7 Days Building a Simple Python To-Do List… Here's What It Actually Taught Me

Dhanush K — Thu, 09 Jul 2026 17:37:36 +0000

When I first thought about building a To-Do List application, I assumed it would take a day or two.

After all, it's "just" a CRUD app... right?

Seven days later, I realized I had underestimated how much there was to learn.

This wasn't just about adding, editing, and deleting tasks. It became an exercise in thinking like a software developer instead of simply writing Python code.

Why I Chose This Project

My previous project was a Number Guessing Game. It helped me become comfortable with Python basics, but I wanted something closer to a real application.

A To-Do List seemed like the perfect next step because it introduced concepts that many real-world applications use:

Creating, reading, updating, and deleting data (CRUD)
Persistent storage
Input validation
Error handling
Modular project structure

I wanted to build everything myself rather than copy a tutorial.

The Reality

The hardest part wasn't Python syntax.

It was deciding how the application should work.

Questions like these came up constantly:

How should I store each task?
Should I use a list or a dictionary?
Where should file handling happen?
When should data be saved?
What should main.py be responsible for?
How can I keep the code organized as the project grows?

These aren't syntax problems.

They're software design problems.

And solving them taught me far more than memorizing Python functions.

Features I Built

The finished application includes:

➕ Add tasks
✏️ Edit tasks
🗑️ Delete tasks
✅ Mark tasks as completed
📋 View all tasks
💾 Save tasks automatically to a JSON file
📂 Load tasks when the application starts
⚠️ Input validation
🛡️ Exception handling
🧩 Modular project structure

What I Learned

Over the course of seven days, I strengthened my understanding of:

Functions
Lists and dictionaries
Loops (for and while)
Conditional statements
CRUD operations
File handling
JSON data persistence
Exception handling
Input validation
Modular programming
Separating application logic from data storage

More importantly, I learned that building software is about making good design decisions—not just writing code.

The Biggest Lesson

Before this project, I often thought programming was mainly about knowing the right syntax.

Now I think differently.

The syntax is usually the easy part.

Understanding the problem, designing the solution, organizing the code, and deciding how everything fits together—that's where the real learning happens.

What's Next?

This project is now feature-complete for its current scope.

I'm continuing to build more Python projects to improve my problem-solving skills and deepen my understanding of software development.

Each project is a little more challenging than the last, and that's exactly the goal.

📂 GitHub Repository: https://github.com/xDK0d3r/todo-list

🌐 Portfolio: https://xdk0d3r.github.io/

If you're also learning Python by building projects, I'd love to hear what you're working on or any feedback you have on this project.

Thanks for reading! 🚀

I Built My Personal Portfolio Website with GitHub Pages

Dhanush K — Mon, 29 Jun 2026 17:17:32 +0000

I just launched my personal portfolio website using GitHub Pages.

It brings together my projects, GitHub repositories, and ways to connect with me in one place.

I'm currently learning Python backend development and documenting my journey by building projects and sharing what I learn.

Feedback is always welcome!

🔗 Portfolio: https://xdk0d3r.github.io/

My First Python Project: Lessons Learned While Building a Number Guessing Game

Dhanush K — Sat, 27 Jun 2026 15:11:00 +0000

Hello everyone! 👋

I'm a self-taught Python learner, and today I completed my very first programming project—a command-line Number Guessing Game.

It isn't a large project, but finishing it feels like an important milestone because it's the first application I built from start to finish on my own.

Why I Choose This Project

After learning the basics of Python, I wanted to build something practical instead of only solving small exercises.

A number guessing game seemed like the perfect beginner project because it combines many fundamental programming concepts into one application.

Project Features

The game includes:

🎲 Random number generation between 1 and 100
🎯 Five attempts to guess the correct number
⌨️ User input validation
✅ Handles invalid input using exception handling
📏 Range validation (only accepts numbers from 1–100)
💬 Helpful feedback after each guess ("Too Big" or "Too Small")
🏆 Win and lose conditions
🧩 Organized code using multiple functions instead of one large script

What I Learned

This project helped me understand how different Python concepts work together in a real application.

Some of the topics I practiced include:

Variables
Functions
Return values
Conditional statements (if, elif, else)
While loops
Exception handling with try and except
User input validation
Using Python's random module
Breaking a program into smaller, reusable functions

One lesson I learned is that separating code into functions makes the program much easier to understand and maintain.

Challenges

The biggest challenge was making the program accept only valid input.

I didn't want the game to crash if the user entered letters or special characters, so I implemented exception handling and input validation until a valid number was entered.

I also wanted to ensure the player could only enter numbers between 1 and 100, which added another layer of validation.

Looking Ahead

This project is feature-complete for its current scope.

I have ideas for future versions, such as difficulty levels, score tracking, and replay support, but for now I'm leaving the project as it is and moving on to build new applications.

My goal is to keep creating projects that gradually become more challenging while improving my Python skills.

Source Code

You can check out the complete project on GitHub:

GitHub Repository: https://github.com/xDK0d3r/Number-Guessing-Game

Final Thoughts

Every experienced developer started somewhere.

This Number Guessing Game is my first completed Python project, and I'm excited to continue learning by building more projects and sharing my progress along the way.

If you're also learning Python, I'd love to hear what you're working on.

Happy coding! 🚀

DEV Community: Dhanush K

Building My First Web Backend Project: A URL Shortener with FastAPI and SQLite

What Does a URL Shortener Do?

From CLI Applications to a Web Application

Why FastAPI?

Using Jinja2 for the Interface

Database Design

Generating the Short Code

Keeping the V1 Scope Small

Current V1 Scope

What I Learned

Project Structure

V1 Complete

Final Thoughts

Links

A Different Perspective

Personal Expense Tracker V2 — Edit, Validation & Error Handling

🆕 What I Added in V2

✏️ Edit Expenses

🛡️ Input Validation

⚠️ Error Handling

🧠 What I Learned

🏗️ Current Architecture

📌 V2 Status

🔗 Project

Personal Expense Tracker — V1 Complete: Building the Core Working Stage

Why I Built This Project

What I Built

Application Architecture

main.py — UI Layer

expense_manager.py — Application Layer

storage.py — Persistence Layer

Understanding Object Relationships

Why V1 Is Complete

What I Learned From V1

What I Didn't Focus On in V1

What's Coming in V2?

Validation

Error Handling

Edit Expense

V1 → V2

Final Thoughts

🔗 Project

I Spent 7 Days Building a Simple Python To-Do List… Here's What It Actually Taught Me

Why I Chose This Project

The Reality

Features I Built

What I Learned

The Biggest Lesson

What's Next?

I Built My Personal Portfolio Website with GitHub Pages

My First Python Project: Lessons Learned While Building a Number Guessing Game

Why I Choose This Project

Project Features

What I Learned

Challenges

Looking Ahead

Source Code

Final Thoughts

`main.py` — UI Layer

`expense_manager.py` — Application Layer

`storage.py` — Persistence Layer