BINARY_SIZE.md

Binary Size Comparison

This document compares the application size and dependencies between the initial implementation (main branch) and the refactored clean architecture (task-session-2 branch).

Main Branch (Initial Implementation)

Binary Size:

$ du -sh kasir-api
7.9M    kasir-api

Dependencies:

module kasir-api

go 1.25.6

Characteristics:

• Zero external dependencies
• Pure standard library implementation
• Monolithic structure (single file)
• Smaller binary size

Task-Session-2 Branch (Clean Architecture)

Binary Size:

$ du -sh bin/kasir-api
15M     bin/kasir-api

Dependencies:

module kasir-api

go 1.25.6

require (
	github.com/jackc/pgx/v5 v5.8.0
	github.com/knadh/koanf/parsers/dotenv v1.1.1
	github.com/knadh/koanf/providers/env/v2 v2.0.0
	github.com/knadh/koanf/providers/file v1.2.1
	github.com/knadh/koanf/v2 v2.3.2
	github.com/pressly/goose/v3 v3.26.0
)

require (
	// ... 17 indirect dependencies
)

Dependency Stats:

• go.mod: 32 lines
• go.sum: 77 lines
• Total: 109 lines

Characteristics:

• 6 direct dependencies
• 17 indirect dependencies
• Layered architecture (domain, repository, service, handler)
• PostgreSQL support with connection pooling
• Configuration management (.env support)
• Database migrations with goose
• Larger binary size due to additional features

Size Increase Analysis

Metric	Main	Task-Session-2	Increase
Binary Size	7.9M	15M	+7.1M (90%)
Direct Dependencies	0	6	+6
Total Dependencies	0	23	+23

What Adds to Binary Size?

1. pgx/v5 (PostgreSQL driver) - ~4-5M

   • Full-featured PostgreSQL driver
   • Connection pooling
   • Prepared statements support

2. koanf (Configuration) - ~1-2M

   • Environment variable parsing
   • .env file support
   • Multiple providers

3. goose (Migrations) - ~1-2M

   • Migration management
   • Up/Down migration support
   • Version tracking

Trade-offs

Main Branch Advantages

✅ Smaller binary (7.9M) ✅ Zero dependencies ✅ Faster compilation ✅ Simpler deployment

Task-Session-2 Advantages

✅ Clean architecture (maintainable) ✅ SOLID principles ✅ PostgreSQL support ✅ Database migrations ✅ Configuration management ✅ Testable design ✅ Production-ready features

Optimization Options

If binary size is critical, you can:

1. Build with compression:

   go build -ldflags="-s -w" -o bin/kasir-api ./cmd/api/
   upx --best --lzma bin/kasir-api

   Expected size: ~5-6M (60% reduction)

2. Remove unused features:

   • Use in-memory only (remove pgx)
   • Use environment variables only (remove koanf)
   • Manual migrations (remove goose)

3. Use standard library alternatives:

   • database/sql with lib/pq (smaller than pgx)
   • os.Getenv() instead of koanf
   • Custom migration runner

Conclusion

The 90% size increase (7.9M → 15M) is justified by:

• Production-ready database support
• Professional configuration management
• Automated migration system
• Clean, maintainable architecture
• Comprehensive test coverage

For production applications, the additional 7.1M is a worthwhile trade-off for maintainability, testability, and feature completeness.