DEV Community: Rakesh Chaubey

Docker with ASP.NET

Rakesh Chaubey — Mon, 23 Jun 2025 17:17:46 +0000

📦 Docker Setup for .NET 8 Web API Project
This document describes how to create a Docker image and run a container for a .NET 8 Web API using a multi-stage Dockerfile.

Docker Ignore

Docker file in visual studio proj

Docker Image

Docker Container

You can have as many container you want for an image

🛠 Dockerfile Breakdown

# Stage 1: Build Environment
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build-env
# 👉 Using .NET SDK 8.0 image for build

WORKDIR /App
# 👉 Set working directory inside container to /App

COPY . ./
# 👉 Copy all files from the current directory to /App inside container

RUN dotnet restore
# 👉 Restore all NuGet packages based on the .csproj file

RUN dotnet publish -c Release -o out
# 👉 Build and publish the app to the /App/out folder in Release mode

# Stage 2: Runtime Image
FROM mcr.microsoft.com/dotnet/aspnet:8.0
# 👉 Use a lighter ASP.NET runtime image for running the app

WORKDIR /App
# 👉 Set working directory again to /App in the runtime image

COPY --from=build-env /App/out .
# 👉 Copy published output from the build stage

EXPOSE 8085
# 👉 Expose port 8085 in the container (used by the app)

ENTRYPOINT ["dotnet", "DemoAPi.dll"]
# 👉 Start the app using dotnet CLI

🐳 Docker Commands
🔧 Build the Docker Image

docker build -t demoimage .

-t demoimage: Tags the image with name demoimage.

.: Refers to the current directory where Dockerfile exists.

🚀 Run the Docker Container

docker run -d --name demo-c -p 8080:8085 demoimage

-d: Detached mode (runs in background).

--name demo-c: Container name is demo-c.

-p 8080:8085: Maps port 8080 on host to port 8085 inside container.

demoimage: Name of the image to use for the container.

🌐 Test the API
Open your browser or use a tool like Postman to test:

http://localhost:8085/WeatherForecast/

📝 Summary
Multi-stage Dockerfile ensures smaller final image.

App is built and published in one stage, and only output is copied to runtime image.

Use port mapping to expose your app externally.

You can create multiple containers from the same image anytime.

---Rough note in hindi

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build-env
# Bhai dotnet sdk 8.0 le aa
WORKDIR /App
# saare cheeze app folder main daalo

# Copy everything to app folder
COPY . ./
# Restore as distinct layers//Aab proj file se sab dll restore kar with exact version
RUN dotnet restore
# Build and publish a release---App folder ke andar outfolder hain usme dal to release code 
RUN dotnet publish -c Release -o out

# Build runtime image
FROM mcr.microsoft.com/dotnet/aspnet:8.0
# sdk bana ke 
WORKDIR /App
# app folder main saara code alread hain upar command ne kiya tha  
COPY --from=build-env /App/out .
# ek port expose karna hoga jaise agar local host call hoga tab kaun se port pe call jayega woh
EXPOSE 8085
# JAB BHI LOCAL HOST SE CALL KAROGE 8085 PORT PE TAB YE APPLICATION RUN HOGA 
# first line wale build env se sab kuch app out main past e hoga 
ENTRYPOINT ["dotnet", "DemoAPi.dll"]
# Project name 


#docker build -t demoimage .
#eska matlab . represt in current directory docker file.
#run this in docker termial it will create image
# now you have created an image for a project . Aab chao to 1000000 container bana do es image ke. Jitne chahe utne 
# Now so as to create container we need to run docker run -d --name demo-c -p 8080:8085 demo-image
# here you are saying docker please run  dettach mode container name (any) which port you want run(localmhost) 
#and also docker host configured in project  and also name of the image you created above
# Now container in ready.
#So as to test run in terminal start "http://localhost:8080/WeatherForecast/"

Time & Space Complexity

Rakesh Chaubey — Mon, 26 May 2025 10:05:09 +0000

Scenario:
You have a list of packages arriving at a warehouse. Each package has a tracking number. Your task is to find duplicate packages based on their tracking number.

Different Approaches to Solve This Problem
Approach 1: Naive — Compare every package with every other package

