DEV Community: Ajith

Fashion E-Commerce Store

Ajith — Wed, 02 Sep 2026 06:12:57 +0000

When I started this project, the brief was simple to state and deceptively large to build: a full fashion e-commerce platform — product catalog, size and color variants, filters, an "AI-style" size recommender, cart, checkout, JWT auth, order tracking, and a wishlist. Here's a walkthrough of how it came together, the decisions behind the architecture, and a few lessons learned along the way.

Why FastAPI + MySQL

FastAPI was the obvious choice for a REST backend like this. Automatic OpenAPI docs (you get /docs for free), native Pydantic validation, and async support made it easy to move fast without sacrificing structure. MySQL paired with SQLAlchemy's ORM gave a relational model that fits e-commerce data naturally — products, variants, orders, and users all have clean foreign-key relationships that a document store would make awkward.

The stack ended up being:

Backend: FastAPI + Pydantic v2
Database: MySQL 8.x via SQLAlchemy ORM, with Alembic for migrations
Auth: JWT (OAuth2 password flow) + bcrypt password hashing
Frontend: Server-rendered Bootstrap 5 pages with vanilla JS calling the same REST API a mobile app would use
Designing the catalog: the size/color variant problem

The trickiest early design decision was how to model a product that comes in multiple sizes and colors, each with its own stock count. The naive approach — a single stock field on the product — falls apart the moment you need "Medium, Black" to sell out while "Large, Black" is still available.

The fix was a separate ProductVariant table: one row per size+color combination, each with its own SKU and stock quantity. The Product table holds shared data (name, description, price, category), while ProductVariant handles everything that varies by selection. This is the same pattern most real fashion retailers use under the hood, and it made the cart and checkout logic much simpler — every cart line item points to a specific variant, not just a product.

Product (1) ──< ProductVariant (many)
"Classic Crew Neck T-Shirt" S/Black, M/Black, L/Black,
S/White, M/White, ...
The size recommendation engine

