DEV Community: Sumeet Dugg

Understanding Programming Languages – Purpose, Evolution, and Use Cases

Sumeet Dugg — Sat, 02 May 2026 07:42:42 +0000

Why They Exist and What Problems They Solve

Programming languages did not appear randomly , they evolved over time as developers faced new types of problems in software development. In the early days, programming was done using low-level languages like machine code and assembly, which were difficult to write and understand. As systems became more complex, new languages were created to simplify development, improve readability, and reduce human effort.

Over the years, different types of programming languages emerged based on specific needs. Some languages like C were designed for system-level control and performance, while others like Java focused on portability across platforms. Later, languages like Python were introduced to improve developer productivity and simplify coding. Modern languages such as Go and Rust focus on scalability, concurrency, and safety in distributed systems.

Understanding this evolution helps in identifying why a particular language exists and what problem it solves. Instead of just learning syntax, it becomes important to understand the purpose behind each language — whether it is designed for system programming, web development, mobile applications, or large-scale distributed systems.

Python (1991)

Python was created by Guido van Rossum in 1991. The main idea behind creating Python was to solve a very real problem that developers were facing at that time — programming languages like C and C++ were powerful, but they were complex, difficult to read, and required writing a lot of boilerplate code even for simple tasks. Guido wanted to create a language that feels natural to read and write, almost like English, so that developers can focus more on solving problems rather than struggling with syntax.

Python supports Object-Oriented Programming (OOP), but it was not limited to just one paradigm. It was designed as a multi-paradigm language, meaning you can write procedural code, functional code, or OOP-based systems depending on your use case. This flexibility is one of the reasons why Python became extremely popular in modern development.

From a real-world perspective, companies use Python in multiple domains:

Backend development (Django, Flask) Machine Learning and AI (your current learning path) Automation (similar to how you solved your Docker problem) Data analysis and scripting

Python was created using C language internally, which is why it balances simplicity with performance.

Code Example:

class DeploymentManager: 
      def init(self, app_name): 
          self.app_name = app_name
      def deploy(self):
          print(f"Deploying {self.app_name} to centralized               Docker server")
manager = DeploymentManager("Client Application") manager.deploy()

In my experience, Python is like your first practical tool — it allows you to quickly build solutions without overthinking low-level complexity.

JavaScript (1995)

JavaScript was created by Brendan Eich in 1995, and interestingly, it was developed in just 10 days. At that time, the web was static — websites could not interact with users dynamically. The problem was clear: browsers needed a language that could run inside them and make web pages interactive without contacting the server again and again.

JavaScript solved that problem by introducing client-side scripting. Initially, it was not designed as a full programming language, but over time it evolved into one of the most powerful ecosystems.

JavaScript supports OOP, but unlike traditional languages, it uses prototype-based inheritance instead of classical inheritance. Later, ES6 introduced class syntax to make it easier for developers.

Today, companies use JavaScript everywhere:

Frontend frameworks (React, Angular, Vue) Backend (Node.js) Full-stack development Real-time applications (chat apps, dashboards)

The biggest strength of JavaScript is that it runs in the browser, meaning every user already has the runtime installed — no extra setup required.

Code Example:

class DeploymentManager {
  constructor(appName) {
    this.appName = appName;
  }

  deploy() {
    console.log(`Deploying ${this.appName} via web dashboard`);
  }
}

const manager = new DeploymentManager("Client Application");
manager.deploy();

In real-world thinking, JavaScript is like moving your application logic closer to users — similar to how you reduced installation effort using Docker.

Java (1995)

Java was created by James Gosling at Sun Microsystems. The core problem Java tried to solve was platform dependency. Earlier, if you wrote software for Windows, it would not run on Linux or Mac without changes.

Java introduced the concept of "Write Once, Run Anywhere" using the Java Virtual Machine (JVM). Instead of running directly on the system, Java code runs on JVM, which acts as a middle layer.

Java is a fully Object-Oriented Programming language, meaning everything revolves around classes and objects. This makes it highly structured and suitable for large-scale enterprise applications.

Companies use Java for:

Banking systems Enterprise backend systems Android development Large distributed systems

Java was heavily inspired by C++, but it removed complex features like pointers to make development safer.

Code Example:

class DeploymentManager {
    String appName;

    DeploymentManager(String appName) {
        this.appName = appName;
    }

    void deploy() {
        System.out.println("Deploying " + appName + " using centralized server architecture");
    }

    public static void main(String[] args) {
        DeploymentManager manager = new DeploymentManager("Client Application");
        manager.deploy();
    }
}

From a practical perspective, Java is like building a strong, structured system where everything is controlled and scalable — similar to managing applications through a central Docker server.

C (1972)

C was created by Dennis Ritchie at Bell Labs. The main goal was to build a language that could be used to develop operating systems efficiently. In fact, UNIX OS was written in C, which made C one of the most influential programming languages ever created.

C does not support OOP. It is a procedural programming language, meaning programs are structured as a sequence of instructions and functions.

C was created because assembly language was too low-level and difficult to manage for large systems. C provided a balance — it is close to hardware but still readable.

Companies and systems use C for:

Operating systems (Linux, Windows core components) Embedded systems Device drivers

Code Example:

#include <stdio.h>

void deploy(char appName[]) {
    printf("Deploying %s using system-level execution\n", appName);
}

int main() {
    deploy("Client Application");
    return 0;
}

From a real-world point of view, C is like working directly with the machine — maximum control but requires deep understanding.

Go (2009)

Go (Golang) was created at Google by Rob Pike, Ken Thompson, and Robert Griesemer. The problem they faced was managing large-scale systems with languages like C++ and Java, which had become complex and slow to compile.

Go was designed to simplify development for cloud systems and distributed applications, which directly connects to your Docker-based thinking.

Go does not follow traditional OOP, but it supports structs and interfaces, which achieve similar functionality in a simpler way.

Companies use Go for:

Cloud platforms Microservices DevOps tools (Docker, Kubernetes are written in Go)

Code Example:

package main
import "fmt"

type DeploymentManager struct {
    appName string
}

func (d DeploymentManager) deploy() {
    fmt.Println("Deploying", d.appName, "using containerized infrastructure")
}

func main() {
    manager := DeploymentManager{appName: "Client Application"}
    manager.deploy()
}

From a practical mindset, Go is exactly what you applied — simple, scalable, and built for distributed systems.

Rust (2010)

Rust was created by Graydon Hoare at Mozilla. The main problem Rust was trying to solve was something very serious in system programming — memory safety. Languages like C and C++ give full control to developers, but that control comes with risks like memory leaks, segmentation faults, and undefined behavior. These issues are very hard to debug and can crash entire systems.

Rust was designed in a very unique way. Instead of using garbage collection like Python or Java, it introduced a concept called ownership and borrowing. This ensures memory safety at compile time itself, meaning many errors are caught before the program even runs.

Rust supports OOP concepts like structs, methods, and encapsulation, but it does not follow traditional class-based inheritance. It focuses more on safety and performance.

Companies use Rust for:

System-level programming
High-performance backend systems
Security-critical applications
Browsers (Mozilla used it in Firefox components)

