Forem: Samwit Adhikary

How I Built a Full Stack Community Platform from Scratch - And What I Learned

Samwit Adhikary — Wed, 08 Apr 2026 19:15:25 +0000

A real story of building AskLoop - combining Medium + Dev.to + Stack Overflow with Django 5 + React 18

The Problem I Kept Seeing

I've spent a lot of time on developer platforms. And I kept noticing the same pattern everywhere.

You ask a question - it gets buried.
You share something valuable - it disappears in 48 hours.
A great discussion starts - nobody follows up.

There's always content. But rarely real depth.
There's always activity. But rarely meaningful interaction.

That bothered me enough to build something about it.

So I built AskLoop - a community platform that combines:

✍️ Medium-style long-form articles
❓ Stack Overflow-style Q&A with voting
💬 Dev.to-style forum discussions

All in one place. No noise. No paywalls.

Live demo: https://askloop-here.netlify.app

What I Built

Before diving into the technical stuff, here's what the platform does:

3 post types - Article, Q&A, Forum Discussion
Rich text editor with image upload (TipTap)
Nested comments with threaded replies
Q&A voting - upvote/downvote + accept answer
JWT Authentication - register, login, refresh tokens
User profiles - bio, social links, reputation
Badge system - auto-awarded at reputation milestones
Real-time notifications - likes, comments, follows
Full-text search with filters
Bookmarks, follows, reports
Account deletion with password confirmation

Tech Stack

I wanted to use tools I could actually understand and explain - not just copy-paste a boilerplate.

Backend

Django 5.0.6
Django REST Framework 3.15.2
Simple JWT (djangorestframework-simplejwt)
django-allauth + dj-rest-auth
PostgreSQL via Supabase
Gunicorn + Nginx
Whitenoise

Frontend

React 18 + TypeScript
Vite
TipTap (rich text editor)
shadcn/ui + Tailwind CSS
Axios + React Router v6
date-fns

Infrastructure

Backend → Linode (Ubuntu 22.04)
Frontend → Netlify
Database → Supabase PostgreSQL

Total cost: $5/month (just the Linode server)

One thing I learned the hard way - Netlify is HTTPS but my Linode server is HTTP. Browsers block mixed content. The fix was proxying the API through Netlify using a _redirects file:

