Forem: Bharath Kumar_30

From Docker Failure to PostgreSQL Success: My Real Backend Learning Experience

Bharath Kumar_30 — Wed, 01 Apr 2026 15:58:35 +0000

Hey everyone,

This is a continuation of my journey.

After struggling with PostgreSQL integration, I decided to try something new:

Docker

I thought it would make things easier.

But again… reality had other plans

Trying Docker

I installed Docker Desktop and started setup.

At first, everything looked fine.

But then…

Issues Started

I faced multiple problems:

Disk space errors
WSL not working
Installation failures
“Catastrophic failure” errors

It was frustrating.

I spent time fixing:

Environment variables
WSL updates
System settings

Still, it didn’t work smoothly.

Reality Check

At that moment, I realized:

I’m still learning
I need a simpler path

So I made a decision.

Switching Back to Local Setup

Instead of forcing Docker, I went back to:

Local PostgreSQL setup

This time, I focused step by step:

Installed PostgreSQL properly
Opened pgAdmin
Created database
Ran my schema

Finally… Success!

Then came the best moment:

Tables created successfully
Database working
Connection from Python working

Everything finally clicked

What I Learned

Tools are important, but timing matters
Docker is powerful, but not always beginner-friendly
Simplicity wins when learning

My Growth

Today I:

Understood PostgreSQL deeply
Integrated it into my project
Learned from real errors
Built confidence

Final Thought

It’s okay to fail.
It’s okay to change direction.
What matters is moving forward.

Today, I didn’t just build a feature.
I built experience.

And that’s what truly matters

From SQLite to PostgreSQL: My First Integration Attempt (Failures, Learning & Direction Change)

Bharath Kumar_30 — Wed, 01 Apr 2026 15:55:39 +0000

Hey everyone,

Today was one of those days where I didn’t just code… I struggled, failed, learned, and improved.

I started with a clear goal:

Replace SQLite with PostgreSQL
Store all my project data in a real database

Sounds simple right?
But the journey had some twists.

My Initial Plan

My project was using SQLite. It was easy, but not scalable.

So I decided:

Remove SQLite completely
Integrate PostgreSQL
Use .env for security
Store everything in database

Step 1: Database Setup

I installed PostgreSQL and opened pgAdmin.

Then I:

Created a database → social_media_db
Designed tables using DDL
Ran SQL successfully

That moment felt good — my database was ready.

Step 2: Integration Attempt

Next, I started integrating it into my code.

Removed sqlite3
Added psycopg2
Created a db.py connection file
Updated queries (? → %s)

Problems I Faced

This is where things got real.

Connection errors
Query syntax mistakes
Forgot commit()
Small bugs everywhere

At first, I thought:

“Why is this so hard?”

But slowly I understood…

What I Learned

SQLite and PostgreSQL are NOT the same
Small syntax changes matter
Database connection must be handled properly
Errors are part of learning

Change in Thinking

At one point, I felt:

“Maybe I should try a better setup…”

That’s when I started thinking about Docker.

Because:

It gives clean environment
Easy to manage services
Industry-level approach

My Realization

Today I understood something important:

Learning backend is not just coding…
It’s about understanding systems.

My Takeaway

I successfully designed and created my PostgreSQL database
I started integrating it into my project
I faced real-world problems
And I didn’t give up

Final Thought

Today was not perfect.
But it was real.

Failures taught me more than success.

And tomorrow… I come back stronger

# Setting Up PostgreSQL Locally and Connecting It to My Project (Beginner Journey)

Bharath Kumar_30 — Wed, 25 Mar 2026 17:44:50 +0000

Hey everyone,

Today I worked on something very important in backend development — setting up a database and connecting it to my project.

Until now, I was mainly focused on coding features. But today I understood that without a proper database setup, a project is not complete.

So I decided to set up PostgreSQL locally and integrate it step by step.

What I focused on today

My main goal was to:

Set up PostgreSQL locally
Create a database
Configure environment variables
Connect database using Python
Execute my database schema

Step 1: Creating the database

After installing PostgreSQL, I created a database for my project:

```sql id="y2y3g1"
CREATE DATABASE social_media_db;




This is where all my project data will be stored.

---

##  Step 2: Managing credentials using .env

Instead of writing database credentials directly in code, I used a `.env` file.



```env id="3hkgmq"
DB_HOST=localhost
DB_PORT=5432
DB_NAME=social_media_db
DB_USER=postgres
DB_PASSWORD=your_password