Code Example:

struct DeploymentManager {
    app_name: String,
}

impl DeploymentManager {
    fn deploy(&self) {
        println!("Deploying {} with memory-safe execution", self.app_name);
    }
}

fn main() {
    let manager = DeploymentManager {
        app_name: String::from("Client Application"),
    };
    manager.deploy();
}

From a practical mindset, Rust is like building a system where mistakes are not allowed at runtime — everything is validated early, just like preventing deployment errors before pushing to production.

Swift (2014)

Swift was created by Chris Lattner at Apple. Before Swift, Apple developers used Objective-C, which was powerful but complex and difficult to read.

The problem Swift solved was developer productivity and safety in iOS/macOS development. Apple wanted a modern language that is fast, safe, and easy to use.

Swift is a fully Object-Oriented and protocol-oriented language. It combines OOP with modern features like type safety and optionals to avoid runtime crashes.

Companies use Swift for:

iOS app development
macOS applications
Apple ecosystem products

Code Example:

class DeploymentManager {
    var appName: String

    init(appName: String) {
        self.appName = appName
    }

    func deploy() {
        print("Deploying \(appName) in Apple ecosystem")
    }
}

let manager = DeploymentManager(appName: "Client Application")
manager.deploy()

From a real-world view, Swift is like upgrading from an old system to a modern, optimized system — same goal, but faster and safer execution.

Kotlin (2011)

Kotlin was created by JetBrains. The problem Kotlin aimed to solve was the verbosity and boilerplate code in Java. Developers were writing too much repetitive code for simple tasks.

Kotlin is fully Object-Oriented and also supports functional programming. It runs on the JVM, which means it is fully compatible with Java but much more concise.

Google officially adopted Kotlin for Android development, which made it extremely popular.

Companies use Kotlin for:

Android apps
Backend development (Spring Boot with Kotlin)
Multiplatform apps

Code Example:

class DeploymentManager(val appName: String) {
    fun deploy() {
        println("Deploying $appName with modern Android architecture")
    }
}

fun main() {
    val manager = DeploymentManager("Client Application")
    manager.deploy()
}

From your perspective, Kotlin is like optimizing an existing system (Java) to remove unnecessary effort — similar to how you replaced manual installs with Docker.

TypeScript (2012)

TypeScript was created by Microsoft. The main issue with JavaScript was that it is dynamically typed, which leads to bugs in large applications.

TypeScript solves this by adding static typing on top of JavaScript. It helps developers catch errors during development rather than runtime.

TypeScript supports full OOP concepts and is widely used in large-scale applications.

Companies use TypeScript for:

Enterprise frontend applications
Scalable web apps
Angular development

Code Example:

class DeploymentManager {
  appName: string;

  constructor(appName: string) {
    this.appName = appName;
  }

  deploy(): void {
    console.log(`Deploying ${this.appName} with type safety`);
  }
}

const manager = new DeploymentManager("Client Application");
manager.deploy();

From a practical view, TypeScript is like adding validation rules before deployment — fewer runtime surprises.

C# (2000)

C# was created by Anders Hejlsberg at Microsoft. It was designed as part of the .NET framework to compete with Java.

C# is a fully Object-Oriented language and provides strong type safety and modern features.

Companies use C# for:

Enterprise applications
Windows desktop apps
Game development (Unity)

Code Example:

using System;

class DeploymentManager {
    string appName;

    public DeploymentManager(string appName) {
        this.appName = appName;
    }

    public void Deploy() {
        Console.WriteLine("Deploying " + appName + " using .NET ecosystem");
    }
}

class Program {
    static void Main() {
        var manager = new DeploymentManager("Client Application");
        manager.Deploy();
    }
}

From a real-world mindset, C# is like building a structured enterprise system with strong rules and stability.

PHP (1994)

PHP was created by Rasmus Lerdorf. It started as a simple scripting tool for web pages.

Over time, it evolved into a full backend language with OOP support.

Companies use PHP for:

Web development
CMS platforms (WordPress)

Code Example:


<?php
class DeploymentManager {
    public $appName;

    function __construct($appName) {
        $this->appName = $appName;
    }

    function deploy() {
        echo "Deploying " . $this->appName . " via web server";
    }
}

$manager = new DeploymentManager("Client Application");
$manager->deploy();
?>

Ruby (1995)

Ruby was created by Yukihiro Matsumoto. The goal was developer happiness and productivity.

Ruby is fully Object-Oriented — everything is an object.

Used in:

Web development (Rails)

Code Example:

class DeploymentManager
  def initialize(app_name)
    @app_name = app_name
  end

  def deploy
    puts "#{@app_name} deployed with developer-friendly approach"
  end
end

manager = DeploymentManager.new("Client Application")
manager.deploy

COBOL (1959)

COBOL was designed by a committee led by Grace Hopper.

It does not originally support OOP.

Used in:

Banking systems
Financial institutions

Code Example:

IDENTIFICATION DIVISION.
PROGRAM-ID. DEPLOY.
PROCEDURE DIVISION.
DISPLAY "Deploying Client Application in banking system".
STOP RUN.

Fortran(1957)
It was created by IBM for scientific computing.

Used in:

Scientific simulations
Engineering

Code Example:

program deploy
  print *, "Deploying Client Application in scientific system"
end program deploy

Wrap -up

The real skill is not just learning syntax — it is understanding why a language exists and when to use it, just like choosing Docker instead of manual deployment.

👉 I take a hands-on approach to building a unified architecture using Node.js for frontend, Python for notification ,C# .NET for backend. {% embed https://dev.to/practical_tech_notes/docker-microservices-demo-with-cross-language-containers-mf1 %}

Sumeet Dugg — Thu, 30 Apr 2026 10:22:21 +0000

Sumeet Dugg

Apr 30

Docker Microservices Demo with Cross-Language Containers

#docker #microservices #tutorial #devops

Comments

5 min read

Docker Microservices Demo with Cross-Language Containers

Sumeet Dugg — Thu, 30 Apr 2026 10:14:07 +0000

Docker Microservices Demo with Cross-Language Containers

From Local Development to Docker - A Cross-Language Technical Roadmap

By the end of this guide, you'll understand how to:

Build a microservices application using multiple programming languages
Run C# (.NET), Python (Flask), and Node.js (Express) services independently
Convert applications into Docker images
Use a Docker network so containers can communicate by service name
Understand how containers isolate file systems, networking, and runtime environments
Use docker build, docker run, and docker network commands
Build a basic frontend that communicates with backend services

Prerequisites

Foundational Knowledge

Basic understanding of C#, Python, and JavaScript/Node.js
Familiarity with command line/terminal
Basic understanding of APIs and HTTP requests

Software Required

Docker Desktop installed and running
.NET 8 SDK (Optional)
Python 3.12+ (Optional)
Node.js 22+ (Optional)
Google Chrome or any browser
Text editor (VS Code recommended)

Hardware Requirements

Windows/Linux/Mac system
Minimum 8 GB RAM recommended
Internet connection for downloading Docker images and packages

Introduction: What Are Containers in Docker?

