feat: replace console logging with structured logging infrastructure

[Patrick-Ehimen]

Replace Console Logging with Proper Logging Infrastructure

📋 Summary

Replaces all console.log/warn/error statements with a structured logging infrastructure using consola to improve debugging, monitoring, and production readiness.

🐛 Problem

The codebase was using basic console statements in production code, which creates several issues:

• No log levels: Unable to control what gets logged in different environments
• No structured logging: Difficult to parse and analyze logs programmatically
• No request tracing: Cannot track requests through the system for debugging
• Production noise: Console logs in production are unprofessional and noisy
• No centralized configuration: Each console statement operates independently

Affected Files

• pages/blog.vue line 59: console.error('Blog fetch error:', err)
• server/api/blog.ts lines 53, 75, 79: Multiple console statements

✅ Solution

Implemented a comprehensive structured logging infrastructure with:

• Structured logging with JSON-like format for better parsing
• Environment-based log levels (debug in dev, warn+ in production)
• Request tracing with unique IDs for each API call
• Separate loggers for different contexts (client, API, blog)
• Configurable via environment variables

🔄 Changes Made

Files Added

• utils/logger.ts - Core logging configuration and logger instances
• plugins/logger.client.ts - Client-side logging configuration
• server/middleware/logging.ts - Request tracing middleware
• .env.example - Environment configuration examples

Files Modified

• server/api/blog.ts - Replaced console statements with structured logging
• pages/blog.vue - Added structured client-side error logging
• nuxt.config.ts - Added logging configuration to runtime config

Dependencies Added

• consola ^3.4.2 - Modern logging library with excellent Nuxt.js integration

🧪 Testing

Manual Testing Steps

1. Start dev server: npm run dev
2. Visit /blog: Should see structured logs with request IDs
3. Check browser console: Client-side logs are properly structured
4. Test error scenarios: Temporarily break blog feed URL to verify error logging

Expected Log Output

[api] ℹ Incoming request {
  method: 'GET',
  url: '/blog',
  requestId: 'c604d92b-ed30-4809-b0c0-a5bf7389243e',
  timestamp: '2025-08-18T12:41:08.094Z'
}

[blog] ⚠ Blog feed issue, returning empty data {
  error: 'fetch failed',
  requestId: 'c604d92b-ed30-4809-b0c0-a5bf7389243e',
  feedUrl: 'https://medium.com/feed/@storacha'
}

📸 Before/After

Before

console.error('Blog fetch error:', err)
console.warn('Failed to process blog post:', post.title, error)

After

blogLogger.error('Failed to get blog posts', {
  error: e.message || String(e),
  stack: e.stack,
  requestId,
  feedUrl: config.public.blogFeedUrl
})

clientLogger.error('Blog fetch error', {
  error: err instanceof Error ? err.message : String(err),
  stack: err instanceof Error ? err.stack : undefined,
  timestamp: new Date().toISOString()
})

⚙️ Configuration

Environment Variables

# Server-side log level: debug, info, warn, error
NUXT_LOG_LEVEL=debug

# Client-side log level: debug, info, warn, error
NUXT_PUBLIC_LOG_LEVEL=info

Production vs Development

• Development: Shows all log levels (debug+) for comprehensive debugging
• Production: Only shows warnings and errors to reduce noise

🚀 Benefits

• 🔍 Better debugging with request tracing and structured data
• 📊 Log analysis ready for tools like ELK stack or similar
• 🚀 Production ready with appropriate log levels
• 🛠️ Maintainable with centralized logging configuration
• 📈 Performance monitoring with request duration tracking

💥 Breaking Changes

None - this is purely an internal improvement that doesn't affect the public API.

📝 Checklist

• Code follows project style guidelines
• Self-review completed
• Comments added for complex logic
• Tests pass locally
• No breaking changes introduced
• Documentation updated (if needed)

🔗 Related Issues

Closes #189