DEV Community: Sourabh Mandal

Dont Forget to Package Go App the right way in Docker

Sourabh Mandal — Fri, 16 May 2025 14:02:28 +0000

Packaging applications with Docker is standard practice today — but for production-ready Go apps, image size, startup time, and security matter. In this post, we’ll walk through how to containerize a Go application, then progressively optimize the image size from 45MB to just 4MB using tried-and-tested techniques.

🚀 Why Containerize Golang Apps?

Go produces statically linked binaries — ideal for minimal containers.
Containerized apps run reliably across different environments.
Optimized containers improve deployment speed, resource usage, and security.

🛠️ What You’ll Learn

How to containerize a Golang app with Docker.
Multi-stage builds and their benefits.
Reducing image size with Go build flags.
Using minimal base images (scratch).
Compressing binaries with UPX.
Real-world deployment tips and optimizations.

📖 Step 1: Basic Dockerfile

Let’s start simple — a basic Dockerfile using the official Go image:

FROM golang:1.24.3

WORKDIR /app

COPY go.mod go.sum ./
RUN go mod download

COPY . .
RUN go build -o server ./cmd/main.go

EXPOSE 8080
CMD ["./server"]

Image size: 🐳 ~45MB
✅ Works fine for development, but not production-friendly.

📖 Step 2: Multi-Stage Build

Now, let’s reduce size by separating build-time and runtime environments:

FROM golang:1.24.3 AS build

WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN go build -o server ./cmd/main.go

FROM golang:1.24.3
WORKDIR /app
COPY --from=build /app/server /server
EXPOSE 8080
CMD ["./server"]

Image size: 🐳 ~38MB
✅ Keeps runtime image clean — no build tools.

📖 Step 3: Minimal Base Image (scratch)

Use a minimal base image like scratch for further optimization:

FROM golang:1.24.3 AS builder

WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o server ./cmd/main.go

FROM scratch
COPY --from=builder /app/server /server
ENTRYPOINT ["/server"]

Image size: 🐳 ~17MB
✅ Only includes your Go binary — nothing else.

Note: Requires statically linked binaries (CGO_ENABLED=0).

📖 Step 4: Go Build Flags

Use Go build flags to strip debugging info:

go build -ldflags="-s -w" -o server ./cmd/main.go

Image size: 🐳 ~12MB
✅ Smaller binaries, faster startup.

📖 Step 5: UPX Compression

Compress your binary with UPX:

upx --ultra-brute --quiet server

Image size: 🐳 ~4MB
✅ Drastically reduced size, with negligible startup overhead.

📦 Final Optimized Dockerfile

FROM golang:1.24.3-alpine AS build

WORKDIR /app

RUN apk add --no-cache upx

COPY go.mod go.sum ./
RUN go mod download && go mod verify
COPY . .

RUN CGO_ENABLED=0 GOARCH=amd64 GOOS=linux go build -v \
  -o server \
  -ldflags="-s -w" \
  -installsuffix cgo \
  ./cmd/main.go

RUN upx --ultra-brute --quiet server && upx --test server

FROM scratch

COPY --from=build /app/server /server

ENTRYPOINT ["/server"]

Final image size: 🐳 4MB

📊 Image Size Summary

Optimization Level	Image Size
Basic Golang + Alpine	45MB
+ `-ldflags="-s -w"`	38MB
+ `scratch`	17MB
+ UPX	4MB

💡 Bonus Tips

Use layer caching for faster CI/CD builds.
Include SSL certificates if using scratch.
Gracefully handle signals for safe shutdowns.
Define Docker health checks.
Integrate security scanning tools.
Measure container performance metrics post-deployment.

📈 Real-World Impact

Lower cloud storage and registry costs
Faster container startup times
Better scaling performance
Improved security with minimal attack surface

🎯 Recap: 4 Key Optimization Techniques

✅ Multi-stage builds to separate build and runtime.
✅ Go build flags (-ldflags="-s -w") for smaller binaries.
✅ Using scratch for minimal base images.
✅ UPX for ultra-light binary compression.

📚 Further Reading

📚 The Ultimate React Interview Preparation Guide for Senior Software Engineers (2025)

Sourabh Mandal — Fri, 16 May 2025 13:46:51 +0000

In this comprehensive guide, I’ll break down the essential React concepts every senior software engineer should master before heading into an interview. Whether you're preparing for a product company, a startup, or a remote global team, this list will ensure you're ready for deep technical discussions.

📖 Core React Fundamentals