Containers run in isolated environments on a host machine (local or remote). Docker containers have their own:

File system
Networking
Processes
Runtime environment

This allows developers to build applications that behave consistently across systems.

You can create private Docker networks where containers communicate securely using container names instead of IP addresses.

The Story Behind This Project

To understand Docker networking practically, I created three separate applications using different technologies:

C# for the authentication service
Python for the notification service
Node.js for the frontend dashboard

Instead of running everything on localhost manually, Docker containers make them work together cleanly.

What Is Microservices Architecture?

Microservices is an architectural style where an application is split into small independent services.

Instead of one large monolithic application:

Each service handles one responsibility
Services can be built in different languages
Services can scale independently
Teams can develop services separately

In this project:

Auth handles login/payment response
Notification handles alerts
Frontend shows all data in browser

Project Structure

micro-demo/
├── auth-service/          # C# ASP.NET Core Service
│   ├── auth-service.csproj
│   ├── Program.cs
│   └── Dockerfile
├── notification-service/  # Python Flask Service
│   ├── app.py
│   ├── requirements.txt
│   └── Dockerfile
└── frontend/              # Node.js Frontend
    ├── server.js
    ├── package.json
    └── Dockerfile

Download Project Files: GitHub Repository

Step 1: Build the C# Auth Service

Program.cs

using auth_service.payment_services;

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

var payment = new PaymentService();

app.MapGet("/", () => "auth-service running");

app.MapGet("/login", () =>
{
    return Results.Ok(new
    {
        token = "jwt-demo-token"
    });
});

app.MapGet("/pay", async () =>
{
    return Results.Ok(await payment.ProcessPayment());
});

app.Run("http://0.0.0.0:8080");

payment-service/payment.cs

using System.Net.Http;

namespace auth_service.payment_services;

public class PaymentService
{
    private readonly HttpClient http = new HttpClient();

    public async Task<object> ProcessPayment()
    {
        string notify = "";
        try
        {
            notify = await http.GetStringAsync("http://notification-service:5000/notify");
        }
        catch
        {
            notify = "notification failed";
        }

        return new
        {
            service = "payment-service",
            payment = "success",
            notification = notify
        };
    }
}

auth-service.csproj

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>
</Project>

Dockerfile

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -o /app

FROM mcr.microsoft.com/dotnet/aspnet:8.0
WORKDIR /app
COPY --from=build /app .
EXPOSE 8080
ENTRYPOINT ["dotnet", "auth-service.dll"]

Build Image

docker build -t auth-service:Demo .

Step 2: Build Python Notification Service

app.py

from flask import Flask

app = Flask(__name__)

@app.route("/")
def home():
    return "notification-service running"

@app.route("/notify")
def notify():
    return "Email + SMS sent"

app.run(host="0.0.0.0", port=5000)

requirements.txt

Flask

Dockerfile

FROM python:3.12-slim
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
EXPOSE 5000
CMD ["python", "app.py"]

Build Image

docker build -t notification-service:Demo .

Step 3: Build Node.js Frontend

server.js

const express = require("express");
const axios = require("axios");
const app = express();

app.get("/", async (req, res) => {
  let csData = {};
  let pythonData = "";

  try {
    const csResponse = await axios.get("http://auth-service:8080/pay");
    csData = csResponse.data;
  } catch (err) {
    csData = { error: "C# service unreachable" };
  }

  try {
    const pyResponse = await axios.get("http://notification-service:5000/notify");
    pythonData = pyResponse.data;
  } catch (err) {
    pythonData = "Python service unreachable";
  }

  res.send(`
    <html>
      <head>
        <title>Microservices Frontend</title>
      </head>
      <body>
        <h1>Frontend Dashboard</h1>
        <pre>${JSON.stringify(csData, null, 2)}</pre>
        <pre>${pythonData}</pre>
      </body>
    </html>
  `);
});

app.listen(3000, () => {
  console.log("Frontend running at Docker");
});

package.json

{
  "dependencies": {
    "axios": "^1.15.2",
    "express": "^5.2.1"
  }
}

Dockerfile

FROM node:22-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

Build Docker Image

docker build -t frontend-nodejs:Demo .

Step 4: Create Docker Network

docker network create network-microservice

This creates a private bridge network where containers can find each other by container name.

Step 5: Run All Containers

Run Auth Service

docker run -d --name auth-service --network network-microservice -p 5001:8080 auth-service:Demo

Run Notification Service

docker run -d --name notification-service --network network-microservice -p 5002:5000 notification-service:Demo

Run Frontend

docker run -d --name frontend-nodejs --network network-microservice -p 5003:3000 frontend-nodejs:Demo

Step 6: Verify Network

docker network inspect network-microservice

Output:

"Containers": {
  "2c2361e10770...": {
    "Name": "auth-service",
    "IPv4Address": "172.19.0.2/16"
  },
  "cdd769411ae9...": {
    "Name": "frontend-nodejs",
    "IPv4Address": "172.19.0.4/16"
  },
  "cf3f827dfe15...": {
    "Name": "notification-service",
    "IPv4Address": "172.19.0.3/16"
  }
}

If all three containers appear in the output, your services are connected successfully!

Step 7: Open in Browser

Navigate to: http://localhost:5003/

You'll see the frontend dashboard showing:

C# Service Data: Payment service response with notification
Python Flask Data: Email + SMS sent confirmation

Key Technical Concepts Learned

Why Container Names Work

Inside the Docker network:

http://auth-service:8080
http://notification-service:5000

Docker automatically resolves names to container IP addresses.

Why This Is Powerful

You built:

Cross-language architecture
Independent deployments
Internal service communication
Real microservices behavior

Common Problems & Fixes

Docker Not Running

Start Docker Desktop first.

Port Already Used

Change -p host:container

Example:

-p 6003:3000

Container Cannot Reach Another Container

Ensure both are on same network:

docker network inspect network-microservice

Final Thoughts

This project demonstrates that Docker is not just for packaging apps—it becomes an operating environment where multiple services can behave like a distributed system on one machine.

You used:

C#
Python
Node.js
Networking
APIs
Containers

That is real backend engineering practice.

Questions? Comments? Drop them below!

If you found this helpful, give it a and share with your dev community!

Author: Sumeet Dugg

Published: April 29, 2026

Fake Developer Dashboard That Roasts You While You Work 💀

Sumeet Dugg — Sun, 12 Apr 2026 14:43:11 +0000

This is a submission for the DEV April Fools Challenge

What I Built

I built FakeDevDashboard — a satirical, real-time developer dashboard that looks completely serious but shows 100% fake (and painfully relatable) metrics written in Csharp programming.

It includes:

Fake system metrics (CPU always dying 🔥)
Developer “mental state” tracking (highly questionable accuracy)
AI-generated chaos predictions using Google Gemini
Fake commit history (aka Wall of Shame)

The goal was simple:

👉 Make something that looks enterprise-level… but do silly things to developers.

Project

sumeetpypi / dev-Challenges-projects

⚡ FakeDevDashboard

A completely fake, hilariously over-engineered developer monitoring dashboard that looks very serious and roasts you while you work.