bool HasDuplicates_Naive(List<string> trackingNumbers)
{
    int n = trackingNumbers.Count;

    for (int i = 0; i < n; i++)
    {
        for (int j = i + 1; j < n; j++)
        {
            if (trackingNumbers[i] == trackingNumbers[j])
                return true; // duplicate found
        }
    }
    return false; // no duplicates
}

Time Complexity Analysis:
Ou

ter loop runs n times.
Inner loop runs about n - 1, then n - 2, ..., 1 times.
Total comparisons ≈ n * (n - 1) / 2 ≈ O(n²) (quadratic).

As the number of packages grows, this approach becomes very slow.

Space Complexity Analysis:

We only use a few variables.
Space complexity is O(1) (constant space).

Approach 2: Using a HashSet (better approach)

bool HasDuplicates_HashSet(List<string> trackingNumbers)
{
    HashSet<string> seen = new HashSet<string>();

    foreach (var number in trackingNumbers)
    {
        if (seen.Contains(number))
            return true; // duplicate found

        seen.Add(number);
    }
    return false; // no duplicates
}

Time Complexity Analysis:

Loop runs n times.
Each lookup and add in HashSet is average O(1).
So total time is O(n) (linear).

Space Complexity Analysis:

We use extra space for the HashSet.
In the worst case (no duplicates), the HashSet stores all n tracking numbers.
So space complexity is O(n).

Explanation in Human Terms (Logistics Domain)
Naive Approach: Like checking every package manually against every other package to find duplicates — this takes a lot of time as packages grow.

HashSet Approach: Like having a quick scanning system that remembers every package’s tracking number as you scan, instantly checking if a package is already scanned.

Approach	Time Complexity	Space Complexity	Real-World Analogy
Naive Comparison	O(n²)	O(1)	Manually checking every package against others
HashSet	O(n)	O(n)	Scanning and recording each package for fast duplicate detection

Run this in local to see the result

using System;
using System.Collections.Generic;
using System.Diagnostics;

class Program
{
    static bool HasDuplicates_Naive(List<string> trackingNumbers)
    {
        int n = trackingNumbers.Count;

        for (int i = 0; i < n; i++)
        {
            for (int j = i + 1; j < n; j++)
            {
                if (trackingNumbers[i] == trackingNumbers[j])
                    return true;
            }
        }
        return false;
    }

    static bool HasDuplicates_HashSet(List<string> trackingNumbers)
    {
        HashSet<string> seen = new HashSet<string>();

        foreach (var number in trackingNumbers)
        {
            if (seen.Contains(number))
                return true;

            seen.Add(number);
        }
        return false;
    }

    static void Main()
    {
        int n = 10000;
        var packages = new List<string>();

        for (int i = 0; i < n; i++)
            packages.Add($"PKG{i}");

        // Add a duplicate at the end
        packages.Add("PKG1234");

        var sw = Stopwatch.StartNew();
        Console.WriteLine("Naive: " + HasDuplicates_Naive(packages));
        sw.Stop();
        Console.WriteLine($"Naive time: {sw.ElapsedMilliseconds} ms");

        sw.Restart();
        Console.WriteLine("HashSet: " + HasDuplicates_HashSet(packages));
        sw.Stop();
        Console.WriteLine($"HashSet time: {sw.ElapsedMilliseconds} ms");
    }
}

Final Takeaway for You as a .NET Logistics Developer:

Time Complexity is about how fast your code runs when the number of packages grows.
Space Complexity is about how much extra memory your code needs.
When designing microservices or APIs for logistics, choose algorithms that balance speed and memory wisely.
Using collections like HashSet or Dictionary often improves time complexity at the cost of space.

Let me give a very easy example:
Problem Statement
Imagine you work in a logistics warehouse that receives thousands of packages daily. Each package has a unique tracking number.

Your job is to detect if there are duplicate packages — meaning if the same tracking number appears more than once.

Why Is This Important?

Detecting duplicates helps avoid shipping mistakes, incorrect billing, or inventory errors.
The solution must be efficient — warehouses handle millions of packages in real-time.
Inefficient algorithms can cause delays or crash systems due to slow processing or memory issues.

The First (Naive) Approach: What Was Wrong?
How It Works