Start with rock-solid fundamentals. Even as a senior, you’ll be expected to explain these clearly:

JSX — How it transpiles to React.createElement.
Virtual DOM — What it is, how reconciliation and diffing work.
Functional vs Class Components.
Props and PropTypes for validation.
Local State Management in components.
Event Handling and Synthetic Events.
Lifecycle Methods (class-based) and useEffect (functional).
Controlled vs Uncontrolled Components in forms.
Keys in Lists and their role in reconciliation.

🟣 Advanced React Concepts

Once fundamentals are solid, you should dive deep into modern React patterns and hooks:

Hooks:
- useState, useEffect
- useRef (for DOM access and persistent values)
- useContext
- useReducer for complex state
- useCallback and useMemo for performance optimization
- useLayoutEffect vs useEffect
- Custom Hooks (when, why, and how to write them)
Context API:
- Provider/Consumer pattern
- Prop drilling avoidance
- Performance implications of context value changes
Error Boundaries — Handling runtime UI errors.
React Portals — Rendering outside the parent DOM tree for modals, tooltips, etc.

🔶 State Management at Scale

Senior roles require understanding both local and global state management strategies:

Redux (or alternatives like Zustand, Recoil, Jotai)
- Store, Actions, Reducers, Selectors
- Async operations (redux-thunk, redux-saga)
- Redux Toolkit for cleaner syntax and setup
React Query / TanStack Query
- Server state management
- Caching, background refetching, pagination
- Optimistic UI updates
- Mutation handling patterns

⚡ Performance Optimization Techniques

You’ll often be asked about application speed and responsiveness:

React.memo
useCallback / useMemo
Code splitting with React.lazy and Suspense
Dynamic imports
Virtualized lists (react-window, react-virtualized)
Lazy loading components and images
Preventing unnecessary re-renders

🟡 Routing Deep Dive

React apps at scale require smart routing structures:

React Router basics and nested routes
Programmatic navigation
Route protection patterns
Query strings and dynamic parameters
Handling 404 routes
Code-splitting routes
Integrating routes with authentication workflows

📝 Forms and Validation Patterns

Forms can get complex — be ready to discuss:

Controlled vs Uncontrolled Forms
Popular libraries: Formik, React Hook Form
Validation with Yup/Zod
Handling dynamic and nested fields
Error handling and UX patterns
Debounced validations

🧪 Testing React Applications

Testing is non-negotiable for senior roles:

Unit testing with Jest
Component testing with React Testing Library
Snapshot testing
Mocking APIs with msw (Mock Service Worker)
Testing custom hooks
End-to-end testing with Cypress or Playwright

🟦 TypeScript in React (If Applicable)

TypeScript is becoming standard in React projects:

Typing Props, State, Refs
Typing custom hooks and Context API
Utility types (Partial, Pick, Omit, Record)
Discriminated unions for complex state management
Strongly-typed component patterns
Type-safe HOCs

📊 Component Design Patterns

Senior engineers must structure reusable and scalable components:

Presentational vs Container components
Compound component pattern
Higher-Order Components (HOCs)
Render Props
Function as child components
Hooks-based composition patterns
Controlled and Uncontrolled components

🛠️ App Architecture and Scalability

Be prepared to talk about app organization and scaling:

Component folder structuring
Modular codebases
Code splitting strategies
Feature-based folder structures
Micro frontends (Module Federation)
Shared UI libraries (with Storybook integration)
Multi-tenant SaaS application patterns

🔒 Security Best Practices

Front-end security awareness is essential:

Preventing XSS in React apps
Sanitizing dynamic HTML (dangerouslySetInnerHTML caveats)
Securely handling API tokens and secrets
Avoiding insecure localStorage usage
Safe authentication flows (JWT, OAuth)

🌐 Server-Side Rendering (SSR) and Static Generation

Modern React projects often involve Next.js or SSR strategies:

SSR vs CSR vs SSG
Next.js getServerSideProps, getStaticProps, ISR
SEO benefits of SSR
Lazy loading server-rendered pages
API routes in Next.js

🚀 Deployment and Build Optimization

Performance tuning and build pipeline awareness:

Webpack concepts (tree shaking, code splitting)
Modern bundlers: Vite, Parcel, ESBuild
Environment variables and API endpoint management
Bundle analysis tools (webpack-bundle-analyzer)
Lighthouse audits and performance budgets

🟢 Integration and API Management

Seamless API communication is crucial:

REST vs GraphQL integration
Axios and Fetch patterns
API error handling strategies
Token storage (HTTP-only cookies vs localStorage)
Real-time communication (WebSockets, SSE)
Offline-first patterns