⚡ FAKEDEV DASHBOARD ONLINE
All metrics are completely fake. Your prediction is 100% real

📸 What It Looks Like

A dark terminal-aesthetic dashboard with four main panels:

System Metrics — CPU always screaming, RAM holding on for dear life
Mental State Monitor — Imposter syndrome at 94%, sanity at 12%
AI Chaos Engine — Gemini AI predicting your production outages
Wall of Shame — Your fake (but accurate) commit history

✨ Features

Feature	Description
🖥️ Fake System Metrics	CPU/RAM/Disk/Network bars that auto-refresh every 8 seconds
🧠 Mental State Monitor	Tracks sanity, confidence, imposter syndrome & reddit time
🤖 AI Chaos Engine	Google Gemini generates prophecies, horoscopes & chaos warnings
💬 Live AI Chat	Full conversation with the Chaos Engine in the dashboard
🚨 Random Alerts	Rotating panel of darkly humorous

…

View on GitHub

How I Built It

🏗️ Tech Stack

ASP.NET Core MVC (.NET 8)
C#
Google Gemini 2.0 Flash API
HTML + CSS Grid + JavaScript (fetch + setInterval)

⚙️ Architecture

The project follows clean MVC architecture:

🔌 Key Features

Live updates using polling (no SignalR)
Dependency Injection with Singleton services
AI integration with fallback handling
Graceful degradation (works even without API key)

🤖 AI Chaos Engine

Uses Google Gemini API to generate:

Developer horoscope
Daily prophecy
Deployment risk
Chaos probability

Fallback system ensures:

App never crashes
Always returns something funny

🧩 Features

🖥️ System Metrics

CPU always above 90%
Chrome using entire RAM
Node modules consuming reality

🧠 Developer Metrics

Confidence: low
Bugs: increasing
Google searches: questionable

🤖 AI Chat

Ask AI if you should deploy
Get roasted professionally

📝 Wall of Shame

Example commits:

⚡ Fun Elements

Random chaos alerts every ~25 seconds
“Trigger Chaos” button
Konami Code Easter Egg 🎮
DevTools console surprise
Fake but realistic alerts

💡 What I Learned

Clean dependency injection in ASP.NET Core
Using IHttpClientFactory properly
Async/await patterns in real APIs
Strongly typed ViewModels
Designing resilient systems with fallbacks

🚀 Try It Yourself

Clone the repo
Open in Visual Studio 2022
Add Gemini API key in appsettings.json (optional)
Run the app

No API key?

👉 No problem — it still works with built-in chaos 😄

Prize Category

Best Google AI Usage

Because:

Integrated Gemini API into a real app
Built fallback-safe AI system
Used AI creatively (not just “generate text”)
Turned AI into a chaos engine 😈

Final Thought

We spend so much time building serious software.

Sometimes…

you need a dashboard that tells you:

“Deployment successful. Consequences unknown.”

ASP.NET Core MVC Explained — Step-by-Step with Real Code & Best Practices

Sumeet Dugg — Tue, 07 Apr 2026 10:45:25 +0000

Understand models, views, controllers and why you should use MVC for scalable, testable applications.

Introduction

Model-View-Controller (MVC) is the standard architectural pattern for building modern web applications in ASP.NET Core. It is a design pattern that separates an application into three main logical components: the Model, the View, and the Controller.

This separation helps manage complexity when building applications, allowing you to focus on one aspect of the implementation at a time.

During my college days, I built a Banking System project as part of my academic curriculum. You can check it out here: bankingProject-c-.net
Challenges & Limitations I Faced Without MVC

Building the project without MVC introduced several problems:

No Separation of Concerns — All HTML, business logic, and data handling lived together. How MVC Solves These Problems In contrast, MVC provides:

Models for data and business logic

Views for UI

Controllers to handle user interaction and route requests

This separation makes the code easier to maintain, easier to test, and cleaner and scalable.

1. The Core Components

Each component has a distinct responsibility. Understanding the boundaries between them is key to writing clean code.

M — The Model

The Model represents the shape of your data and the business logic. It is the "truth" of your application.

Responsibilities: Manages the state of the application and handles data logic (e.g., interacting with the database, validating data rules).
In ASP.NET Core: These are typically plain C# classes (POCOs).
Domain Models: Represent database tables (e.g. Product, User)
View Models: Data specifically shaped for display on a screen (e.g. ProductSummaryViewModel that combines data from multiple tables).

V — The View

The View is the User Interface (UI). Its only job is to display information to the user.

Responsibilities: Renders the user interface elements (HTML, CSS) using data provided by the Controller. Ideally, a View should not contain complex logic — only presentation logic (e.g., loops to display a list, if-statements to show/hide buttons).
In ASP.NET Core: These are .cshtml files using the Razor view engine. Razor allows you to embed C# code directly into HTML to generate dynamic content.

C — The Controller

The Controller is the coordinator. It handles user input and interaction.

Responsibilities: Receives the user's request, figures out what to do with it (usually by calling services or the Model), and then selects which View to return to the user.
In ASP.NET Core: Controllers are C# classes that inherit from Controller. They contain public methods called Actions (e.g., Index(), Details(id)).

2. The Request Lifecycle

To understand MVC, you must follow the path of a web request (e.g., a user clicking a link).

Routing: A user navigates to a URL like Books/Details/2. The ASP.NET Core Routing engine determines it needs the BooksController and the Details action method.
Controller Action: The Details method in the Controller executes.
Model Retrieval: The Model retrieves the data (perhaps from a SQL database).
View Selection: The Controller receives the data, decides which View to use (usually Details.cshtml), and passes the data (the Model) to it.
Rendering: The Razor View Engine takes the HTML template and merges it with the Model data to produce a standard HTML page.
Response: The final HTML is sent back to the user's browser.

3. Key Advantages of MVC Architecture

Separation of Concerns (SoC): By decoupling the UI (View), Data (Model), and Application Logic (Controller), the application becomes easier to manage. Front-end developers can modify HTML/CSS without breaking backend logic, and vice versa.
Enhanced Testability: Since Controllers and Models are standard C# classes independent of the UI, you can easily write unit tests for them without simulating a browser.
Full Control Over HTML: Unlike ASP.NET Web Forms which auto-generated complex HTML, MVC gives you absolute control over rendered markup — critical for modern CSS frameworks like Bootstrap or Tailwind.
Asynchronous Support: ASP.NET Core MVC is built to handle async/await efficiently, allowing applications to handle more concurrent requests without blocking the server.

4. MVC Project Structure in ASP.NET Core

When you create a new MVC project via Visual Studio or CLI (dotnet new mvc), you get this standard folder structure:

Note: If you want to learn how to download and install Visual Studio, check out this guide: Getting Started with C# Programming

Create Your First ASP.NET Core MVC Project

Step 1 — Open Visual Studio and Create a New Project

Open Visual Studio
Click Create a new project

Step 2 — Select Project Template

Choose ASP.NET Core Web App (Model-View-Controller)
Language: C#
Platform: Windows / .NET
Click Next

Step 3 — Configure the Project

Fill in the following details:

Project name: BooksLibrary
Location: Default (or your preferred path)
Solution name: BooksLibrary

Click Next.

Note: You can choose your desired location to store project files. I recommend keep default location as it is now.

Step 4 — Choose .NET Version

Select the latest available version: .NET 9 / .NET 10 (LTS)
Set Authentication type to None
Click Create

Visual Studio will scaffold the project and open the default MVC structure.

Understanding MVC Through Code Examples

M — The Model

In MVC architecture, the Model carries the heaviest responsibility. It represents real-world entities, business logic, and domain rules that form the foundation of your application.

For the BooksLibrary project, we need one class — Book.cs — to hold core information about each library book.

Right-click the Models folder in Solution Explorer → Add → Class → name it Book.cs → click Add.

namespace BooksLibrary.Models
{
    public class Book
    {
        public int Id { get; set; }
        public string? Title { get; set; }
        public string? Author { get; set; }
        public string? Genre { get; set; }
        public decimal Price { get; set; }
    }
}

Note: A namespace is a container that groups related classes in C#. It prevents naming conflicts and keeps your code maintainable.

V — The View

Views are the visual layer of your MVC application. They receive data from Controllers and render it as HTML. Views should not contain business logic — only presentation logic.

Views use Razor syntax (.cshtml files) that blends HTML with C# code.

Folder Structure for Views

Views/
  ├── Books/
  │   ├── Index.cshtml
  │   └── Details.cshtml
  ├── Shared/
  │   └── _Layout.cshtml
  └── _ViewStart.cshtml

Index.cshtml — Book List View

Right-click Views/Books → Add View → name it Index.cshtml.

@model IEnumerable<BooksLibrary.Models.Book>
@{
    ViewData["Title"] = "Books Library";
}

<div class="container mt-4">
    <h2>Our Book Collections</h2>
    <table class="table table-striped table-hover">
        <thead>
            <tr>
                <th>Title</th>
                <th>Author</th>
                <th>Genre</th>
                <th>Price</th>
                <th>Actions</th>
            </tr>
        </thead>
        <tbody>
            @foreach (var book in Model)
            {
                <tr>
                    <td>@book.Title</td>
                    <td>@book.Author</td>
                    <td>@book.Genre</td>
                    <td>$@book.Price.ToString("F2")</td>
                    <td>
                        <a asp-action="Details" asp-route-id="@book.Id"
                           class="btn btn-sm btn-info">Details</a>
                    </td>
                </tr>
            }
        </tbody>
    </table>
</div>

Breaking Down the Razor Syntax

The @model Directive — tells the view what type of data to expect. Must be the first line.

@model IEnumerable<BooksLibrary.Models.Book>

Setting View Metadata — @{ } blocks let you write C# code. ViewData passes info like the page title to the layout.

@{
    ViewData["Title"] = "Books Library";
}

Outputting Variables — the @ symbol switches from HTML to C#.

@book.Title

C# Control Structures — use foreach, if, while inside Razor views.

@foreach (var book in Model)
{
    <tr>
        <td>@book.Title</td>
    </tr>
}

Tag Helpers — asp-action generates the correct route URL; asp-route-id passes the book ID as a parameter.

<a asp-action="Details" asp-route-id="@book.Id" class="btn btn-sm btn-info">Details</a>

Details.cshtml — Single Book View

Create Details.cshtml in the Views/Books folder:

@model BooksLibrary.Models.Book
@{
    ViewData["Title"] = "Book Details";
}

<div class="container mt-4">
    <h2>Book Details</h2>
    <div class="card">
        <div class="card-body">
            <h4 class="card-title">@Model.Title</h4>
            <dl class="row">
                <dt class="col-sm-3">Author</dt>
                <dd class="col-sm-9">@Model.Author</dd>
                <dt class="col-sm-3">Genre</dt>
                <dd class="col-sm-9">@Model.Genre</dd>
                <dt class="col-sm-3">Price</dt>
                <dd class="col-sm-9">$@Model.Price.ToString("F2")</dd>
            </dl>
            <div class="mt-3">
                <a asp-action="Index" class="btn btn-secondary">Back to List</a>
            </div>
        </div>
    </div>
</div>

This view expects a single Book object rather than a collection — note the @model directive reflects that.

C — The Controller

Controllers are the traffic cops of your MVC application. They handle incoming requests, coordinate between Models and Views, and decide what response to send back.

When a user clicks a link or submits a form, the Controller:

Processes the incoming request
Interacts with the Model (retrieves or updates data)
Selects the appropriate View
Passes data to that View
Returns the rendered result to the user

Creating the Books Controller

Right-click Controllers → Add Controller → choose MVC Controller - Empty → name it BooksController.cs.

using System.Diagnostics;
using BooksLibrary.Models;
using Microsoft.AspNetCore.Mvc;

namespace BooksLibrary.Controllers
{
    public class BooksController : Controller
    {
        private static List<Book> _books = new List<Book>
        {
            new Book
            {
                Id = 1,
                Title = "The Alchemist",
                Author = "Paulo Coelho",
                Genre = "Fantasy/Adventure",
                Price = 12.99m
            },
            new Book
            {
                Id = 2,
                Title = "Harry Potter and the Philosopher's Stone",
                Author = "J.K. Rowling",
                Genre = "Fantasy",
                Price = 14.99m
            },
            new Book
            {
                Id = 3,
                Title = "1984",
                Author = "George Orwell",
                Genre = "Dystopian",
                Price = 13.99m
            }
        };

        public IActionResult Index()
        {
            return View(_books);
        }

        public IActionResult Details(int id)
        {
            var book = _books.FirstOrDefault(b => b.Id == id);

            if (book == null)
            {
                return NotFound();
            }

            return View(book);
        }

        [ResponseCache(Duration = 0, Location = ResponseCacheLocation.None, NoStore = true)]
        public IActionResult Error()
        {
            return View(new ErrorViewModel
            {
                RequestId = Activity.Current?.Id ?? HttpContext.TraceIdentifier
            });
        }
    }
}

Breaking Down the Controller

Controller Inheritance

public class BooksController : Controller

Every controller inherits from the Controller base class, which provides View(), RedirectToAction(), and NotFound().

Action Methods

public IActionResult Index()
{
    return View(_books);
}

Action methods return IActionResult — typically a view, redirect, or HTTP status code. View(_books) passes the book collection to the Index view.

Route Parameters

public IActionResult Details(int id)

Parameters are automatically populated from the URL. For /Books/Details/3, the id parameter receives the value 3.

Running the Application

In Visual Studio, find the green ▶ Play button in the top toolbar (labelled "IIS Express" or your project name)
Click it or press F5

The browser will open showing your books list. Click the Details button on any book to see its individual details page.

What We Accomplished

We built a complete MVC application from the ground up, covering all three core components:

The Model — The Book class defines the data structure with properties like Title, Author, Genre, and Price. It is the foundation everything else is built on.
The Views — Two Razor views handle the presentation layer: Index.cshtml lists all books in a table, and Details.cshtml displays information for a single book.
The Controller — BooksController orchestrates everything. It handles incoming requests, manages the book collection, and coordinates between the Model and Views to deliver the right content.