Compare every package with every other package to find duplicates.
For example, if you have 10 packages:
Compare package 1 with package 2, 3, 4...
Then compare package 2 with package 3, 4, 5... and so on.

for (int i = 0; i < n; i++)
{
    for (int j = i + 1; j < n; j++)
    {
        if (trackingNumbers[i] == trackingNumbers[j])
            return true;
    }
}
return false;

What’s Wrong Here?
Time Complexity: This approach takes O(n²) time because for n packages, it does roughly n * (n-1) / 2 comparisons.

What does that mean?

If you double the number of packages, the work done more than quadruples.
Example:

10 packages → 45 comparisons
100 packages → 4,950 comparisons
1,000 packages → 499,500 comparisons

Result: The algorithm gets very slow and impractical as the number of packages grows large (which is typical in logistics).

The Better Approach: Using a HashSet
Concept in Logistics Terms

Imagine a scanner that checks each package’s tracking number as it arrives.
The scanner keeps a list (a “memory”) of all scanned tracking numbers.
When a new package arrives, the scanner quickly checks if this number is already in the list.
If yes → duplicate found!
If no → add it to the list and continue scanning.

HashSet<string> seen = new HashSet<string>();

foreach (var number in trackingNumbers)
{
    if (seen.Contains(number))
        return true; // duplicate found

    seen.Add(number);
}
return false; // no duplicates

What Has Changed?
Time Complexity:

Checking if a number is in the HashSet is O(1) on average (constant time).
You only loop once over all packages → O(n) total time.

Space Complexity:

You use extra memory to store the tracking numbers in the HashSet → O(n) space.

Tradeoff:

You spend some memory to drastically reduce the processing time.

Why Is the HashSet Approach Much Better?

Scenario	Naive Approach	HashSet Approach
Number of Packages (n)	1,000	1,000
Number of Comparisons	~499,500	1,000 lookups (plus add ops)
Time to Detect Duplicates	Very slow	Very fast
Memory Usage	Very low (constant)	Moderate (proportional to n)

Real-World Analogy
Naive: Like an employee who manually compares each package against every other one — gets tired and slow as packages pile up.

HashSet: Like a smart scanning machine that instantly checks each package against a database of scanned packages — fast even if the number of packages is huge.

XML

Rakesh Chaubey — Mon, 26 May 2025 09:42:52 +0000

Today, JSON rules the world. But before that — and still in many large enterprises — XML was (and is) the silent workhorse. And in the logistics industry, you'll still find a lot of XML powering core systems like shipment tracking, ERP sync, customs data, and invoicing.

In this post, we’ll cover:

What XML is (with a real-world example)
Where it’s still used in logistics
Why some systems prefer it over JSON
Tips to handle XML well

🧠 What is XML?
XML (eXtensible Markup Language) is a text-based format used to store and exchange structured data. Think of it like HTML, but for data — and it’s both human-readable and machine-readable.
It uses opening and closing tags to define each field.

Here’s a simple logistics-related XML:

<Shipment>
  <ShipmentId>SHIP-98765</ShipmentId>
  <Origin>Mumbai</Origin>
  <Destination>Hyderabad</Destination>
  <Status>Out for Delivery</Status>
  <Items>
    <Item>
      <SKU>T-SHIRT</SKU>
      <Quantity>2</Quantity>
    </Item>
  </Items>
</Shipment>

Pretty neat, right? This looks very similar to what you'd send or receive in a SOAP API or through an enterprise file-based integration.

🚚 Where XML is Still Used in Logistics
Even today, major Indian logistics companies and their backend systems — whether in supply chains, freight networks, or ERP systems — still exchange XML data regularly.

🔄 Here are a few real-life examples:

🧾 Invoices and billing exchanged via EDI/XML
📤 Shipment updates between warehouse management systems
✈️ Customs declaration documents for international shipments
🏦 Payment or reconciliation files from banks in XML format
🔁 Legacy SOAP APIs (still common in big orgs)

✅ Why XML is Still Preferred in Some Cases
Feature Why It Matters in Logistics
Strict structure Ensures every document follows a defined format (using XSD schemas)
Validation-ready You can catch errors before processing
Namespaces Helpful in large B2B integrations to avoid field conflicts
Mature ecosystem Works well with legacy tools like BizTalk, SAP, Oracle, etc.
SOAP Support Some logistics APIs still expose SOAP endpoints (which use XML)