🎨 Accessibility and Internationalization

Inclusive apps improve user experience:

ARIA attributes and roles
Keyboard navigation support
Screen reader compatibility
React i18n libraries and locale management

⚙️ Bonus: Soft Skills and Senior Responsibilities

Beyond code, senior roles demand leadership and mentorship:

Conducting code reviews and feedback
Leading architectural decisions
Mentoring junior engineers
Technical decision-making and trade-offs
Cross-functional collaboration
Debugging and troubleshooting production systems

🔍 Final Thoughts

React interviews for senior positions go well beyond “how does useState work.” You’ll be expected to demonstrate architectural foresight, performance optimization skills, advanced patterns, and leadership abilities.

If you master the topics in this list and back them up with real-world experience, you’ll be well-positioned to ace your next senior React interview.

Was this helpful?

If you’d like, I can convert this into a handwritten iPad roadmap, a mind map, or a PDF checklist too — just let me know! 🚀

Best way to use Traefik in development mode

Sourabh Mandal — Thu, 15 May 2025 13:04:52 +0000

In the modern microservices architecture, reverse proxies play a crucial role in managing traffic and securing applications. Traefik has emerged as a popular choice due to its Docker-native integration and ease of configuration. This guide will walk you through setting up Traefik locally for development purposes.

What is Traefik?

Traefik is a modern HTTP reverse proxy and load balancer designed to seamlessly deploy microservices. Its standout features include:

Automatic service discovery
Built-in Let’s Encrypt support
Real-time configuration updates
Docker integration
Dynamic load balancing

Prerequisites

Before we begin, ensure you have:

Docker and Docker Compose installed
Basic understanding of YAML configuration
Admin access to modify system files

Setting Up Traefik Locally

First, we need to configure our local network. Create a Docker Compose file and create a localhost_net network like shown below.

services:
  # service definition goes here
  # place for traefik service definition
  # ...

networks:
  localhost_net:
    external: true
volumes:
  traefik-data:
    driver: local

Please note that the network is defined as external so we have to manually create it before we run docker-compose command

To create a network use docker network create localhost_net

Create a localhost network for traefik Domain Configuration

We’ll use two local domains to expose our application endpoints. Traefik has a builtin dashboard which can be exposed to the internet via http endpoint so we will be doing that for local development (not recomended in production setup) and our App on separate endpoint, both of these endpoints will be hosted behind traefik reverse proxy, following are the urls to setup:

Traefik dashboard - https://proxy.localhost
Your application - https://app.localhost

We need to point both these urls to our local loopback address (127.0.0.1) for them to access our locally served up traefik from docker-compose file

Edit /etc/hosts (mac) file in administrator mode. you can check where your host file setup are based on your OS, however configuration are same across OS.

Add the following 2 lines at the end of your host file

Add the Traefik service to your Docker Compose file. Please note that we have mounted a configuration file for traefik instead of defining all configurations in single docker-compose file. We will define these configuration later in the article:

services:
  traefik:
    image: traefik:v3.1.6
    command: "--configFile=/config/traefik.yml"
    ports:
      - "80:80"
      - "443:443"
      - "8080:8080"
    volumes:
      - "./traefik_data:/etc/traefik"
      - "./config/configuration.yml:/config/traefik.yml:ro"
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
      - "./localhost.crt:/certs/localhost.crt:ro"
      - "./localhost.key:/certs/localhost.key:ro"
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.traefik.rule=Host(`proxy.localhost`)"
      - "traefik.http.routers.traefik.entrypoints=websecure"
      - "traefik.http.services.traefik.loadbalancer.server.port=8080"
    networks:
      - localhost_net

networks:
  localhost_net:
    external: true

volumes:
  traefik_data:

Generate local SSL certificates using OpenSSL at the root of your project:
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \ -keyout localhost.key -out localhost.crt

This will generate 2 files localhost.crt and localhost.key

Traefik Configuration file

Create config/configuration.yml with the following settings:

global:
  checkNewVersion: true
  sendAnonymousUsage: false

serversTransport:
  insecureSkipVerify: true

entryPoints:
  # Redirect HTTP to HTTPS
  web:
    address: ":80"
    http:
      redirections:
        entryPoint:
          to: websecure
          scheme: https

  # HTTPS endpoint
  websecure:
    address: ":443"
    http:
      tls:
        domains:
          - main: "localhost"
            sans:
              - "*.localhost"