This is the essence of MVC — clean separation of concerns that makes your application easier to maintain, test, and scale.

Found This Helpful?

Leave a comment below sharing what you learned, what challenges you faced, or what you're planning to build next!

Related links:

I moved our Python interpreter into Docker. Full story + setup guide: 👇 https://dev.to/practical_tech_notes/my-local-python-setup-was-quietly-destroying-our-teams-productivity-docker-fixed-it-1647 #Python #Docker #VSCode

Sumeet Dugg — Fri, 03 Apr 2026 15:59:13 +0000

Sumeet Dugg

Apr 3

My Local Python Setup Was Quietly Destroying Our Team's Productivity. Docker Fixed It.

#docker #cicd #python #kubernetes

Comments 2

6 min read

My Local Python Setup Was Quietly Destroying Our Team's Productivity. Docker Fixed It.

Sumeet Dugg — Fri, 03 Apr 2026 15:50:29 +0000

How I moved our Python interpreter into a Docker container, wired it into VS Code, and never looked back.

Let me be upfront with you, I didn't want to write this article.

Not because the topic isn't worth it — it absolutely is — but because writing it means admitting that I let a fixable problem drag on for almost five months before I actually fixed it. Five months of "works on my machine." Five months of onboarding friction. Five months of my team losing hours to an issue that, once solved, took an afternoon.

So consider this both a technical walkthrough and a cautionary tale from someone who waited too long.

The Environment That Slowly Ate Our Standup

Picture this: three developers, one Python codebase, and a Monday morning that starts with a Slack message at 9:04 AM.

"Hey, the pipeline script is throwing a ModuleNotFoundError. Did something change?"

Nothing changed. Nothing ever changed. That was the whole problem.

We had a requirements.txt. We had virtual environments. We had a well-intentioned README with setup instructions that were already six weeks out of date. What we did not have was any guarantee whatsoever that the Python interpreter running on my Windows machine was looking at the same world as the one running on my colleague's MacBook or our third teammate's Ubuntu workstation.

Every developer's local machine is an ecosystem — years of installs, PATH entries, conflicting system packages, half-removed tools that left ghosts behind. You don't notice the weight of it until it starts affecting other people.

The final straw came on a Wednesday afternoon. We were two days from a demo. I'd spent the morning writing a data transformation function that worked perfectly. I pushed it. Twenty minutes later I got a message: "This is crashing for me immediately."

Same code. Different machine. Different Python minor version — 3.10.4 vs 3.10.11 — and a single library that handled a deprecation differently between them.

I spent three hours on that. Three hours, two days before a demo, on an environment problem.

That evening I opened a new branch and set up Docker.

Why Docker and Why VS Code Dev Containers Specifically

The idea is not complicated once you accept it: stop treating your interpreter as something that lives on your machine, and start treating it as something that lives in your project.

Docker lets you write a Dockerfile — essentially a recipe — that describes an environment precisely. Operating system, Python version, every dependency, every configuration detail. Docker builds that recipe into a container: an isolated, reproducible box. Your code runs inside that box. It runs the same way on every machine. It runs the same way in six months when someone dusts off the repo.

VS Code's Dev Containers extension is what makes this actually pleasant to work in. Instead of running Docker separately and juggling a local editor alongside it, VS Code connects directly into the container. Your terminal, your debugger, your IntelliSense, your interpreter — everything operates from inside the container. From the outside it feels exactly like working locally. From the inside, every single person on the team is running identical environments.

That's the shift that mattered to us: the environment stops being invisible infrastructure that lives on individual laptops and becomes an explicit, version-controlled part of the project. When the environment breaks, you fix the Dockerfile and you commit the fix. Everyone gets it.

The Setup, Done Properly

Let me walk through exactly what I built. I'll explain the reasoning behind each piece rather than just dropping files at you.

Project structure when we were done:

my-project/
├── .devcontainer/
│   └── devcontainer.json
├── Dockerfile
├── requirements.txt
└── main.py

The Dockerfile

#Use an official Python runtime as a base image

FROM python:3.14.3-slim

#Optional: tools you may want during development