Also, XML is verbose(verbose:XML uses a lot of repeating tags and extra characters (like angle brackets) to describe data.), but that’s not always a bad thing. When clarity and data reliability are more important than size (like in customs or compliance), XML shines.

verbose: XML uses a lot of repeating tags and extra characters (like angle brackets) to describe data. This leads to larger file sizes and more bandwidth usage

<Status>Delivered</Status>
<Location>Mumbai</Location>

In XML, each piece of data requires:

An opening tag ()
A closing tag ()
And if nested, even more structure.

🔧 Best Practices When Working with XML
Use XSD for Validation: Is explained at bottom
Don’t accept XML blindly — validate it using an XML Schema Definition (XSD) to make sure it’s safe and structured properly.

Avoid Deep Nesting
Logistics data often involves nested items — keep your hierarchy simple to avoid parser issues.

Prefer Elements Over Attributes (Usually)

<Item>
  <SKU>T-SHIRT</SKU>
  <Quantity>2</Quantity>
</Item>

This is more readable than packing everything into attributes.

Watch Your Encodings
Always declare your encoding at the top:

<?xml version="1.0" encoding="UTF-8"?>

Convert XML to JSON for Modern Systems
If your .NET or Node.js service receives XML from a legacy vendor, use conversion libraries to bridge the gap with your JSON-based APIs.

🆚 JSON vs XML — Quick Thoughts
Feature JSON    XML
Readability Cleaner Verbose
Validation  Less strict (optional)  Strong with XSD
Data Format Lightweight Heavier
Tooling Modern APIs & UIs   Enterprise tools, SOAP
Use Case    Mobile, APIs, Kafka ERP, finance, SOAP systems

In modern logistics platforms, we often find both JSON and XML living side by side.

Logistics tech in India — from Delhivery, BlueDart, DTDC, to Indian Railways freight, and even eInvoice systems under GST — often requires XML formats for backend integration.

So even if you're building the latest microservice in .NET 8 or using Kafka, don’t be surprised if you have to consume an XML feed from a legacy SAP system.

🧵 Wrapping Up
If you're a backend or integration engineer working in logistics, XML isn't going anywhere just yet. It might not be trendy, but it’s stable, secure, and well-suited for B2B and enterprise workflows.

When you receive XML data — say from a courier partner, ERP system, or customs gateway — how do you know it’s correct? That’s where XSD comes in.

✅ XSD stands for XML Schema Definition.
It acts like a contract that defines:

What elements and attributes are allowed
Data types (string, date, int, etc.)
Required vs optional fields
Structure, nesting, and cardinality

📦 Example: Shipment XML
XML file:

<Shipment>
  <ShipmentId>SHIP-12345</ShipmentId>
  <Status>Dispatched</Status>
  <Weight>12.5</Weight>
</Shipment>

Corresponding XSD:

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="Shipment">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="ShipmentId" type="xs:string"/>
        <xs:element name="Status" type="xs:string"/>
        <xs:element name="Weight" type="xs:decimal"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

This ensures:

ShipmentId is a string ✅
Weight must be a decimal ✅
No extra or missing tags allowed ❌

🛠 Why Use XSD in Logistics?

✅ Validates XML structure before processing
🚫 Prevents corrupt or incomplete shipment/invoice data
🔐 Adds security by rejecting unexpected inputs
🏗 Helps generate documentation and UI forms

In .NET, Java, or Python, you can easily load the XSD and validate incoming XML against it using built-in libraries.