/api/* http://your-server-ip/api/:splat 200
/* /index.html 200

Simple. Elegant. Took me 2 hours to figure out 😅

Django REST Framework - What I Learned

Custom User Model

Always use a custom user model from day one. Changing it later is painful.

class User(AbstractUser):
    bio = models.TextField(max_length=500, blank=True)
    reputation = models.IntegerField(default=0)
    role = models.CharField(max_length=20, choices=Role.choices)
    is_banned = models.BooleanField(default=False)

    # Use email as login field
    USERNAME_FIELD = "email"
    REQUIRED_FIELDS = ["username"]

JWT Authentication

I used dj-rest-auth with Simple-JWT. The setup is straightforward but the token refresh flow took some work to get right.

# settings.py
SIMPLE_JWT = {
    "ACCESS_TOKEN_LIFETIME": timedelta(hours=1),
    "REFRESH_TOKEN_LIFETIME": timedelta(days=7),
    "ROTATE_REFRESH_TOKENS": True,
}

On the frontend, I added an Axios interceptor that automatically refreshes the token on 401 responses:

api.interceptors.response.use(
    (response) => response,
    async (error) => {
        if (error.response?.status == 401) {
            // Refresh token and retry
            const refresh = localStorage.getItem("refresh_token");
            const res = await axios.post("/api/auth/token/refresh/",
              { refresh }
            );
            localStorage.setItem("access_token", res.data.access);
            error.config.headers.Authorization = 
              `Bearer ${res.data.access}`;
            return api(error.config);
        }
        return Promise.reject(error);
    }
);

Slug-Based URLs

Posts use slugs instead of IDs for better URLs.
Auto-generated from the title on save:

class Post(models.Model):
    title = models.CharField(max_length=300)
    slug = models.SlugField(unique=True, blank=True)

    def save(self, *args, **kwargs):
        if not self.slug:
            base = slugify(self.title)
            slug = base
            n = 1
            while Post.objects.filter(slug=slug).exists():
                slug = f"{base}-{n}"
                n += 1
            self.slug = slug
        super().save(*args, **kwargs)

The Badge System

Badges auto-award when a user crosses reputation milestones. The key was overriding save() on the User model so it works regardless of how reputation is updated - even through Django admin:

def save(self, *args, **kwargs):
    if self.pk:
        try:
            old = User.objects.get(pk=pk)
            rep_changed = old.reputation != self.reputation
        except User.DoesNotExist:
            rep_changed = False
    else:
        rep_changed = False

    super().save(*args, **kwargs)

    if rep_changed:
        self._check_reputation_badges()

def _check_reputation_badge(self):
    milestones = {
        100: "rising_star",
        500: "contributor",
        1000: "expert",
        5000: "legend",
    }
    for threshold, slug in milestones.items():
        if self.reputation >= threshold:
            badge = Badge.objects.get(slug=slug)
            UserBadge.objects.get_or_create(
                user=self, badge=badge
            )

React — Interesting Challenges

The Edited Badge Problem

Django sets created_at and updated_at in two separate operations —they're never exactly equal even on first save. Difference is ~0.5ms.

My first check updated_at !== created_at was always true, so everything showed "edited".

Fix: Use 1 second tolerance:

{comment.updated_at && comment.created_at &&
  (new Date(comment.updated_at).getTime() - 
   new Date(comment.created_at).getTime()) > 1000 && (
  <span className="text-xs italic text-muted">edited</span>
)}

Load More Pagination

Django's paginated response returns next as an absolute URL like http://localhost:8000/api/posts/?page=2.

When I passed this to Axios, it double-prepended the base URL and got a 404.

Fix: Strip the origin before passing to Axios:

function relPath(url: string): string {
  try {
    const u = new URL(url);
    return u.pathname + u.search;
    // Returns: /api/posts/?page=2
  } catch {
    return url;
  }
}

// Usage
const res = await api.get(relPath(nextUrl));

TipTap Image Alignment

TipTap's default Image extension doesn't support alignment. I built a custom FigureImage node that wraps <img> in <figure> with alignment controlled by CSS margins:

// Center: margin: 0 auto
// Left:   margin-right: auto  
// Right:  margin-left: auto

Text-align on a block element doesn't work for images — margin-based alignment does.

Deployment — Things That Went Wrong

1. Gunicorn 203/EXEC Error

My first production deploy failed with status=203/EXEC. The unix socket path didn't exist. Fix: switched to TCP binding:

ExecStart=... gunicorn --bind 127.0.0.1:8000 ...

2. InconsistentMigrationHistory

Adding django.contrib.sites to INSTALLED_APPS after socialaccount was already migrated caused this error. Fix:

python manage.py migrate sites --fake-initial
python manage.py migrate

3. Mixed Content (HTTPS → HTTP)

Netlify frontend (HTTPS) calling Linode API (HTTP) gets blocked by browsers. Already covered above — Netlify proxy via _redirects solves it.

4. Email Confirmation Template Error

allauth tried to render an email confirmation template that didn't exist. For now:

ACCOUNT_EMAIL_VERIFICATION = "none"

Will add proper email confirmation later.

What I Would Do Differently

1. Plan the data models first

I added fields to models multiple times after the fact. Spending an extra hour designing models upfront saves days of migrations.

2. Use environment variables from day one

I hardcoded some values early and had to hunt them down later. Always use .env from the first commit.

3. Write API docs as you go

Documenting endpoints after the fact is painful. I should have maintained a simple list as I built.

4. Test on mobile early

The UI looked great on desktop but needed work on mobile. Test on real devices early and often.

The Numbers

Lines of code:  ~8,000
Time to build:  ~3 months (evenings + weekends)
Server cost:    $5/month (Linode)
Domain cost:    $0 (using free Netlify subdomain)
Total spent:    $15 so far

What's Next

Password reset via email
HTTPS on the backend server
OAuth (Google + GitHub login)
Email notifications
Mobile app (maybe)

Source Code Available

If you want to build something similar or just learn from the code — I've made the complete source code available:

🔗 https://samwit.gumroad.com/l/askloop-app

Includes:

Complete Django backend
Complete React frontend
Production deployment guide
Full API documentation

Try It Live

https://askloop-here.netlify.app

Create an account, write a post, ask a question. The community is just getting started — you'd be one of the first members.

Final Thoughts

Building AskLoop taught me more than any tutorial ever could.

Every bug was a real problem to solve.
Every feature was a real decision to make.
Every deployment error was a real lesson learned.

If you're thinking about building something — stop thinking and start building.

The first version will be ugly. Ship it anyway.

Questions? Drop them in the comments below — I read and respond to every one.

Follow me for more build-in-public content.

Part 3: Understanding Databases and Creating Your First User System

Samwit Adhikary — Wed, 10 Dec 2025 16:26:29 +0000

This is Part 3 of the series "Learn Backend Development by Building a Social Media App.

Welcome to Part 3.
So far you've understood what a backend is, created your first Django project, and seen your server run for the very first time. Now we move into one of the most important ideas in backend development: data.

Everything in a social media app revolves around data. Users are data. Posts are data. Comments, likes, stories, notification, all data. You're going to learn how that data is stored, how Django interacts with it, and how we begin shaping something as fundamental as a user account.

Today's chapter is long because this is the foundation of everything else. We're going to go step by step in a slow, friendly manner, and by the end, you'll truly understand what happens inside the backend whenever someone creates an account.

Before We Code: What Exactly Is a Database?

A database is simply a place where your backend stores information. Think of it like a very organized notebook. Every time someone registers, a fresh entry is added to the notebook. Every time someone posts a picture, the notebook receives another entry. Every like, every comment, every follow, everything goes into this book.

The difference between a real notebook and a database is that the database can handle millions of entries without getting tired.

Your app might have thousands of users and thousands of posts. A database is where all of that lives, safely and permanently.

Django communicates with the database for you. You don't write SQL. Django does the hard work.

Understanding Models in Django

If a database is like a notebook full of organized information, then a model is the template for how a particular kind of information should look.

For example, if you're designing a user, you need to tell your backend what information a user should contain. Maybe a username, an email, a password, a profile picture, a date they joined, and so on. A model is how you describe that structure.

A simple way to think of it:

Model = Blueprint
Database Table = Building made using that blueprint
Database Row = One specific user built using that blueprint

You write the blueprint once in your Django code. Django creates the building (the table). Every time someone registers, Django adds a row to that table.

Django's Built-In User Model (And Why We Don't Use It)

Django comes with a built-in User model. It already includes username, password, email, and several other properties.

But modern apps need more control. Social media especially needs:

email login
custom fields
profile extension
OTP verification
unique behaviors

Because of this, many real projects don't use Django's default User. They create a custom user model.

Creating it early is important because changing it later becomes very complicated. So in this part, we'll build a custom user model from the ground up.

Creating Your First Django App

Inside your project folder, run:

python manage.py startapp accounts

This creates a new app called accounts. This app will contain:

the custom user model
registration logic
login logic
verification features later

Your folder structure now looks like this:

core/
accounts/
manage.py

The accounts folder will soon become the home of your entire authentication system.

Designing the Custom User Model

Let's open accounts/models.py. Delete everything inside it and write this:

from django.contrib.auth.models import AbstractUser
from django.db import models

class User(AbstractUser):
    email = models.EmailField(unique=True)

    USERNAME_FIELD = 'email'
    REQUIRED_FIELDS = ['username']

    def __str__(self):
        return self.email

Now let's understand what just happend, slowly.
We're telling Django that:

Our User is based on Django's built-in AbstractUser (so we still inherit many useful features like password handling).
The default username is replaced with an email.
Emails must be unique.
When Django prints a user, it should show the email, not some random ID.

This gives us full control. Later parts of the series will add more fields like verification status, OTP codes, timestamps, and more.

Adding the Accounts App to Installed Apps (Important Step)

You just created a new Django app called accounts, but Django doesn't automatically know about it. You must tell Django to load it.

Open core/settings.py and find INSTALLED_APPS. Add "accounts" there like this:

INSTALLED APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',

    'accounts',  # <-- Add here
]

Without this step, Django won't pick up your custom models at all, which would cause errors later.

Connecting the Custom User Model to Django

Django won't magically use you new user model unless you tell it to. So open core/settings.py and add this line at the bottom:

AUTH_USER_MODEL = 'accounts.User'

This line is extremely important. It says, "Hey Django, use this new User model instead of the old one".

Understanding Migrations (Very Important Concept)

You created a model. But right now, the database knows nothing about it.
A migration is like giving the database instructions about your blueprint. It's Django telling the database, "Please create a table for this model".

We run two commands:

python manage.py makemigrations
python manage.py migrate

The first command reads your model and prepares instructions. The second command applies those instructions to the actual database.

After running these commands, your User table now exists inside your database.

You haven't created any users yet, but the table is ready to hold them. Here's a simple diagram of what happened:

This is a process you'll repeat throughout this entire series.

Creating Your First User (Using the Admin System)

Django has a built-in admin panel that lets you interact with your data. But before we can us it, we need to create an admin user.

Run:

python manage.py createsuperuser

It will ask for an email , a username, and a password. Once done, start your server:

python manage.py runserver

Then visit:

http://127.0.0.1:8000/admin

You will see a login page. Enter your credentials, and you'll step into Django's administrator dashboard.

This dashboard will eventually show your posts, comments, users, stories, everything. Right now, it's empty, but that's perfect. It means we're ready to start filling it by building the actual registration and login system.

Where We Are Now

At this moment, your backend has:

a working Django server
a custom user model
a connected database
Django admin access
your first superuser account

You've taken the first real step towards building your social media backend.

What's Coming in Part 4

In the next part, we begin turning this data into something users can actually interact with. You'll learn:

what JWT is
how login really works
how sessions differ from token authentication
how to implement registration using real API endpoints
how to implement login
how to secure protected routes

This is where your backend starts becoming a real API.

Till then, Happy Coding!!

Part 2: Setting Up Your First Django Project

Samwit Adhikary — Tue, 09 Dec 2025 18:55:03 +0000

This is Part 2 of the series "Learn Backend Development by Building a Social Media App.

Welcome back.
In the previous part, you learned what a backend really is and how it quietly powers almost everything inside a modern app. Now it's time to take the first real step: creating your backend project on your own computer.

Before we start typing commands, let's go slowly. I want you to understand what each tool is, why we are installing it, and what your computer is actually doing. Many beginners jump straight into commands without knowing what's happening, and that usually leads to confusion later. We won't do that here. You'll know exactly what's going on.

By the end of this chapter, you'll have a running Django project on your machine. Seeing that browser window open for the first time with your backend responding, that's when the journey becomes real.

Let's begin.

Understanding the Tools We're About to Install

Before we install anything, you should know what role each piece plays.

Python

Python is the language Django runs on. Think of Python as the base ingredient in a recipe. Without it, nothing works.

Django

Django is the framework that helps you create websites and backends quickly. It gives structure, tools, and a lot of built-in features.

Django REST Framework (DRF)

This is the addon for Django. It helps you build APIs so your app (Android, iOS, Web) can talk to your backend easily.

We won't install DRF today. We'll start with Django first so you understand its basics, then add DRF in the next parts.

What Happens When You Install Django?

When you install Django, your computer is basically getting a toolbox filled with:

tools to talk to databases
tools to manage users
tools to build URLs
tools to create models
tools to render data
tools to validate information
tools to structure your entire project

Django is like a well-organized kitchen. Everything has a piece, everything has a purpose, and nothing is random.

Step 1: Install Python

If you already have Python 3.10 or above, you're good. If not, download it from here.

While installing on Windows, make sure you check the box that says:

Add Python to PATH

Otherwise your computer won't know Python exists.

After installation, you can test by opening the terminal (Command Prompt, PowerShell, or Mac/Linux Terminal) and typing:

python --version

If it prints something like Python 3.10 or Python 3.11, you're ready.

Step 2: Create a Project Folder

Choose a place where you want your backend project to live and create a folder. Name it something simple:

social_media_backend

Then open this folder in VS Code or your preferred editor.

Step 3: Create a Virtual Environment

This is something many beginners don't understand at first, so let's go slow. A virtual environment is like a small, private Python world inside your computer. Only this project will use it. Other projects won't interfere. It keeps your backend clean and avoid dependency problems.

Here's the command to create it:

python -m venv venv

This creates a folder called venv that holds your environment.

To activate it:

On Windows

venv\Scripts\activate

On macOS/Linux:

source venv/bin/activate

Once activated, you'll see (venv) appear in your terminal. That means your project is now living in its own safe little world.

Step 4: Install Django

With the virtual environment activate, install Django:

pip install django

Your computer will download Django and set up all its tools. To confirm it installed correctly, type:

django-admin --version

If it shows a version number, everything worked.

Step 5: Create Your Django Project

Now the fun part begins. We're going to create the base structure of your backend.
Inside your project folder, type:

django-admin startproject core .

Let's break this down so you understand:

django-admin is the Django command tool
startproject tells Django to create a new project
core is the name of the project folder Django will create inside your directory
the dot . means "create it here, not in another folder"

When you run this command, Django generates several files.

Here's how your project now looks:

social_media_backend/
│
├── core/
│    ├── __init.py__
│    ├── settings.py
│    ├── urls.py
│    ├── asgi.py
│    └── wsgi.py
│
└── manage.py

If this looks confusing, don't worry. We're going to understand every part of this folder structure.

Understanding the Django Project Structure

Let's go through the important files slowly:

manage.py
Think of this as your project's remote control. You'll use it to:

start the server
apply database migrations
create apps
run commands

It's the file you'll run the most.

settings.py
This file controls everything Django does: database settings, installed apps, security, authentication, etc. You'll come back to this file many times as your backend grows.

urls.py
This is where you tell Django, "When someone visits this URL, run this code."

asgi.py and wsgi.py
These connect your project to web servers. We don't need to touch them yet, but they become important when deploying.

Step 6: Run Your Backend for the First Time

Now type:

python manage.py runserver

Your terminal will show something like:

Starting development server at http://127.0.0.1:8000/

Now open your browser and visit:

http://127.0.0.1:8000/

You should see the Django welcome page.

This is a big moment. It means your backend is alive.
Your journey as a backend developer has officially begun.

A Simple Diagram: Your Project Right Now

Here's a visual way to understand what you just created:

Everything you will build later, login, posts, notifications, stories, will start from this simple running server.

What's Next in Part 3

Now that your project is created and running, the next step is understanding users. In Part 3, we'll take our first step towards real backend functionality:

how databases work
what models are
how Django stores data
how to design a custom user
how to register a user

It will be your first real interaction with the database.

Till then happy coding!!

Part 1: What a Backend Really Is (A Gentle Introduction)

Samwit Adhikary — Mon, 08 Dec 2025 19:13:25 +0000

This is Part 1 of the series "Learn Backend Development by Building a Social Media App.

Understanding the World Behind an App

Before we start coding, I want you to picture something very simple.
Imagine opening an app like Instagram. You scroll through posts, you leave a like, you comment on something funny, and you get a notification when someone follows you. All of this feels instant and smooth, almost magical.

But here's the truth: your phone doesn't actually "know" anything. It doesn't store everyone's posts. It doesn't remember every comment. It doesn't send notifications by itself.

Something else is doing all that work for every user around the world. That hidden system is called the backend. Understanding this is the first step towards becoming a backend developer.

Thinking of the Backend Like a Restaurant Kitchen

A backend is easiest to understand when you think of a restaurant.

Imagine you're sitting at a table with a menu. That menu is like the app you see on your phone. You tap buttons just like you point at items on a menu.

The waiter who takes your order is the API. He carries your request from the table to the kitchen.

The kitchen is the backend. You never see it, but that's where the action happens.

If you ask for food, the waiter tells the kitchen what you want. If you like a post, your app tells the backend which post you liked.

In both cases, the kitchen prepares something and sends it back through the waiter.

That's the basic idea behind every app today.

How Your App Talks to the Backend

Whenever you do something like "open my feed", your app sends a message to a server. The message might simply say, "Please send all posts from today."

The server reads it, looks into its database, collects the posts, and send them back. To keep things organized, all communication follows rules. These rules are called APIs.

An API isn't complicated. It's basically a polite way for your app to say:

"Here's what I want. Here's who I am. Can you give me the right data?"

The server replies with a structured data your app can understand. And just like that, your feed refreshes.

Why Backend Exists in the First Place

If you're building a real social media app, you quickly discover that the backend is the heart of everything.

Your phone cannot store the world's posts. Your friend's phone cannot store everyone's comments. Your laptop cannot decide who should receive a notification.

You need one central brain, a backend that:

stores all the data safely
decides what each user should see
verifies passwords securely
prevents one user from deleting another user's posts
sends notifications in real time

Without a backend, your app is just a collection of buttons that don't actually do anything.

Why We Build With Django

There are many backend frameworks out there, but Django is one of the best for beginners because it takes care of a lot of complicated things for you.

Imagine if you had to personally write code to manage users, handle passwords, connect to a database, check data, validate inputs, and secure everything.
It would be overwhelming.

Django puts all the basic building blocks in place, so you focus on understanding concepts instead of fighting with the foundation.

Then, to create APIs, we add Django REST Framework, usually called DRF. It makes sending and receiving data simple. Think of Django as the house and DRF as the furniture that makes it usable.

What Our Final Social Media Backend Will Look Like

We're not building a small demo. We are building something that resembles a real backend like the ones used in production apps.

Your backend will eventually support:

Account creation
Login with JWT
Email verification
User profiles
Uploads for images and videos
Comments
Likes
Stories
Follows and unfollows
Notifications
Real-time updates
Group features
Exporting your entire user data
And a proper deployment setup

This might sound like a lot right now, but we'll move slowly so that every piece makes sense before we add the next one.

The Tools We Will Use Throughout This Journey

Since this is a full project, we will use tools that real developers use.

Django will be the main framework.
DRF will help us build APIs.
PostgreSQL will store your data safely.
Redis will make instant notification possible.
Django Channels will let the server talk to user in real time.
S3 will store images and videos.
Docker will help us run everything cleanly in production.

You don't need to worry about these now. Each one will be introduced in the moment it becomes relevant, so you never feel lost.

How Everything Works Together

Here's a simple flowchart that shows how the final system works. Don't worry about understanding everything yet - this is just a picture of the destination.

Once you understand this flow, you'll understand how real social media apps operate behind the scenes.

What You'll Gain From This Series

By the time you finish all the parts, you will not only know how to build a backend, you'll understand the thinking behind backend development. You'll know why certain tools exist and where they fit. You'll know how apps actually communicate with servers. You'll know how data flows through systems.

Most importantly, you'll gain the confidence to build apps of your own, without relying on tutorials.

What's Coming Next in Part 2

In the next part, we will finally start coding. You'll install Python, install Django, set up your project, and run your first backend server.

This is where your learning becomes real. You'll see something working on your screen because of code you wrote.