This made my setup cleaner and more secure.

Step 3: Connecting PostgreSQL with Python

To connect my project with the database, I used psycopg2.

```python id="s6x3jm"
import os
import psycopg2
from dotenv import load_dotenv

load_dotenv()

conn = psycopg2.connect(
host=os.getenv("DB_HOST"),
port=os.getenv("DB_PORT"),
dbname=os.getenv("DB_NAME"),
user=os.getenv("DB_USER"),
password=os.getenv("DB_PASSWORD")
)

print("Database connected successfully!")




Seeing this connection work was a great moment.

---

##  Step 4: Executing my database design

Earlier, I had designed my database structure using DDL.

Today, I executed that design in PostgreSQL.

My schema includes:

* Users table
* Platforms table
* Credentials table
* Posts table
* Post logs table

Now my design is no longer just an idea — it’s a working database.

---

##  Step 5: Updating from SQLite to PostgreSQL

My project was previously using SQLite.

So I started adapting it to PostgreSQL.

I learned small but important differences:

* `AUTOINCREMENT` → `SERIAL`
* `DATETIME` → `TIMESTAMP`

These changes helped me understand how different databases work.

---

##  What I learned today

Today was not about writing a lot of code.

It was about understanding how things actually work behind the scenes.

I learned that:

* Database setup is a core part of backend development
* Environment variables are important for security
* Designing and executing a schema are two different steps
* Migrating between databases requires attention to detail

---

##  My takeaway

I feel more confident now working with databases.

Instead of just using default setups, I now understand how to:

* Create and manage databases
* Connect them to applications
* Structure data properly

---

##  Final thought

Every day I’m learning something new.

Some days it’s coding,
Some days it’s understanding systems.

Both are equally important.

This is just one more step in my journey — more learning ahead 🚀

Designing My First Real Database Schema with DDL (PostgreSQL)

Bharath Kumar_30 — Wed, 25 Mar 2026 06:12:06 +0000

Hey everyone,

Today was a different kind of learning day for me.

Instead of writing APIs or working on frontend, I focused on something very important in backend development — database design using DDL commands.

At first, I thought database means just creating tables. But today I understood that it’s much more than that.

What I worked on today

My guide asked me to:

Design the database structure
Write DDL commands (CREATE TABLE)
Apply constraints (for data integrity)
Think about optimization

So I didn’t just create tables — I designed a proper structure for my project.

What is DDL?

DDL stands for Data Definition Language

It is used to define the structure of the database.

Some common commands:

CREATE TABLE
ALTER TABLE
DROP TABLE

Today, I mainly worked with CREATE TABLE.

My Database Design (Project Based)

My project is about social media automation, so I designed tables based on real use cases.

Users Table

Stores user details like username, email, and password.

Important:

Email is unique
Password is stored securely

Platforms Table

Instead of hardcoding platforms like Telegram or Twitter, I created a separate table.

Benefit:

Easy to add new platforms later
No need to change code

Credentials Table

This table connects users and platforms.

Key points:

Stores API keys (in encrypted format)
Prevents duplicate connections using UNIQUE constraint
Uses ON DELETE CASCADE

Posts Table

Stores content that users want to post.

Includes:

Content
Status (pending, sent, failed)

Post Logs Table

This was a very important part.

One post can go to multiple platforms
Each platform result is stored separately

Example:

Telegram → Success
Twitter → Failed

So logs help track everything clearly.

Data Integrity (Important Learning)

Today I understood that just creating tables is not enough.

We must protect the data.

I used:

PRIMARY KEY → unique identification
FOREIGN KEY → relationships
UNIQUE → no duplicates
NOT NULL → required fields
CHECK → restrict valid values
ON DELETE CASCADE → automatic cleanup

Optimization (Small but powerful)

I also added indexes.

Why?

Because:

Faster queries
Better performance

What I realized today

Earlier, I used to think:

“Database = just store data”

Now I understand:

“Database design = foundation of the entire application”

If the structure is wrong, everything becomes difficult later.

My takeaway

Think before creating tables
Design based on real use cases
Always include constraints
Plan for scalability
Keep it clean and structured

Final thought

Today I didn’t just write SQL.

I learned how to think like a backend developer.

Still learning, still improving — one step at a time.

More updates coming soon

I Reached the Final Round… But Didn’t Get Selected (And That’s Okay)

Bharath Kumar_30 — Mon, 23 Mar 2026 16:14:13 +0000

Hey everyone,

Today I wanted to share something real from my journey.

Not a success story.
Not a “I got placed” post.

But something that actually matters more.

💬 What happened?

I attended an interview process that went on for around 10 days.

It was not easy at all. There were more than 450+ candidates.

Round by round, people were getting filtered out.

And somehow… I kept moving forward.

Cleared aptitude
Cleared coding
Cleared mock interview
Cleared technical round

Finally…

👉 I reached the last round

👉 Top 5 candidates

Honestly, that moment itself felt like a win.

😶 But here’s the truth

I didn’t get selected in the final HR round.

Yeah… that hurt.

After coming so far, losing in the last step is not easy to accept.

But at the same time, I didn’t feel like I failed.

Because I know how far I came.

🧠 What I realized

Till now, I always focused on:

Learning AI tools
Practicing prompt engineering
Understanding LLMs
Building projects

I’m still new, but I’ve been learning consistently.

And those things helped me clear all the technical rounds.

But the final round showed me something different.

Being good technically is not enough.

🧩 The missing piece

The HR round was not about coding.

It was about:

How you speak
How you present yourself
How clearly you think
How confidently you answer

And I understood…

👉 I need to improve there.

💡 One thing I learned deeply

In this field, especially in corporate life:

You have to keep updating yourself every single day.

Not just in coding.

But in:

Communication
Thinking
Confidence
Real-world understanding

🔥 My biggest takeaway

From 450+ people to Top 5.

That itself tells me something:

👉 I am on the right path.

I didn’t lose.

I just found what I need to improve next.

💪 What I’m going to do next

Work on communication skills
Practice more real interview scenarios
Keep building projects
Keep learning AI and LLM deeply
Come back stronger

🤝 To anyone reading this

If you are also preparing for interviews…

Listen carefully:

Rejection is normal
Pressure is normal
Self-doubt is normal

But stopping is not.

🌱 Final thought

Sometimes you won’t get what you worked for.

But you will get what you learned from it.

And that matters more.

This is just one step in my journey.

I’ll keep learning.
I’ll keep improving.
I’ll keep showing up.

One day… I’ll write a “selected” post too.

Until then — we move forward 🚀

My Learning Journey: Factory Pattern, Encryption (AES), and PostgreSQL Database Design

Bharath Kumar_30 — Mon, 23 Mar 2026 15:44:05 +0000

Today was a really productive day in my project journey. I focused on understanding some important backend concepts that are actually used in real-world applications. I worked on three main areas:

Factory Pattern (Design Pattern)
Encryption (AES vs Hashing)
PostgreSQL Database Design (DDL + Structure)

I’ll explain everything in a simple and practical way based on what I learned.

🧠 1. Understanding Factory Pattern

At first, I was confused about why we need a factory when we already have routers. But now it’s clear.

What is Factory?

Factory is just a helper function that creates the correct object based on input.

Instead of writing multiple if-else conditions everywhere, we centralize object creation in one place.

My Use Case

In my project, I support multiple platforms like:

Telegram
Twitter
Instagram
Reddit

Each platform has its own service class.

Instead of doing this:

if platform == "telegram":
    service = TelegramService()
elif platform == "twitter":
    service = TwitterService()

I used a factory:

def get_service(platform_name, credentials):
    REGISTRY = {
        "telegram": TelegramService,
        "twitter": TwitterService,
        "instagram": InstagramService,
    }

    service_class = REGISTRY.get(platform_name.lower())
    return service_class(credentials) if service_class else None

Why this is better?

Cleaner code
Easy to maintain
Easy to add new platforms
No repeated logic

Final understanding

Factory = dynamically create the correct service object based on platform

🔐 2. Encryption vs Hashing (AES Explained)

This was another important concept I learned today.

Hashing

One-way process
Cannot reverse
Used for passwords

Example:

password -> hashed value

We never get the original password back.

Encryption (AES)

Two-way process
Can encrypt and decrypt
Used for sensitive data like API keys

Why I used AES?

In my project, I store credentials like tokens and API keys.

These values need to be used later, so I cannot use hashing.

That’s why I used encryption.

What is AES?

AES is a symmetric encryption algorithm.

That means:

Same key is used for:

Encryption
Decryption

Simple Flow

Original Data -> Encrypt using key -> Encrypted Data
Encrypted Data -> Decrypt using same key -> Original Data

Key Point

If the key is lost, data cannot be recovered.

🗄️ 3. PostgreSQL Database Design

Today I also designed my database using PostgreSQL.

What is DDL?

DDL stands for Data Definition Language.

It is used to define database structure.

Examples:

CREATE TABLE
ALTER TABLE
DROP TABLE

My Database Structure

I designed a clean and scalable structure with multiple tables.

1. Users Table

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    username VARCHAR(100),
    email VARCHAR(150) UNIQUE,
    password TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Stores user data
Password is hashed
Email is unique

2. Platforms Table

CREATE TABLE platforms (
    id SERIAL PRIMARY KEY,
    name VARCHAR(50) UNIQUE
);

Stores platform names
Easy to scale (add new platform without changing code)

3. User Credentials Table

CREATE TABLE user_platform_keys (
    id SERIAL PRIMARY KEY,
    user_id INT REFERENCES users(id) ON DELETE CASCADE,
    platform_id INT REFERENCES platforms(id),
    encrypted_data TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    UNIQUE(user_id, platform_id)
);

Stores API keys (encrypted)
Prevents duplicate platform connection
Deletes data if user is deleted

4. Posts Table

CREATE TABLE posts (
    id SERIAL PRIMARY KEY,
    user_id INT REFERENCES users(id),
    content TEXT,
    status VARCHAR(20) CHECK (status IN ('pending', 'processing', 'sent', 'failed', 'partial')),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Stores user posts
Status is controlled using CHECK constraint

5. Post Logs Table

CREATE TABLE post_logs (
    id SERIAL PRIMARY KEY,
    post_id INT REFERENCES posts(id) ON DELETE CASCADE,
    platform_id INT REFERENCES platforms(id),
    status VARCHAR(20),
    error_message TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Why separate logs?

One post can be sent to multiple platforms.

Example:

Telegram -> Success
Twitter -> Failed

So logs are stored separately to track each platform result clearly.

🎯 Final Thoughts

Today I understood how real backend systems are designed.

Factory pattern helps in clean and scalable architecture
AES encryption helps in securing sensitive data
PostgreSQL schema design helps in structured and reliable data storage

This learning helped me move from basic coding to thinking like a backend developer.

📌 Key Takeaways

Don’t mix logic in router — use factory
Use hashing for passwords, encryption for reusable secrets
Always design database with scalability and constraints
Separate logs for better tracking and debugging

This was a great learning day for me. More improvements coming soon.

Fixing My Git Mistakes and Finally Understanding My Router Code

Bharath Kumar_30 — Fri, 20 Mar 2026 16:25:02 +0000

Today was one of those days where I didn’t just write code — I actually fixed my mistakes and understood what I built.

Cleaning Up My Git Mistakes

I realized I had made some serious beginner mistakes:

I committed my .env file (which contains secrets)
I pushed my database file to GitHub
I didn’t have a .gitignore

After guidance, I fixed everything properly:

Removed .env and .db from the repository
Created a .gitignore to avoid future mistakes
Added .env.example to show required environment variables without exposing secrets

This made me understand something important:

A clean and secure repository is as important as working code.

Understanding My Router Code

Earlier, my router files were just “working code” for me.

Today I actually understood what they do.

What is a Router?

In FastAPI, routers handle API requests.

Example:

@router.post("/login")
def login():
    return {"message": "User logged in"}

Now I understand:

Router = entry point for requests
It connects frontend requests to backend logic
It calls services and database operations

Real Flow in My Project

Frontend → Router → Service → Database

User clicks something on UI
Router receives request
Service handles logic
Database stores/retrieves data

What Changed Today

Before:

Code was running, but I didn’t fully understand it

Now:

I know how requests flow
I understand how routers connect everything

Key Learning

Never commit sensitive files like .env
Always use .gitignore
Routers are the backbone of API communication
Understanding your code matters more than just running it

Final Thought

Fixing mistakes taught me more than writing new code.

Every small correction is making me a better developer.

Next Step

Deep dive into services layer
Improve authentication flow
Prepare for technical discussion

If you’re building projects, take time to clean your repo and understand your code. That’s where real growth happens.

I Used AI to Build My Project… But Then I Had to Actually Understand It

Bharath Kumar_30 — Thu, 19 Mar 2026 18:19:49 +0000

When I built my social media automation platform, I used AI tools to generate a lot of the code.

Everything seemed to work — login, dashboard, APIs. But when I looked deeper, I realized something important:

I didn’t fully understand what was happening inside my own project.

So I decided to slow down and learn the core concepts properly: JWT authentication, AES encryption, database design, and debugging.

Here’s what I learned.

Understanding JWT (Authentication)

At first, I thought JWT was just a login token. But it’s more than that.

A typical flow looks like this:

User logs in → password verified → JWT created
→ frontend stores token → sends it in each request
→ backend verifies token → access granted

JWT is essentially structured data that is signed using a secret key.

Example:

from jose import jwt
from datetime import datetime, timedelta

def create_token(email):
    return jwt.encode({
        "sub": email,
        "exp": datetime.utcnow() + timedelta(minutes=60)
    }, SECRET_KEY, algorithm="HS256")

Once I understood this, authentication became much clearer.

Debugging JWT Using jwt.io

One of the most useful tools I used was jwt.io.

I pasted my token into the debugger and could immediately see:

The user email
Expiry time
Algorithm used

When I added my secret key, the tool verified the signature.

This helped me understand that JWT is not encrypted — it is encoded and signed.

AES Encryption for Security

My project allows users to connect platforms like LinkedIn and Telegram. That means handling sensitive data such as API keys and tokens.

Storing these values directly is risky.

To solve this, I used AES encryption (via Fernet):

from cryptography.fernet import Fernet

key = Fernet.generate_key()
f = Fernet(key)

encrypted = f.encrypt(b"api_key")
decrypted = f.decrypt(encrypted)

This ensures that even if the database is exposed, the data remains protected.

Database Design

I chose:

SQLite for simplicity and lightweight storage
SQLAlchemy as the ORM for clean, Python-based database interaction

This allowed me to focus on building features instead of managing database complexity.

Understanding the Project Structure

Initially, the folder structure didn’t make much sense.

Now I see it clearly:

Frontend → Router → Service → Database

Each layer has a specific role:

Frontend handles user interaction
Router handles API endpoints
Service contains business logic
Database stores data

A Critical Bug I Fixed

At one point, I discovered a major issue.

No matter who logged in, my Telegram account was being used.

This meant all users were sharing the same session — a serious security problem.

I fixed it by:

Assigning each user their own credentials
Storing those credentials securely (encrypted)
Removing any global/shared session usage

What I Learned

JWT is signed data used for authentication
AES encryption protects sensitive information
ORM tools simplify database operations
Debugging is essential to truly understand your system

Final Thought

AI can help you build faster, but understanding what you build is what actually makes you a developer.

What’s Next

Implementing refresh tokens
Improving security practices
Deploying the application

If you're building projects with AI, take the time to break things down and understand them. That’s where real learning happens.

From Localhost to Live SaaS: Deploying My FastAPI App with Apache, SSL & JWT Auth

Bharath Kumar_30 — Wed, 18 Mar 2026 18:21:49 +0000

Hey friends 👋

Today I’m sharing my complete real-world deployment journey — from building a FastAPI project to making it live with:

JWT Authentication (Login/Register)
Landing Page + Dashboard UI
FastAPI Backend
Apache Reverse Proxy
HTTPS (SSL with Certbot)
VPS Hosting (Linux)

This is a step-by-step, copy-paste friendly guide — no confusion, just execution

Project Overview

My project includes:

✅ Landing page
✅ User Registration & Login
✅ JWT Authentication
✅ Dashboard (after login)
✅ API-based backend (FastAPI)
✅ Static + Templates (HTML/CSS/JS)

Step 1 — Setup Server

Install Python & pip:

sudo apt update
sudo apt install python3 python3-pip -y

Step 2 — Upload Project

Navigate to your project folder:

cd ~/htdocs/soical-media-automation/automation_platform

Step 3 — Install Dependencies

If you have requirements.txt:

pip3 install -r requirements.txt

If not:

pip3 install fastapi uvicorn python-dotenv

Step 4 — Run FastAPI App

nohup python3 -m uvicorn app.main:app --host 0.0.0.0 --port 8000 > uvicorn.log 2>&1 &

Check if running:

ps aux | grep uvicorn

Step 5 — Setup Apache (Reverse Proxy)

Install Apache:

sudo apt install apache2 -y

Enable required modules:

sudo a2enmod proxy
sudo a2enmod proxy_http

Step 6 — Apache Config (Single Clean Config)

Open config:

sudo nano /etc/apache2/sites-available/001-automate.conf

Paste:

<VirtualHost *:80>
    ServerName automated.soicalmedia.selfmade.one
    Redirect / https://automated.soicalmedia.selfmade.one/
</VirtualHost>

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerName automated.soicalmedia.selfmade.one

    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:8000/
    ProxyPassReverse / http://127.0.0.1:8000/

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/automated.soicalmedia.selfmade.one/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/automated.soicalmedia.selfmade.one/privkey.pem

    Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

Step 7 — Clean Apache Sites

Disable default configs:

sudo a2dissite 000-default.conf
sudo a2dissite default-ssl.conf
sudo a2dissite 001-automate-le-ssl.conf

Enable your config:

sudo a2ensite 001-automate.conf
sudo service apache2 restart

Step 8 — Setup SSL (HTTPS)

Install Certbot:

sudo apt install certbot python3-certbot-apache -y

Run:

sudo certbot --apache -d automated.soicalmedia.selfmade.one

Choose:

Email → your email
Agree → Yes
Redirect → Yes (HTTPS)

Step 9 — Create init.sh (Auto Run)

nano ~/init.sh

Paste:

#!/bin/bash

cd /home/mr.potter/htdocs/soical-media-automation/automation_platform

nohup python3 -m uvicorn app.main:app --host 0.0.0.0 --port 8000 > uvicorn.log 2>&1 &

Run:

chmod +x init.sh
./init.sh

Step 10 — JWT Authentication (Concept)

My app includes:

User registration
Login system
JWT token generation
Protected dashboard

Example flow:

from fastapi import Depends
from fastapi.security import OAuth2PasswordBearer

oauth2_scheme = OAuth2PasswordBearer(tokenUrl="login")

@app.get("/dashboard")
def dashboard(token: str = Depends(oauth2_scheme)):
    return {"message": "Welcome to dashboard"}

Frontend Structure

templates/
    index.html
    login.html
    register.html
    dashboard.html

static/
    css/
    js/

Common Issues I Faced (And Fixes)

Too Many Redirects

Cause: Multiple Apache configs
Fix: Use single config only

requirements.txt not found

Wrong folder
Fix: cd into correct directory

Permission denied

Fix:

sudo chown mr.potter:mr.potter filename

systemctl not working

Use:

sudo service apache2 restart

Final Result

✔ Live SaaS App
✔ Secure HTTPS
✔ Login/Register system
✔ Dashboard
✔ API backend

Final Thoughts

This wasn’t just deployment — it was:

DevOps basics
Backend engineering
Real production setup

If you’re building something similar — don’t stop at localhost.
Deploy it. Break it. Fix it. Learn it

Let’s Connect

If you’re building something cool or stuck in deployment, feel free to reach out

Happy coding

Improving My Automation Website: Making API Setup Easier for Users 🚀

Bharath Kumar_30 — Mon, 16 Mar 2026 18:04:47 +0000

When I first started building my social media automation platform, I thought the hardest part would be coding the integrations.

Turns out… the real challenge was something else.

Helping users get the API keys from different social media platforms.

If you've ever tried integrating APIs from platforms like Instagram, Facebook, LinkedIn, or Telegram, you probably know what I'm talking about.

Nothing is straightforward.

So today I worked on improving my website so users don’t have to struggle the way I did.

The Problem I Faced

My platform allows users to automate posts to different social media platforms.

But before automation works, users must connect their accounts by adding API credentials like:

API Key
Client ID
Client Secret
Access Token
Page ID

The issue?

Every social media platform has a completely different process.

Some examples:

Instagram requires converting to a Business Account.
Facebook requires a Meta Developer App.
LinkedIn needs OAuth configuration.
Telegram requires API ID and API Hash.
Twitter requires Developer access approval.

And honestly… the official documentation is not beginner-friendly.

Even I struggled while figuring it out.

So I asked myself a question:

Why should my users go through the same confusion?

My Solution: A Better Instruction System

Instead of just writing a few steps, I redesigned the instruction pages on my website.

Now each platform page includes a two-level instruction system.

1️⃣ Quick Setup Steps

Users first see simple beginner-friendly steps like this:

Step 1
Go to the official developer portal.

Step 2
Create a developer application.

Step 3
Generate API credentials.

Step 4
Copy the API keys.

Step 5
Paste them into my platform.

This helps users quickly understand the overall process.

2️⃣ “Learn More” Detailed Guide

But some users need deeper instructions.

So I added a Learn More section.

When the user clicks Learn More, the page expands and shows detailed instructions including:

Step-by-step walkthrough
Official developer links
Screenshot placeholders
Common mistakes
Troubleshooting tips

This way beginners are not overwhelmed, but advanced users can still see the full guide.

Example: Instagram Integration

Instagram is one of the most confusing platforms to integrate.

To get the API working, users must:

Convert their Instagram account to a Business account
Connect Instagram to a Facebook Page
Create a Meta Developer App
Enable Instagram Graph API
Generate an Access Token

Many people don’t realize this until they try it.

So now my website clearly explains this step-by-step.

Adding Troubleshooting Sections

Another improvement I made was adding Common Errors sections.

Because when working with APIs, something always goes wrong.

Some examples:

Error: App still in development mode
Solution: Switch the app to Live mode in the Meta Developer dashboard.

Error: Missing permissions
Solution: Add the required permissions like pages_manage_posts.

Error: Access token expired
Solution: Generate a long-lived access token.

These small explanations can save users hours of frustration.

Video Tutorials

Some people prefer watching instead of reading.

So each platform page also includes a video tutorial section.

Users can watch the full setup guide if they want visual instructions.

Making the UX More Friendly

Another thing I added is a simple integration progress indicator.

It shows users exactly where they are in the process.

Example:

Step 1 — Get API Key
Step 2 — Add Credentials
Step 3 — Test Connection
Step 4 — Connected ✅

This small feature makes the experience much clearer.

What I Learned From This

Building automation tools is not just about writing backend code.

It's also about making complex systems understandable for users.

A good product doesn’t just work.

It guides users step by step.

Sometimes improving documentation and instructions is just as important as improving the software itself.

What’s Next for My Platform

Now that the instruction system is improved, my next steps are:

Expanding support for more social media platforms
Adding better UI design for the dashboard
Improving automation workflows
Building scheduling features

My goal is to create a platform where users can automate social media posting with just a few clicks.

No confusion. No frustration.

Just automation.

If you’re building developer tools or automation platforms, one thing I learned is this:

Don’t assume users know what you know.

Clear instructions can make or break the entire experience.

And sometimes the best feature you can build…

is simply helping people understand the process.

From Messy Script to Clean OOP: Rewriting a Python Project the Right Way

Bharath Kumar_30 — Wed, 11 Mar 2026 18:16:29 +0000

When we start learning Python, most of us write everything in one file.
Functions, variables, logic — everything mixed together.

It works for small programs. But when the project grows, the code becomes hard to maintain, difficult to debug, and messy to expand.

So today I decided to rewrite my small Python project using Object-Oriented Programming (OOP).

In this blog I’ll show you:

Why OOP is important
How to convert a normal script into OOP
A simple project structure
Copy-paste ready code for beginners

This guide is beginner friendly, so you can follow along easily.

Why Use OOP?

Object-Oriented Programming helps organize code into objects and classes.

Instead of writing everything as separate functions, we group related logic into classes.

Benefits of OOP:

✔ Cleaner code structure
✔ Easy to maintain
✔ Code reusability
✔ Easier debugging
✔ Scalable for large projects

Without OOP, projects become messy very quickly.

Recommended Project Structure

A clean Python project should be structured like this:

project/
│
├── main.py
├── user.py
├── post_manager.py
└── utils.py

Each file has one clear responsibility.

user.py → handles user data
post_manager.py → handles posts
utils.py → helper functions
main.py → program entry point

This is a simple structure but it already looks more professional.

Step 1: Create a User Class

Create a file called user.py

class User:
    def __init__(self, username, email):
        self.username = username
        self.email = email

    def display_user(self):
        print(f"Username: {self.username}")
        print(f"Email: {self.email}")

Explanation:

__init__() is the constructor
self refers to the current object
The class stores user information

Now we have a User object that represents a real user.

Step 2: Create a Post Manager

Now create post_manager.py

class PostManager:
    def __init__(self):
        self.posts = []

    def create_post(self, content):
        self.posts.append(content)
        print("Post created successfully!")

    def show_posts(self):
        print("\nAll Posts:")
        for post in self.posts:
            print(f"- {post}")

This class manages:

Creating posts
Storing posts
Displaying posts

Instead of mixing everything into one script, we keep post logic inside one class.

Step 3: Utility Functions

Now create utils.py

def show_menu():
    print("\nChoose an option:")
    print("1. Create Post")
    print("2. Show Posts")
    print("3. Exit")

Utility files help keep main.py clean.

Step 4: Main Application File

Create main.py

from user import User
from post_manager import PostManager
from utils import show_menu


def main():

    username = input("Enter username: ")
    email = input("Enter email: ")

    user = User(username, email)
    manager = PostManager()

    print("\nUser Details")
    user.display_user()

    while True:

        show_menu()
        choice = input("Select option: ")

        if choice == "1":

            content = input("Enter post content: ")
            manager.create_post(content)

        elif choice == "2":

            manager.show_posts()

        elif choice == "3":

            print("Exiting program...")
            break

        else:

            print("Invalid option")


if __name__ == "__main__":
    main()

This file connects everything together.

How to Run the Project

Open terminal in your project folder and run:

python main.py

Example output:

Enter username: Alex
Enter email: alex@email.com

Choose an option:
1. Create Post
2. Show Posts
3. Exit

Before vs After OOP

Before using OOP:

❌ Everything in one file
❌ Hard to maintain
❌ Difficult to expand

After using OOP:

✔ Clean file structure
✔ Organized code
✔ Easy to extend
✔ Professional design

Final Thoughts

Refactoring a simple script into an Object-Oriented project is one of the best habits a developer can build.

It helps you:

Write cleaner code
Structure projects better
Think like a software engineer

Even if your project is small, organizing it using classes and modules makes it easier to maintain in the future.

Start simple, keep improving your structure, and your Python projects will feel much more professional.

Conclusion

Turning a messy Python script into a clean OOP structure is a powerful upgrade.

With just a few classes and files, your project becomes:

✔ Cleaner
✔ More maintainable
✔ Easier to scale

If you're learning Python, practicing OOP early will help you build better real-world projects.

Happy coding 🚀

Building Static Social Media Connect Pages & Fixing OOP Errors in My Automation Project

Bharath Kumar_30 — Tue, 10 Mar 2026 12:54:39 +0000

Today was one of those “small work but big progress” days in my Social Media Post Automation System project.

Instead of writing more backend logic, I focused on two important things:

Creating static HTML pages for social media connections
Fixing OOP structure issues in my automation code

Simple tasks… but they helped clean up the project architecture a lot.

Why Static HTML Pages?

My system connects with multiple platforms:

LinkedIn
Facebook
Instagram
Telegram

Each platform needs API credentials and setup steps, and during testing I realized something:

Every platform has its own setup process and documentation.

So instead of mixing everything into one messy page, I created separate static HTML pages for each platform.

Now each page shows:

Step-by-step setup instructions
Required API credentials
Input fields for tokens / IDs
A connect button

Basically a mini setup guide inside the project UI.

Example: Instagram Connect Page

For example, the Instagram page explains how to:

Convert the account to Instagram Business
Connect it to a Facebook Page
Create an app in Meta Developers
Enable Instagram Graph API
Generate a Page Access Token
Find the Instagram Business ID

Then users can enter credentials directly in the page.

Simple, clear, and much easier for testing.

Fixing My OOP Structure

Another thing I worked on today was cleaning up my Object Oriented Programming structure.

Earlier my automation scripts were written like separate programs:

One script for Telegram
One for Instagram
One for Facebook
One for LinkedIn

That worked, but it wasn't scalable.

So I started reorganizing everything into service classes.

Example structure:

services/
 ├── linkedin_service.py
 ├── facebook_service.py
 ├── instagram_service.py
 └── telegram_service.py

Each platform now has its own class with functions like:

post()
connect()
validate_credentials()

Then a manager class controls everything.

SocialMediaManager
        |
        ├── LinkedInService
        ├── FacebookService
        ├── InstagramService
        └── TelegramService

Now my automation system can simply call:

manager.post_to_selected_platforms()

Much cleaner.

Debugging the OOP Errors

While converting everything into classes, I hit a few classic beginner problems:

Missing class imports
Async errors with Telegram
Incorrect method calls
Variables not being passed correctly

Nothing dramatic… just the usual “why is this not working?” moments 😅

After fixing those issues, the system finally started running smoothly again.

And honestly, debugging like this teaches more than writing the code itself.

What I Learned Today

A few small but useful lessons:

Separate UI setup pages make integrations easier to manage.
OOP structure helps organize multi-platform automation.
Debugging errors is normal when restructuring code.
Even simple HTML pages can improve project usability.

Sometimes progress isn't about writing hundreds of lines of code.

Sometimes it's just cleaning things up so the system makes sense.

What’s Next?

Next steps for the project:

Integrate all platforms into one posting dashboard
Allow selecting platforms before publishing
Improve UI design
Deploy the automation system

Slowly but surely, the automation platform is coming together.

And yes… still powered by a lot of coffee and debugging sessions. ☕

Thanks for reading!
If you're building automation tools or API integrations, I'd love to hear about your experience too.