🔧 .NET Example (C#):

var schemaSet = new XmlSchemaSet();
schemaSet.Add("", "Shipment.xsd");

var settings = new XmlReaderSettings();
settings.Schemas = schemaSet;
settings.ValidationType = ValidationType.Schema;
settings.ValidationEventHandler += (s, e) =>
{
    Console.WriteLine("Validation Error: " + e.Message);
};

using var reader = XmlReader.Create("Shipment.xml", settings);
while (reader.Read()) { }

🧵 Bottom Line:
Always ask your partners for an XSD when consuming XML.
It’s the safety net that saves you from bad data and runtime bugs — especially in critical logistics pipelines.

JSON: How JSON Powers Modern Logistics Systems — With Real-World Use Cases

Rakesh Chaubey — Mon, 26 May 2025 09:09:09 +0000

Hey everyone! 👋
I'm Rakesh Chaubey, a backend developer from India with 13+ years of experience working in logistics tech. If you’ve ever built or maintained APIs, data pipelines, or microservices, you already know how crucial structured data is.

In modern web development, JavaScript Object Notation (JSON) has become a go-to format for data interchange, especially in applications like logistics management. Its lightweight structure translates to efficient data handling between servers and clients.
What is JSON?

JSON is a text-based format that represents structured data using key/value pairs. Its simplicity and readability make it easy for both humans and machines to work with.

One format that quietly powers most logistics platforms — from package tracking to warehouse sync — is JSON.

In this post, I’ll walk through:

What JSON really means in the context of logistics
How it’s used behind the scenes in logistics platforms
A real-world example from a shipment-tracking use case
Why you should design and handle JSON carefully

📦 Why JSON is a Big Deal in Logistics
Let’s imagine a courier service like Delhivery or India Post. Every time you send a parcel, the system needs to:

Store package details
Share status with customers
Update internal systems
Integrate with third-party providers (e.g., Flipkart, Amazon)

Each of these actions involves structured data exchange — and that’s where JSON becomes the de facto format.

🔍 A Real JSON Payload From a Shipment System
Here’s a sample JSON response from a fictional logistics backend when you query for tracking info:

{
  "shipmentId": "SHIP-98765",
  "origin": "Mumbai",
  "destination": "Hyderabad",
  "status": "Out for Delivery",
  "lastUpdated": "2025-05-26T07:30:00Z",
  "estimatedDelivery": "2025-05-26",
  "items": [
    {
      "sku": "BOOK-IND-001",
      "description": "Cracking the Coding Interview",
      "quantity": 1
    },
    {
      "sku": "T-SHIRT-L",
      "description": "Black Polo T-Shirt (Size L)",
      "quantity": 2
    }
  ],
  "events": [
    {
      "timestamp": "2025-05-24T13:40:00Z",
      "location": "Hub: Pune",
      "event": "Package arrived at hub"
    },
    {
      "timestamp": "2025-05-25T21:10:00Z",
      "location": "Delivery Center: Hyderabad",
      "event": "Out for delivery"
    }
  ]
}

Now imagine this JSON flowing through:

Internal APIs
Kafka event streams
NoSQL document stores (like Cosmos DB or MongoDB)
Mobile app and customer dashboards

This structure is easy for machines and humans to work with, and flexible enough for new fields like insuranceAmount or fragileItem to be added without breaking downstream consumers.

🧠 Why Developers Love JSON in Logistics
Feature Why It Helps in Logistics
✅ Schema-less Great for evolving delivery systems — add new fields easily
🌍 Language-agnostic Works equally well in C#, Java, Node.js, Python, etc.
⚡ Lightweight Perfect for mobile and low-latency APIs
🧩 Integrates with everything APIs, Kafka, Cosmos DB, MongoDB, etc.
🧪 Easy to test JSON-based stubs and mocks simplify testing in microservices

🧱 Best Practices When Working with JSON in Logistics

Always Version Your APIs

GET /api/v1/shipments/SHIP-98765 Adding /v1/ helps when your logistics systems evolve and older clients are still using older formats.

Use PascalCase or camelCase Consistently
Choose a naming convention and stick to it across services. In .NET, PascalCase is common, while in JavaScript or JSON payloads, camelCase is widely used.
Include Metadata for Better Observability

"sourceSystem": "OrderService",
"processedBy": "TrackingService",
"correlationId": "abc-123"

Metadata helps trace issues across distributed systems, especially in event-driven architectures.

Validate Your Payloads Always validate your incoming and outgoing JSON. Tools like FluentValidation in .NET or JSON Schema help avoid garbage data polluting downstream services.

5.Secure It
Don’t expose internal structure or stack traces in error responses.

Never log sensitive data like customer addresses or phone numbers without redaction.