providers:
  providersThrottleDuration: 2s

  # Docker provider for services running inside Docker
  docker:
    watch: true
    network: localhost_net # Ensure this matches your Docker network name
    exposedByDefault: false

# Enable Traefik UI
api:
  dashboard: true
  insecure: true

# Log level: INFO|DEBUG|ERROR
log:
  level: INFO

# Manual TLS (self-signed certificate setup)
tls:
  certificates:
    - certFile: "/certs/localhost.crt"
      keyFile: "/certs/localhost.key"

Let’s deploy a sample NGINX application behind Traefik:

services:
  traefik:
    image: traefik:v3.1.6
    command: "--configFile=/config/traefik.yml"
    ports:
      - "80:80"
      - "443:443"
      - "8080:8080"
    volumes:
      - "./traefik_data:/etc/traefik"
      - "./config/configuration.yml:/config/traefik.yml:ro"
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
      - "./localhost.crt:/certs/localhost.crt:ro"
      - "./localhost.key:/certs/localhost.key:ro"
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.traefik.rule=Host(`proxy.localhost`)"
      - "traefik.http.routers.traefik.entrypoints=websecure"
      - "traefik.http.services.traefik.loadbalancer.server.port=8080"
    networks:
      - localhost_net

  app:
    image: nginx
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.app.rule=Host(`app.localhost`)"
      - "traefik.http.routers.app.entrypoints=websecure"
      - "traefik.http.services.app.loadbalancer.server.port=80"
    networks:
      - localhost_net

networks:
  localhost_net:
    external: true

volumes:
  traefik_data:

Advanced Configuration Options

Middleware Configuration

Traefik supports various middleware options for enhanced functionality:

# Example of adding basic auth middleware
labels:
   - "traefik.http.middlewares.auth.basicauth.users=admin:$$apr1$$xyz123"
   - "traefik.http.routers.app.middlewares=auth@docker"

Rate Limiting

Protect your services with rate limiting:

labels:
  - "traefik.http.middlewares.ratelimit.ratelimit.average=100"
  - "traefik.http.middlewares.ratelimit.ratelimit.burst=50"

Health Checks

Configure health checks for your services:

labels:
   traefik.http.services.app.loadbalancer.healthcheck.path=/health
   traefik.http.services.app.loadbalancer.healthcheck.interval=10s

Security Considerations

When setting up Traefik locally, consider these security best practices:

SSL/TLS Configuration: Always use HTTPS, even locally
Access Control: Secure the Traefik dashboard
Docker Socket: Be cautious with Docker socket mounting
Network Isolation: Use separate networks for different environments

Troubleshooting Common Issues

Certificate Issues

Ensure certificates are properly mounted
Check certificate permissions
Verify domain names match certificates

Network Problems

Confirm Docker network exists
Check host file configurations
Verify port mappings

Service Discovery Issues

Ensure labels are correctly configured
Check Docker network connectivity
Verify service ports

Conclusion

Setting up Traefik locally provides a powerful development environment that mirrors production configurations. This setup allows you to:

Test microservices architecture locally
Develop with HTTPS enabled
Experiment with various Traefik features
Prepare for production deployment

Remember to check Traefik’s official documentation for the latest features and best practices as you build upon this basic setup.

You Don't Need GORM, there is a better alternative

Sourabh Mandal — Tue, 13 May 2025 19:57:22 +0000

If you are still using GORM, Let me tell you there is a better alternative. Over the past few weeks I have been exploring the best way possible to communicate with my database.
So I turned to benchmark results and take the most performant one off the shelf. But the problem was all of them had mixed views. Gorm was winning for how easy it is to bootstrap and supports multiple databases and where as sqlx and sqlc are were some of the popular libraries know for its speed.

Hi, I am software engineer and been working with GoLang for 3 years. If you are still here and Enjoy the art of building and experimenting with Code. Please consider subscribing YouTube Channel.

When building Go applications with PostgreSQL, GORM is often the go-to ORM because of its simplicity and developer-friendly API. However I had fare share of nightmares using ORMs especially with Postgres. This versatile database supports more essential Data-Types that are not natively supported in GORM.

Of course you can implement custom type, but doesnt that defeat the whole purpose of Using GORM for simplicity.

What is the best ORM?

Flexibility over Queries and SQL
Easy Schema Migrations
Safety from SQL Injections

The Inherent problem with every ORMs

Complex unoptimised queries for simple requests
Less flexibility for optimization
Hard to execute rollbacks and transactions

Why SQLc + pgx/v5 + atlas