The brief called for "AI-based size recommendations." Rather than reaching for a trained ML model on day one (which needs a lot of labeled fit data most fashion startups don't have yet), I built a rule-based measurement-matching engine instead — one that's explainable, debuggable, and immediately useful with just a size chart.

Here's the core idea: each product category has a SizeChart with min/max chest, waist, hip, and height ranges per size. When a user submits their measurements, the engine scores every size in the chart:

A perfect fit inside the range scores 1.0
A near-miss just outside the range gets partial credit that decays with distance
Missing measurements are skipped, not penalized

Then it layers on two nice touches: a fit preference (snug/regular/loose) nudges the result up or down a size, and if the user tells us a previous size "ran small," that feedback becomes a strong prior for the next recommendation.

The result isn't a black box — it comes back with a confidence score and a plain-language explanation ("Your chest and waist measurements best matched size M"). That transparency matters more than raw accuracy for a first version: customers trust a system they can question. And because it's isolated in one function, swapping in a real ML model later is a drop-in replacement, not a rewrite.

Checkout and the payment gateway abstraction

Checkout needed to feel realistic without wiring up real payment credentials for a demo project. The solution was a small PaymentGateway interface with a mock implementation underneath:

python
class PaymentGateway(ABC):
@abstractmethod
def charge(self, amount, method, token, order_number) -> PaymentResult:
...

Cash-on-delivery orders confirm instantly. Card and UPI payments simulate authorization with realistic latency and even include a deterministic failure hook for testing declined payments. Because every router depends on the interface rather than a specific provider, adding a real Stripe or Razorpay integration later means writing one new class and flipping a config value — no changes to the checkout endpoint itself.

The checkout flow also had to guard against a subtle race condition: a user adds an item to their cart, someone else buys the last unit, and now the original user tries to check out. The endpoint re-validates stock for every line item at checkout time, not just when items were added to the cart, and only decrements stock after payment succeeds.

Auth, and a real bug worth mentioning

Password hashing went through bcrypt via passlib initially — the standard, well-documented choice. But testing surfaced a real compatibility issue: newer versions of the bcrypt package dropped an internal attribute that older passlib versions probe for during version detection, causing spurious failures even though the underlying hashing worked fine. The fix was to call bcrypt directly instead of routing through passlib's compatibility layer — fewer moving parts, and one less place for library version drift to cause silent breakage. It's a good reminder that "well-established library" doesn't mean "immune to version mismatches," and that testing the actual auth flow end-to-end (not just reading the docs) catches things a code review alone wouldn't.

What's next

A few things I'd tackle if this were headed to production rather than a portfolio piece: rate limiting on the login/register endpoints, moving product images to real object storage instead of placeholder URLs, and swapping the mock payment gateway for a real processor. The architecture is set up to make all three straightforward additions rather than rewrites — which, in the end, was the real goal of this project: not just shipping features, but shipping them in a shape that can grow.

Built as part of a Python full-stack internship project. Full source, setup instructions, and API docs available in the project README.

Bookstore Management

Ajith — Tue, 01 Sep 2026 02:15:55 +0000

As part of my Python full-stack internship, I was tasked with building a real-world e-commerce application from scratch: a bookstore management system with a catalog, inventory tracking, a shopping cart, checkout with payments, order management, reviews, and a wishlist. Here's what I built, how it's put together, and a few honest lessons from getting it running on my own machine.

The Feature List

The brief covered pretty much everything you'd expect from a real bookstore:

Book catalog — categories, authors, genres, and search across title, ISBN, author name, and description
Inventory management — live stock counts, a "reserved quantity" that prevents overselling the last copy while someone's payment is processing, and low-stock alerts (both in the admin panel and as an email-able management command for cron jobs)
Shopping cart — session-based, so it works without forcing a login, with quantity limits tied to actual available stock
Checkout — shipping address, payment method selection, live order summary, free-shipping threshold
User authentication — registration, login/logout, password reset, and a profile page, all built on Django's own django.contrib.auth rather than reinventing it
Order management — order history, a status timeline (Pending → Processing → Shipped → Delivered), and cancellation that releases reserved/purchased stock back to inventory
Reviews & ratings — one review per user per book, 1–5 stars, with average ratings surfaced everywhere a book appears
Wishlist — add, remove, and one-click "move to cart"

On top of the storefront, I also built a full Django REST Framework API covering books, authors, categories, genres, and reviews, with a staff-only low_stock endpoint for inventory dashboards — because a real bookstore eventually needs a mobile app or a partner integration, and building the API alongside the website (instead of bolting it on later) turned out to be much less painful.

The Stack
Backend: Django 4.2 + Django REST Framework + django-filter
Database: SQLite for local development, MySQL 8.x as a one-line config swap for anything closer to production
Frontend: Django templates + Bootstrap 5 (no separate frontend framework — for a project like this, server-rendered HTML is simpler to reason about and ships faster)
Payments: a mock gateway I wrote myself, so the whole checkout flow is demoable without real API keys — cards ending in 0000 even simulate a decline, so the retry-payment path isn't just theoretical
The Part Nobody Warns You About: Environment Setup

Here's the honestly useful part of this post. The code was the easy bit. The thing that actually ate an afternoon was getting a working Python environment on Windows:

Python version mismatches. I initially had Python 3.14 installed — brand new, and neither Pillow nor mysqlclient had prebuilt Windows wheels for it yet. Pip tried to compile them from source, which then failed because I didn't have a C compiler or MySQL's header files configured. The fix was simply installing Python 3.12 alongside 3.14 and pointing my virtual environment at that instead (py -3.12 -m venv venv). Newer isn't always better when your dependencies haven't caught up yet.
MySQL friction. Getting mysqlclient to build on Windows requires MySQL's C headers to be discoverable, which is its own rabbit hole — and then there's actually remembering the root password you set months ago (or didn't set at all). For a project like this, I ended up defaulting the whole app to SQLite for local development, with MySQL support still fully wired in behind a single environment variable (DB_ENGINE=mysql) for whenever a real deployment needs it. Django's ORM abstracts the database engine completely, so nothing in the application code needs to change either way — it's purely a settings toggle.
PowerShell isn't Bash. Small thing, but if you're following a tutorial written for Mac/Linux, source venv/bin/activate will fail silently-ish on Windows. It's venv\Scripts\Activate.ps1 instead, and you may need to loosen PowerShell's execution policy first (Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser).

None of this is hard once you know it — but it's exactly the kind of thing that isn't in the Django docs and eats real time on a first project.

What I'd Tell Past Me
Default to SQLite during development. Reach for MySQL/Postgres only when you actually need to test against it — every extra piece of infrastructure is one more thing that can be broken on setup day.
Pin dependency versions, but not too tightly against your Python version. A hard pin like Pillow==10.4.0 will break the moment someone runs a newer Python than existed when that pin was written. A version range gives pip room to pick a build that actually has a wheel.
Build the inventory logic before the checkout logic. Reserving stock at order-creation time (rather than just at payment-success time) is what stops two customers from "buying" the last copy of a book simultaneously — and it's much easier to bolt onto checkout from the start than to retrofit later.
Write a management command for the boring stuff. The low-stock report (check_low_stock) is three lines of ORM filtering, but as a scheduled command it turns into a genuinely useful daily alert with almost no extra work.
Wrapping Up

This project ended up being a solid cross-section of what "full-stack" actually means in practice: data modeling (inventory reservations, snapshot order items so price history doesn't silently change), auth and permissions, a REST API, session-based state (the cart), and — maybe most realistically — the unglamorous work of making sure a stranger on a fresh machine can actually get the thing running.

If you're doing something similar for your own internship or portfolio, my one piece of advice: get the environment setup boring and reliable first. Everything else is just Django.

Food Delivery App

Ajith — Wed, 26 Aug 2026 06:32:17 +0000

FoodExpress — Food Delivery Platform
A full-stack food delivery web app built with Python (Flask), SQLAlchemy, and HTML/CSS/Bootstrap, covering all the required internship task features:

🍽️ Restaurant listings — search & filter by cuisine
📋 Menu management — admin panel to add/enable/disable/delete menu items per restaurant
🛒 Cart & checkout — add items, adjust quantities, single-restaurant cart rule
💳 Payment gateway (simulated) — card entry form, validated & "processed" server-side
📦 Order tracking with real-time delivery status — a live progress tracker that polls the server every few seconds and advances through: Order Placed → Confirmed → Preparing → Out for Delivery → Delivered
👤 Authentication — signup/login (Flask-Login, hashed passwords)
🛠️ Admin dashboard — manage restaurants/menus, view & advance orders

Task Submission - DAS006560 - Online E-Commerce Shopping Platform

Ajith — Fri, 14 Aug 2026 18:21:51 +0000

My Task Submission

I recently completed my task submission and learned a lot from working on this project. It gave me a good opportunity to practice my skills and understand how different parts of the project work together.

While working on the task, I faced some challenges, but I solved them by researching, testing, and making improvements. I also learned more about writing clean code, using Git, and organizing my project properly.

Overall, this task was a valuable learning experience. I am happy with my progress and look forward to improving my skills through more projects in the future.

Thank you to the community for the opportunity to share my work!

# My Task Submission I recently completed my task submission and learned a lot from working on this project. It gave me a good opportunity to practice my skills and understand how different parts of the project work together. While working on the task, I

Ajith — Fri, 14 Aug 2026 18:15:38 +0000