RUN apt-get update 
&& apt-get install -y --no-install-recommends git curl 
&& rm -rf /var/lib/apt/lists/*

#Set the working directory in the container

WORKDIR /app

#Copy the requirements file into the container (if you have one)

COPY requirements.txt ./

#Install any needed Python packages specified in requirements.txt

RUN pip install --no-cache-dir -r requirements.txt

#Copy code last (better layer caching)

COPY . .

A few deliberate choices here worth explaining.

I used python:3.14.3-slim rather than python:3.14.3. The slim variant strips out things like documentation files and build tools that we don't need at runtime. It keeps the image smaller and faster to pull, which matters when someone is spinning this up for the first time on a slow connection.

The WORKDIR /app appline sets the working directory inside the container to a clean, predictable path. When VS Code mounts your project into the container, it maps to this location. No path confusion, no surprises.

Copying requirements.txt before anything else is intentional. Docker builds in layers, and it caches each layer. If your requirements haven't changed but your code has, Docker doesn't re-run pip install on every rebuild — it uses the cached layer. This makes iteration fast.

Requirements File

I added list of libraries, i was willing to use

fastapi
uvicorn
pydantic
numpy
pandas
scikit-learn
langchain
openai
requests
python-dotenv

Building docker image

Open cmd or visual code terminal .
1. Go to project files where it have Dockerfile from cmd for example cd .
Write command as shown below:

docker build -t my-python-interpreter:3.14.3 .

What above Command Does ??

It builds a Docker image from your project files and gives name to it.

Step-by-Step Explaination

docker build - Create an image using the Dockerfile in this directory.
-t - It lets you name your image .

In our case my-python-interpreter is the name of image and 3.14.3 is the version(tag)

Running Docker python interpreter image from VScode

Let start adding docker image interpreter to VScode

Open VS Code and open the project folder containing your Dockerfile.
Hit Ctrl + Shift + P and type Dev Containers: Add Dev Container into the text box.
Click on Dev Containers: Add Dev Container Configuration Files...
Click on Add configuration to workspace and press Enter.
It will create the configuration files in your project.

Next Step run container

Running container in VScode terminal code

open terminal in VScode from Menu → Terminal → New Terminal
Write command as shown below:

docker run -it my-python-interpreter:3.14.3

docker run - Create + start a new container from an image
-i - Interactive , keeps STDIN open and allow to type commands inside container
-t - Create + start a new container from an image
my-python-interpreter - Image name
3.14.3 - Version name (Tag)

3. Press Ctrl + Shift + P

4 . Write Dev Containers: Attach to Running Container...

5. Press Enter .

6. New window will open , now you can check you added interpreter from ternimal and check python interpreter

7. Write command- which python and which pip, you should see something like below:

Congratulation! Interpreter added successfully

If you want to understand about docker images and containers you can follow article: Understand docker images and containers

What Changed for the Team

I rolled this out on a Thursday. By Friday morning, every developer had pulled the branch, reopened in the Dev Container, and was running code.

Here's the before and after that actually mattered:

Onboarding a new developer, before: roughly four hours. Install Python, set up a virtual environment, install dependencies, hit a conflict, debug the conflict, realise a system package was interfering, fix that, update the README with the step we'd missed.

Onboarding a new developer, after: clone the repo, open in VS Code, click "Reopen in Container," wait three minutes for the image to build, done. The fourth developer we brought on set herself up entirely independently without asking anyone a single question.

Debugging environment issues, before: a ritual of sharing Python versions, pip list outputs, PATH variables, and educated guesses.

Debugging environment issues, after: there are no environment issues. If the code runs in the container on my machine, it runs in the container on yours. When we do find a configuration problem, we fix the Dockerfile, push it, and everyone rebuilds. One fix, universally applied.

The most underrated change was what disappeared from our standups. We used to start every session with at least one throwaway exchange about someone's environment. That's gone. We talk about actual work now.

The Honest Takeaway

The environment is now a first-class part of the project. It lives in the repository. It's reviewed in pull requests. When someone joins the project in eight months, they don't inherit our laptop histories — they get a clean, defined, reproducible box. That's what professional software development should look like.

If you're still fighting your local Python setup — if your standup has a regular guest appearance from "it works on my machine" — this is the fix. It costs an afternoon. It pays back immediately.

If this article saved you debugging time or helped your team, — Questions about the setup? Leave a comment and I'll answer every one.

Echoes of Experience: From Writing Code to Writing Myself

Sumeet Dugg — Mon, 23 Mar 2026 16:00:35 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

This is a submission for the 2026 WeCoded Challenge:

Echoes of Experience

There is a strange kind of silence that comes with staring at a blank screen.

Not the peaceful silence you enjoy after solving a bug.
Not the satisfying quiet after a long day of coding.

This one feels different.It feels like doubt.

That was me a few months ago — not as a developer, but as a writer.

The Developer Who Couldn’t Write

I’ve been a Python developer for over four years now. I’ve built APIs, handled backend logic, worked with databases, and debugged problems that once felt impossible. In code, I was confident.

But writing?

That was a completely different story.

I remember opening my first article draft. The cursor blinked at me like it was asking a question I couldn’t answer:

“What do you even have to say?”

I closed the tab.
That became a habit.

My Journey Didn’t Start With Confidence

Like many developers, my journey wasn’t a straight line.

I didn’t wake up one day knowing Python. I didn’t walk into my first job feeling like an expert. I struggled. A lot.

I come from a background where opportunities weren’t always obvious. I had to figure things out step by step. Learning programming wasn’t glamorous—it was confusing, frustrating, and sometimes lonely.

I still remember spending hours trying to understand why a simple loop wasn’t working. Or why an API call failed without any clear error.

There were no mentors guiding me daily. No perfect roadmap. Just curiosity… and persistence.

And somehow, that was enough._

The Silent Growth No One Sees

In tech, growth is rarely loud.

No one applauds when you finally understand asynchronous programming.
No one celebrates when you debug something after three hours.

But those moments change you.

They build something deeper than skills — they build resilience.

Over the years, I became someone who could break down problems, think logically, and keep going even when nothing made sense.

But here’s what I didn’t realize:

Those struggles were stories.

And I wasn’t telling them.

Why I Started Writing (Even When I Wasn’t Ready)

The idea of writing didn’t come from confidence. It came from frustration.

I wanted to earn something extra. I wanted to share knowledge. I wanted to grow beyond just coding.

But more than that… I wanted to be seen.

Not in a loud, attention-seeking way. But in a real way.

I realized something important:

There are thousands of developers like me — learning quietly, struggling silently, improving slowly.

And most of them never share their journey.

So I decided to try.

Even if I wasn’t perfect.

Even if my writing wasn’t “professional.”

Even if no one read it.

The First Attempt (And the Fear That Came With It)

My first article wasn’t great.

I overthought every sentence. I kept editing. Deleting. Rewriting.

It didn’t sound like me.

It sounded like someone trying to sound smart.

And that’s when I understood something important:

Writing is not about sounding intelligent. It’s about sounding honest.

So I started again.

This time, I wrote like I speak.

Simple. Direct. Real.

And suddenly, it felt easier.

The Reality No One Talks About

Let me be honest.

Writing articles is hard.

Not technically hard — emotionally hard.

You start questioning everything:

“Is this useful?”
“Will anyone read this?”
“Am I wasting my time?”

And when results don’t come quickly — no views, no earnings, no recognition — it hits even harder.

I applied to programs. I waited for responses. Days turned into weeks.

Nothing.

And that silence felt heavier than any rejection.

Because at least rejection gives you closure.

Waiting doesn’t.

But Something Changed

Even though I wasn’t earning yet… something else was happening.

I was thinking differently.

When I solved a problem, I didn’t just move on. I asked:

“How would I explain this to someone else?”

When I learned something new, I thought:

“Is this worth sharing?”

And slowly, I started noticing something:

I wasn’t just consuming knowledge anymore.

I was shaping it.

Writing Made Me a Better Developer

This was unexpected.

Writing didn’t just improve my communication — it improved my thinking.

Because when you write:

You simplify complex ideas
You organize your thoughts
You identify gaps in your understanding

There were times I thought I understood something… until I tried explaining it.

That’s when the real learning began.

The Invisible Struggle of Many Developers

There’s a truth we don’t talk about enough:

Many developers feel invisible.

They work hard. They learn. They grow.

But they don’t share.

Not because they don’t have value — but because they think they don’t.

They think:

“I’m not experienced enough”
“Others know more than me”
“My story isn’t special”

I used to think the same.

But here’s what I’ve learned:

Your story doesn’t need to be extraordinary to be meaningful.

It just needs to be real.

My Experience Is Not Unique — And That’s the Point

I’m not someone who built a startup.
I’m not someone who went viral overnight.
I’m just a developer who kept going.

And that’s exactly why my story matters.

Because it’s relatable.

There are people right now:

Learning their first programming language
Struggling with self-doubt
Trying to find their place in tech

And they don’t need perfect success stories.

They need real ones.

The Turning Point: Accepting Imperfection

At some point, I stopped trying to be perfect.

I stopped chasing the idea of writing “the best article.”

Instead, I focused on writing an honest one.

And that changed everything.

Because perfection delays action.

But honesty creates connection.

What I’ve Learned So Far

If I had to summarize my journey into a few lessons, it would be this:

You Don’t Need Permission to Start

No one will tell you, “Now you’re ready to write.”

You just begin.

Your Early Work Won’t Be Great — And That’s Okay

Growth comes from doing, not waiting.

Consistency Matters More Than Motivation

You won’t feel inspired every day. Show up anyway.

Sharing Is a Skill

Just like coding, writing improves with practice.

Value Comes Before Results

Focus on helping, not earning. Results follow.

Where I Am Today

I’m still learning.

Still writing.

Still figuring things out.

I haven’t “made it” yet. I’m not where I want to be.

But I’m not where I used to be either.

And that matters.

Because progress isn’t always visible.

But it’s always happening.

Why I’m Still Writing

I’m not writing because I’ve achieved everything.

I’m writing because I’m still on the journey.

And maybe that’s the most honest place to write from.

If even one person reads my story and thinks:

“I’m not alone in this.”

Then it’s worth it.

To Anyone Reading This

If you’re a developer who’s thinking about writing… start.

Not when you feel ready.

Not when you feel confident.

Start now.

Write about:

What you learned today
What confused you
What you struggled with
What you finally understood

Because someone out there is exactly where you were yesterday.

And your words might help them move forward.

The Echo That Stays

We often think impact comes from big achievements.

But sometimes, it comes from small, honest stories.

Stories that echo.

Stories that stay.

Stories that remind someone that progress is possible — even when it’s slow, even when it’s messy.

This is mine.

And I’m just getting started.

How I Solved a Deployment Nightmare Using Docker and FastAPI

Sumeet Dugg — Mon, 23 Mar 2026 05:37:52 +0000

The Problem I Faced
I was working at a Python development company where we had to deploy applications on every client machine. Each time a new feature was added or a bug was fixed, we had to manually install or update the application on multiple systems.

This process was:

Time-consuming
Error-prone
Difficult to maintain

Every deployment felt like repeating the same exhausting cycle.

The Idea That Changed Everything
One day, I suggested a simple but powerful idea to my team:

“What if we install Docker on a central server and allow all clients to access the application from there?”

Instead of installing applications on every machine, we could:

Run the application once on a server
Allow clients to access it via a browser using an IP address

Example:

http://<server-ip>:8000

The Result
This approach completely transformed our workflow:

No need to install software on every client machine
Centralized updates (update once, reflect everywhere)
Easy access through browsers
Clean and scalable architecture

Now, every client had separate access to the application just by visiting the server address.

Why Docker Made This Possible
Before Docker:

Applications were installed individually
Dependencies conflicted
Environment issues were common

After Docker:

Everything runs inside containers
Applications become portable
Same setup works anywhere in the world

What is FastAPI (Quick Overview)
FastAPI is a Python-based framework built on top of Starlette. It leverages the Asynchronous Server Gateway Interface (ASGI) technology to perform asynchronous tasks efficiently. FastAPI also validates data using Pydantic, ensuring that incoming requests meet the required schema, as illustrated in the diagram below.

FastAPI runs on the Uvicorn server, which is an asynchronous web server that uses the ASGI standard to run Starlette applications. Uvicorn acts as a handler — it receives HTTP requests and forwards them to Starlette for processing. FastAPI further enhances Starlette’s routing system by adding built-in data validation and automatic API documentation features.

“When I first started learning FastAPI, it was a bit challenging for me to understand its functionalities, especially since I came from a Java programming background. However, as I spent more time working with it, writing code in FastAPI gradually became easier and more intuitive.
What I found most impressive was its asynchronous nature, which allows it to handle multiple HTTP requests at the same time efficiently. It also performs automatic data validation — if the incoming data is invalid, it immediately raises clear exceptions, which makes debugging much simpler.
Another feature that stood out to me was how easy FastAPI makes it to explore and test application endpoints. It comes with a built-in Swagger UI, where you can view and interact with all your APIs. For example, by visiting http: localhost:8000/docs, you can see a complete list of endpoints available in your application and test them directly from the browser.”

Building a Simple FastAPI Application
Let’s create a basic CRUD API.

Create main.py

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
from typing import List

app = FastAPI()

# -----------------------------
# Data Model
# -----------------------------
class Task(BaseModel):
    id: int
    title: str
    completed: bool = False

# Fake in-memory database
tasks: List[Task] = []

# -----------------------------
# CREATE (POST)
# -----------------------------
@app.post("/tasks", response_model=Task)
def create_task(task: Task):
    for t in tasks:
        if t.id == task.id:
            raise HTTPException(status_code=400, detail="Task already exists")
    tasks.append(task)
    return task

# -----------------------------
# READ (GET ALL)
# -----------------------------
@app.get("/tasks", response_model=List[Task])
def get_tasks():
    return tasks

# -----------------------------
# READ (GET ONE)
# -----------------------------
@app.get("/tasks/{task_id}", response_model=Task)
def get_task(task_id: int):
    for task in tasks:
        if task.id == task_id:
            return task
    raise HTTPException(status_code=404, detail="Task not found")

# -----------------------------
# UPDATE (PUT)
# -----------------------------
@app.put("/tasks/{task_id}", response_model=Task)
def update_task(task_id: int, updated_task: Task):
    for index, task in enumerate(tasks):
        if task.id == task_id:
            tasks[index] = updated_task
            return updated_task
    raise HTTPException(status_code=404, detail="Task not found")

# -----------------------------
# DELETE
# -----------------------------
@app.delete("/tasks/{task_id}")
def delete_task(task_id: int):
    for index, task in enumerate(tasks):
        if task.id == task_id:
            tasks.pop(index)
            return {"message": "Task deleted"}
    raise HTTPException(status_code=404, detail="Task not found")

Understanding Docker
Consider Docker as a warehouse robot. Before Docker, workers (like traditional “dockers”) had to carry and manage each package separately, which was time-consuming and inefficient. After the introduction of Docker, every package is packed into standardized containers, making transportation and management much easier and reducing manual effort.

Docker is based on two key concepts: images and containers. To understand this, think of an image as a blueprint of a house, and a container as the actual house built from that blueprint. You can create as many containers (houses) as you want from a single image (blueprint), ensuring consistency across all environments.

Now, let’s create the project file structure.

Note: The .gitignore and README.md files are not essential for this setup, so you can skip creating them.
_

How I Added a FastAPI Application to Docker
If your system does not have Docker pre-installed, you can install it from the official documentation here:
https://docs.docker.com/desktop/setup/install/windows-install/

For now, I am installing Docker on my local system. However, you can follow the same procedure to install it on a central server as well.

Creating a Dockerfile

Create a file named Dockerfile or dockerFile(no extension):

# 1. Base image (Python)
FROM python:3.10-slim

# 2. Set working directory
WORKDIR /app

# 3. Copy requirements file
COPY requirements.txt .

# 4. Install dependencies
RUN pip install --no-cache-dir -r requirements.txt

# 5. Copy project files
COPY . .

# 6. Expose port
EXPOSE 8000

# 7. Run FastAPI app
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

Requirements File Create requirements.txt:

fastapi
uvicorn

Build and Run the Docker Container
Step 1: Build Image

docker build -t fastapi-app .

Now, open the Docker Desktop UI. You will see the image you created listed in the “Images” section, as shown below.

Step 2: Run Container

docker run -d -p 8000:8000 fastapi-app

Open your browser and go to http://localhost:8000/docs/ . You will see the output as shown below:

Final Thoughts
What started as a small idea turned into a major improvement for our team.

Key Takeaways:

Docker eliminates repetitive installations
FastAPI makes backend development fast and efficient
Centralized deployment saves time and effort
Clients can access applications easily via browser

Closing Note
Sometimes, the best solutions are not complex — they just require a shift in thinking.

Instead of asking:

“How do we install this everywhere?”

Ask:

“How can we run this once and access it everywhere?”

That question changed everything for me — and it might do the same for you.