Less boilerplate
Type safety
Idiomatic Go Code
Easier to understand and maintain

Build Your Own ORM like Legos

Here is what worked for me

📌 What is This Database Stack?

Pgx: A performant PostgreSQL driver and toolkit for Go. Think of it as the standard library database/sql on steroids.

Sqlc: Generates type-safe Go code from your SQL queries at compile time.

Atlas: Modern database schema management tool, similar to Flyway or Liquibase, with clean DSL and migration workflows.

🚀 Benefits Over GORM

1️⃣ Type Safety and Compile-Time Validation

GORM: Relies on runtime reflection. Mistyped column names or queries can slip into production.

sqlc: Parses your SQL and generates Go code with exact struct types. If your query or schema changes, your code won’t compile until fixed. Safer, cleaner, no surprises.

2️⃣ Better Performance

pgx is faster than database/sql+GORM because:
No reflection overhead.
Direct native support for PostgreSQL types.
Optimized connection pooling.
Support for advanced features like COPY, notifications, and batch queries.

Benchmarks consistently show pgx outperforming GORM by 30-50% in high-throughput systems.

3️⃣ Clear, Explicit SQL Control

GORM abstracts away SQL, which is fine until you need complex queries, CTEs, window functions, or JSONB operations.

sqlc lets you write native SQL — as expressive as you need — and still benefit from type-safe Go code generation.

You control the query plan, indices, and joins — not the ORM.

4️⃣ Schema Migrations Done Right with Atlas

GORM Migrations: Rudimentary. Often rely on auto-migrate at runtime (risky in production).

Atlas: DSL or declarative SQL migrations. Tracks schema state, detects diffs, and generates migration scripts safely.

5️⃣ Simpler Debugging and Maintenance

No hidden ORM-generated queries.
You can log, EXPLAIN ANALYZE, or optimize your SQL directly.
Easier for any PostgreSQL DBA or Go dev to audit.

✅ When to Pick GORM Instead

To be fair — GORM still makes sense for:

Quick prototypes.
Small internal tools.
Teams unfamiliar with raw SQL.

But for high-performance systems, analytics-heavy apps, or codebases where correctness and maintainability matter, pgx + sqlc + Atlas is superior.

🎯 Final Thoughts

Go’s superpower is simplicity and performance — and your database layer should reflect that. GORM trades safety and speed for convenience, but tools like pgx, sqlc, and Atlas give you the best of both worlds: developer ergonomics and production reliability.

If you care about type safety, performance, and clean database management in Go, it’s worth making this switch.

Build a File Upload API in Golang

Sourabh Mandal — Sun, 04 May 2025 18:56:20 +0000

Just look around you, we are all surrounded by apps that upload files in one form or another - Facebook, Gmail, Github and even the videos I have uploaded on YouTube is an implementation of some file upload API.

In fact, I can confidently say that File Upload is Second most implemented feature after the login Page. Still, its hardly the case that many of us can implement this, the right way. So lets fix that.

File Uploaded with Local Storage

Lets start with a basic implementation. Trust me its so simple, like a kindergarten syllabus.

Here we create an API Handler which takes in a file (multipart/form-data) from request, processes the file and save it in the server codebase.

The above example works, but the problem is, it just works.

Let’s take it to the NEXT LEVEL and make this API a bit more resilient to client request. Well If you code this example, You my friend will soon be HACKED!!! And this is something not many teach you not even ChatGPT.

This code is more insecure than hard-coded secrets in GitHub repository.

Think about it -

What if I send text data instead of a file?
What if the file I am sending, is more than 50 GB?
What if I upload a PDF file when the server is expecting an image file?

Let’s go by an example, suppose you are building user profile picture API. Almost every app has this API be it Github, YouTube, Facebook, Instagram, you name it. Here in this series, we will build a similar API.

How to Improve this API?

Check the header Content-Type has multipart/form-data
Set maximum and minimum limits for file size to be uploaded
Properly sanitise the filename before saving
Avoid file name clashes, with unique file names

First we improve the mime type detector, well what’s wrong with MIME detector. Even though, it works fine we can add some simple optimisation using Maps for O(1) lookups

Next We will tackle checking the header section. We are checking the request header (Content-Type) then the file header for relevant information.

Since our profile picture API only needs to upload images, we check for accepted file-types only

Finally, we improve the file name, by adding a UUID for uniqueness and replace space with underscores.

In the next post we will further improve this API and move towards more scalable, production ready API with S3 Integration.

Full Code on Github for your reference