About Us

[{"_1":2,"_129":-5,"_130":-5},"loaderData",{"_3":4},"routes/editions.$slug",{"_5":6,"_28":29},"edition",{"_7":8,"_9":10,"_11":12,"_13":14,"_15":16,"_17":18,"_19":20,"_24":25,"_26":27},"number",12,"title","The Future of React: Server Components Deep Dive","description","Exploring React Server Components, streaming, and the future of React development. Plus tips on optimizing your React apps.","date","2025-07-20","slug","future-of-react","readingTime","8 min","topics",[21,22,23],"React","Server Components","Performance","published",true,"content","\n# The Future of React: Server Components Deep Dive\n\nWelcome to edition #12 of the newsletter! This week, we're diving deep into React Server Components and what they mean for the future of React development.\n\n## What Are Server Components?\n\nReact Server Components (RSC) represent a paradigm shift in how we think about React applications. Unlike traditional components that run on the client, Server Components execute on the server and stream their output to the client.\n\n### Key Benefits\n\n1. **Zero Bundle Size Impact** - Server Components don't ship JavaScript to the client\n2. **Direct Backend Access** - Access databases and APIs directly without creating endpoints\n3. **Automatic Code Splitting** - Better performance out of the box\n4. **Streaming** - Send content to users as it becomes ready\n\n## How They Work\n\n```jsx\n// app/PostList.server.jsx\nimport { db } from './db';\n\nexport default async function PostList() {\n const posts = await db.posts.findMany();\n \n return (\n

\n {posts.map(post => (\n \n ))}\n

\n );\n}\n```\n\nThis component runs entirely on the server. No database code is sent to the client!\n\n## Streaming and Suspense\n\nOne of the most powerful features is the ability to stream content:\n\n```jsx\nimport { Suspense } from 'react';\n\nexport default function Page() {\n return (\n

\n }>\n \n \n

\n );\n}\n```\n\nThe header and footer render immediately, while the post list streams in when ready.\n\n## Best Practices\n\n### 1. Use Server Components by Default\n\nStart with Server Components and only reach for Client Components when you need interactivity.\n\n### 2. Minimize Client Boundaries\n\nKeep the `\"use client\"` directive as close to the interactive leaves of your component tree as possible.\n\n### 3. Optimize Data Fetching\n\nFetch data where it's needed, not at the root of your application.\n\n```jsx\n// ✅ Good - fetch where needed\nasync function UserProfile({ userId }) {\n const user = await getUser(userId);\n return

{user.name}

;\n}\n\n// ❌ Bad - fetching at root and prop drilling\nfunction App() {\n const users = await getAllUsers();\n return ;\n}\n```\n\n## Performance Optimization Tips\n\n### Parallel Data Fetching\n\nServer Components enable parallel fetching at different levels:\n\n```jsx\nasync function Dashboard() {\n // These fetch in parallel!\n const userPromise = getUser();\n const postsPromise = getPosts();\n const statsPromise = getStats();\n \n const [user, posts, stats] = await Promise.all([\n userPromise,\n postsPromise,\n statsPromise\n ]);\n \n return (\n

\n \n \n \n

\n );\n}\n```\n\n### Smart Caching\n\nUse React's cache function for request-level memoization:\n\n```jsx\nimport { cache } from 'react';\n\nconst getUser = cache(async (id) => {\n return await db.user.findUnique({ where: { id } });\n});\n```\n\n## Real-World Use Cases\n\n### 1. Data-Heavy Dashboards\n\nPerfect for admin panels and dashboards that display lots of data without much interactivity.\n\n### 2. Content-Heavy Sites\n\nBlogs, documentation sites, and marketing pages benefit from the reduced bundle size.\n\n### 3. E-commerce Product Pages\n\nShow product details fast, with interactive elements only where needed.\n\n## Common Pitfalls to Avoid\n\n### Don't Mix Concerns\n\n```jsx\n// ❌ Bad - mixing server and client concerns\nasync function Component() {\n const data = await fetchData();\n const [state, setState] = useState(); // Error! Can't use hooks\n return

...

;\n}\n```\n\n### Remember the Boundary\n\nClient Components can't import Server Components directly. Use composition:\n\n```jsx\n// ✅ Good\nfunction Layout({ children }) {\n return (\n \n {children} // Server Component passed as children\n \n );\n}\n```\n\n## Migration Strategy\n\nIf you're migrating an existing app:\n\n1. **Start at the leaves** - Convert non-interactive components first\n2. **Work up the tree** - Gradually move more components to the server\n3. **Measure performance** - Track bundle size and performance metrics\n4. **Iterate** - Don't try to convert everything at once\n\n## Looking Ahead\n\nServer Components are just the beginning. The React team is working on:\n\n- **Server Actions** - Mutations that run on the server\n- **Improved streaming** - Better progressive enhancement\n- **Better DevEx** - Tools to visualize the client/server boundary\n\n## Resources\n\n- [React Server Components RFC](https://github.com/reactjs/rfcs)\n- [Next.js App Router Docs](https://nextjs.org/docs)\n- [Patterns for Server Components](https://patterns.dev)\n\n## This Week's Challenge\n\nTry converting a data-fetching component in your app to a Server Component. Measure the bundle size difference!\n\n---\n\nThat's it for this edition! Next week, we'll explore Server Actions and how they simplify form handling and mutations.\n\nHave questions or feedback? Just hit reply!\n\nStay curious, \nlwh\n","allEditions",[30,31,43,55,66,77,88,98,109,119],{"_7":8,"_9":10,"_11":12,"_13":14,"_15":16,"_17":18,"_19":20,"_24":25,"_26":27},{"_7":32,"_9":33,"_11":34,"_13":35,"_15":36,"_17":37,"_19":38,"_24":25,"_26":42},11,"TypeScript 5.5: What's New and Why It Matters","Breaking down the latest TypeScript features, performance improvements, and how they impact your daily development workflow.","2025-07-13","typescript-5-5","7 min",[39,40,41],"TypeScript","JavaScript","Developer Tools","\n# TypeScript 5.5: What's New and Why It Matters\n\nEdition #11 is all about TypeScript! Let's explore the latest features in TypeScript 5.5 and how they can improve your development workflow.\n\n## Type Predicate Inference\n\nOne of the biggest additions is improved type predicate inference. The compiler can now automatically infer type predicates in many cases:\n\n```typescript\n// Before: Manual type predicate\nfunction isString(value: unknown): value is string {\n return typeof value === 'string';\n}\n\n// After: Automatic inference!\nfunction isString(value: unknown) {\n return typeof value === 'string';\n // TypeScript infers: value is string\n}\n```\n\nThis makes your code cleaner and reduces boilerplate!\n\n## Const Type Parameters\n\nYou can now mark type parameters as `const` to infer the most specific type:\n\n```typescript\nfunction makeArray(arr: T[]) {\n return arr;\n}\n\nconst arr = makeArray([1, 2, 3]);\n// Type: readonly [1, 2, 3] (not number[])\n```\n\nThis is incredibly useful for creating type-safe configurations and constants.\n\n## Performance Improvements\n\nTypeScript 5.5 includes significant performance improvements:\n\n- **30% faster** on large codebases\n- **Reduced memory usage** for complex types\n- **Faster incremental builds**\n\n### Real-World Impact\n\nOn our production codebase:\n- Build time: 45s → 28s\n- Memory usage: 2.8GB → 1.9GB\n- IDE responsiveness: Noticeably snappier\n\n## Regular Expression Syntax Checking\n\nNew feature: TypeScript now checks regex syntax!\n\n```typescript\nconst regex1 = /[abc/; // Error: Unterminated character class\nconst regex2 = /(?test)/; // ✅ Valid named capture group\n```\n\nThis catches bugs at compile time instead of runtime.\n\n## Control Flow Narrowing Improvements\n\nBetter narrowing in more scenarios:\n\n```typescript\ntype Result = { success: true; data: T } | { success: false; error: string };\n\nfunction processResult(result: Result) {\n if (result.success) {\n console.log(result.data); // ✅ TypeScript knows data exists\n } else {\n console.log(result.error); // ✅ TypeScript knows error exists\n }\n}\n```\n\n## Practical Tips\n\n### 1. Update Your tsconfig.json\n\n```json\n{\n \"compilerOptions\": {\n \"target\": \"ES2022\",\n \"lib\": [\"ES2022\", \"DOM\"],\n \"module\": \"NodeNext\",\n \"moduleResolution\": \"NodeNext\",\n \"strict\": true,\n \"skipLibCheck\": true\n }\n}\n```\n\n### 2. Use Const Type Parameters for Config\n\n```typescript\nconst config = createConfig({\n api: {\n endpoint: \"https://api.example.com\",\n timeout: 5000,\n },\n} as const);\n\n// TypeScript knows exact values!\n```\n\n### 3. Leverage Type Predicate Inference\n\nRemove manual type predicates where possible. Let TypeScript do the work!\n\n## Migration Guide\n\n1. **Update TypeScript**: `npm install typescript@5.5`\n2. **Fix any new errors** (stricter checking may find bugs!)\n3. **Remove manual type predicates** where inference works\n4. **Benchmark performance** improvements\n\n## What's Next?\n\nThe TypeScript team is working on:\n- **Isolated declarations** for faster builds\n- **Better error messages** with suggestions\n- **Improved JSDoc support**\n\nThat's all for this edition. Happy typing!\n\nlwh\n",{"_7":44,"_9":45,"_11":46,"_13":47,"_15":48,"_17":49,"_19":50,"_24":25,"_26":54},10,"Building Scalable APIs: Lessons from Production","Real-world strategies for building APIs that scale. From rate limiting to caching, and everything in between.","2025-07-06","scalable-apis","10 min",[51,52,53],"API Design","Backend","Scalability","\n# Building Scalable APIs: Lessons from Production\n\nEdition #10! Today we're covering battle-tested strategies for building APIs that can handle scale.\n\n## The Foundation: Good Design\n\nBefore optimization, focus on solid API design:\n\n### RESTful Principles\n\n```\nGET /api/posts - List posts\nGET /api/posts/:id - Get single post\nPOST /api/posts - Create post\nPUT /api/posts/:id - Update post\nDELETE /api/posts/:id - Delete post\n```\n\n### Versioning\n\nAlways version your APIs:\n\n```\n/api/v1/posts\n/api/v2/posts\n```\n\n## Rate Limiting\n\nProtect your API from abuse:\n\n```javascript\nimport rateLimit from 'express-rate-limit';\n\nconst limiter = rateLimit({\n windowMs: 15 * 60 * 1000, // 15 minutes\n max: 100, // Limit each IP to 100 requests per windowMs\n message: 'Too many requests, please try again later.',\n});\n\napp.use('/api/', limiter);\n```\n\n### Tiered Rate Limits\n\nDifferent limits for different user tiers:\n\n```javascript\nconst limits = {\n free: { max: 100, windowMs: 15 * 60 * 1000 },\n pro: { max: 1000, windowMs: 15 * 60 * 1000 },\n enterprise: { max: 10000, windowMs: 15 * 60 * 1000 },\n};\n```\n\n## Caching Strategies\n\nCache at multiple levels:\n\n### 1. Application-Level Caching\n\n```javascript\nimport NodeCache from 'node-cache';\nconst cache = new NodeCache({ stdTTL: 600 });\n\nasync function getPosts() {\n const cached = cache.get('posts');\n if (cached) return cached;\n \n const posts = await db.posts.findMany();\n cache.set('posts', posts);\n return posts;\n}\n```\n\n### 2. HTTP Caching\n\nUse proper cache headers:\n\n```javascript\napp.get('/api/posts', (req, res) => {\n res.set({\n 'Cache-Control': 'public, max-age=300', // 5 minutes\n 'ETag': generateETag(data),\n });\n res.json(data);\n});\n```\n\n### 3. CDN Caching\n\nFor static or infrequently changing data, use a CDN.\n\n## Database Optimization\n\n### Indexing\n\nIndex frequently queried fields:\n\n```sql\nCREATE INDEX idx_posts_user_id ON posts(user_id);\nCREATE INDEX idx_posts_created_at ON posts(created_at DESC);\n```\n\n### Query Optimization\n\n```javascript\n// ❌ Bad - N+1 queries\nconst posts = await db.posts.findMany();\nfor (const post of posts) {\n post.author = await db.users.findUnique({ where: { id: post.userId } });\n}\n\n// ✅ Good - Single query with join\nconst posts = await db.posts.findMany({\n include: { author: true }\n});\n```\n\n## Pagination\n\nAlways paginate large datasets:\n\n```javascript\napp.get('/api/posts', async (req, res) => {\n const page = parseInt(req.query.page) || 1;\n const limit = parseInt(req.query.limit) || 20;\n const skip = (page - 1) * limit;\n\n const [posts, total] = await Promise.all([\n db.posts.findMany({ skip, take: limit }),\n db.posts.count(),\n ]);\n\n res.json({\n data: posts,\n pagination: {\n page,\n limit,\n total,\n totalPages: Math.ceil(total / limit),\n },\n });\n});\n```\n\n## Error Handling\n\nConsistent error responses:\n\n```javascript\nclass APIError extends Error {\n constructor(statusCode, message, details = {}) {\n super(message);\n this.statusCode = statusCode;\n this.details = details;\n }\n}\n\napp.use((err, req, res, next) => {\n if (err instanceof APIError) {\n return res.status(err.statusCode).json({\n error: {\n message: err.message,\n details: err.details,\n },\n });\n }\n \n // Unexpected errors\n console.error(err);\n res.status(500).json({\n error: { message: 'Internal server error' },\n });\n});\n```\n\n## Monitoring and Observability\n\nTrack key metrics:\n\n```javascript\nimport prometheus from 'prom-client';\n\nconst httpRequestDuration = new prometheus.Histogram({\n name: 'http_request_duration_seconds',\n help: 'Duration of HTTP requests in seconds',\n labelNames: ['method', 'route', 'status'],\n});\n\napp.use((req, res, next) => {\n const start = Date.now();\n res.on('finish', () => {\n const duration = (Date.now() - start) / 1000;\n httpRequestDuration.labels(req.method, req.route.path, res.statusCode).observe(duration);\n });\n next();\n});\n```\n\n## Real-World Checklist\n\n- [ ] API versioning implemented\n- [ ] Rate limiting configured\n- [ ] Caching strategy in place\n- [ ] Database queries optimized\n- [ ] Pagination for list endpoints\n- [ ] Consistent error handling\n- [ ] Monitoring and logging\n- [ ] Documentation (OpenAPI/Swagger)\n- [ ] Load testing performed\n- [ ] Security headers configured\n\n## Conclusion\n\nBuilding scalable APIs is about making smart decisions early and continuously optimizing based on real usage patterns.\n\nNext week: Web Performance in 2025!\n\nlwh\n",{"_7":56,"_9":57,"_11":58,"_13":59,"_15":60,"_17":61,"_19":62,"_24":25,"_26":65},9,"Web Performance in 2025: The Complete Guide","Modern techniques for blazing-fast websites. Core Web Vitals, image optimization, and performance monitoring.","2025-06-29","web-performance-2025","9 min",[23,63,64],"Web Development","Optimization","\n# Web Performance in 2025: The Complete Guide\n\nWelcome to edition #9! Today we're diving into everything you need to know about web performance in 2025.\n\n## Core Web Vitals\n\nGoogle's Core Web Vitals are the foundation of modern web performance:\n\n### Largest Contentful Paint (LCP)\n\nMeasures loading performance. Should occur within 2.5 seconds.\n\n```javascript\n// Optimize LCP with preloading\n\n```\n\n### First Input Delay (FID)\n\nMeasures interactivity. Should be less than 100ms.\n\n```javascript\n// Use code splitting to reduce main thread work\nconst HeavyComponent = lazy(() => import('./HeavyComponent'));\n```\n\n### Cumulative Layout Shift (CLS)\n\nMeasures visual stability. Should be less than 0.1.\n\n```css\n/* Always specify dimensions for images */\nimg {\n width: 100%;\n height: auto;\n aspect-ratio: 16 / 9;\n}\n```\n\n## Image Optimization\n\nImages are often the biggest bottleneck:\n\n### Modern Formats\n\n```html\n

\n```\n\n### Lazy Loading\n\n```html\n $\"Description\"$ \n```\n\n### Responsive Images\n\n```html\n\n```\n\n## JavaScript Optimization\n\n### Code Splitting\n\n```javascript\n// Route-based splitting\nconst Home = lazy(() => import('./routes/Home'));\nconst About = lazy(() => import('./routes/About'));\n\nfunction App() {\n return (\n }>\n \n } />\n } />\n \n \n );\n}\n```\n\n### Tree Shaking\n\nEnsure your bundler can eliminate dead code:\n\n```javascript\n// ✅ Good - Named imports enable tree shaking\nimport { Button } from 'ui-library';\n\n// ❌ Bad - Default imports include everything\nimport UILibrary from 'ui-library';\n```\n\n## Caching Strategies\n\n### Service Workers\n\n```javascript\nself.addEventListener('fetch', (event) => {\n event.respondWith(\n caches.match(event.request).then((response) => {\n return response || fetch(event.request);\n })\n );\n});\n```\n\n### HTTP Caching\n\n```javascript\n// Set cache headers\nres.setHeader('Cache-Control', 'public, max-age=31536000, immutable');\n```\n\n## Performance Monitoring\n\n### Real User Monitoring (RUM)\n\n```javascript\nimport { onCLS, onFID, onLCP } from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\n### Performance API\n\n```javascript\nconst perfData = performance.getEntriesByType('navigation')[0];\nconsole.log('DOM Content Loaded:', perfData.domContentLoadedEventEnd);\nconsole.log('Load Complete:', perfData.loadEventEnd);\n```\n\n## Font Optimization\n\n### Font Display Strategy\n\n```css\n@font-face {\n font-family: 'CustomFont';\n src: url('/fonts/custom.woff2') format('woff2');\n font-display: swap; /* Show fallback first */\n}\n```\n\n### Variable Fonts\n\nUse variable fonts to reduce file count:\n\n```css\n@font-face {\n font-family: 'Inter';\n src: url('/fonts/Inter-Variable.woff2') format('woff2');\n font-weight: 100 900;\n}\n```\n\n## Critical CSS\n\nExtract and inline critical CSS:\n\n```html\n\n\n```\n\n## Resource Hints\n\n### Preconnect\n\n```html\n\n```\n\n### DNS Prefetch\n\n```html\n\n```\n\n### Prefetch\n\n```html\n\n```\n\n## Performance Budget\n\nSet and enforce performance budgets:\n\n```javascript\n// webpack.config.js\nmodule.exports = {\n performance: {\n maxAssetSize: 244000,\n maxEntrypointSize: 244000,\n hints: 'error'\n }\n};\n```\n\n## Testing Tools\n\n- **Lighthouse** - Automated audits\n- **WebPageTest** - Detailed performance analysis\n- **Chrome DevTools** - Real-time debugging\n- **Bundle Analyzer** - Visualize bundle size\n\n## Quick Wins Checklist\n\n- [ ] Enable compression (gzip/brotli)\n- [ ] Minify CSS, JS, and HTML\n- [ ] Optimize and compress images\n- [ ] Implement lazy loading\n- [ ] Use a CDN\n- [ ] Enable HTTP/2 or HTTP/3\n- [ ] Reduce third-party scripts\n- [ ] Implement caching strategies\n- [ ] Use modern image formats\n- [ ] Minimize main thread work\n\n## Conclusion\n\nPerformance is not a one-time task—it's an ongoing commitment. Monitor, measure, and iterate!\n\nNext week: Docker for developers!\n\nlwh\n",{"_7":67,"_9":68,"_11":69,"_13":70,"_15":71,"_17":61,"_19":72,"_24":25,"_26":76},8,"Docker for Developers: Beyond the Basics","Advanced Docker patterns, multi-stage builds, and production-ready containerization strategies.","2025-06-22","docker-advanced",[73,74,75],"Docker","DevOps","Containers","\n# Docker for Developers: Beyond the Basics\n\nEdition #8 takes you beyond Docker basics into advanced patterns and production strategies.\n\n## Multi-Stage Builds\n\nReduce image size dramatically:\n\n```dockerfile\n# Build stage\nFROM node:20-alpine AS builder\nWORKDIR /app\nCOPY package*.json ./\nRUN npm ci\nCOPY . .\nRUN npm run build\n\n# Production stage\nFROM node:20-alpine\nWORKDIR /app\nCOPY --from=builder /app/dist ./dist\nCOPY --from=builder /app/node_modules ./node_modules\nCOPY package*.json ./\nEXPOSE 3000\nCMD [\"node\", \"dist/index.js\"]\n```\n\nThis pattern keeps your production image small and secure.\n\n## Docker Compose for Development\n\n```yaml\nversion: '3.8'\nservices:\n app:\n build: .\n ports:\n - \"3000:3000\"\n volumes:\n - .:/app\n - /app/node_modules\n environment:\n - DATABASE_URL=postgresql://postgres:password@db:5432/myapp\n depends_on:\n - db\n \n db:\n image: postgres:15-alpine\n environment:\n - POSTGRES_PASSWORD=password\n - POSTGRES_DB=myapp\n volumes:\n - postgres_data:/var/lib/postgresql/data\n\nvolumes:\n postgres_data:\n```\n\n## Build Optimization\n\n### Layer Caching\n\nOrder matters! Put changing files last:\n\n```dockerfile\n# ✅ Good - dependencies cached separately\nCOPY package*.json ./\nRUN npm ci\nCOPY . .\n\n# ❌ Bad - cache invalidated on any file change\nCOPY . .\nRUN npm ci\n```\n\n### .dockerignore\n\nExclude unnecessary files:\n\n```\nnode_modules\nnpm-debug.log\n.git\n.env\ndist\ncoverage\n```\n\n## Health Checks\n\n```dockerfile\nHEALTHCHECK --interval=30s --timeout=3s --start-period=5s \\\n CMD node healthcheck.js || exit 1\n```\n\n```javascript\n// healthcheck.js\nconst http = require('http');\n\nconst options = {\n host: 'localhost',\n port: 3000,\n path: '/health',\n timeout: 2000\n};\n\nhttp.get(options, (res) => {\n if (res.statusCode === 200) {\n process.exit(0);\n } else {\n process.exit(1);\n }\n}).on('error', () => {\n process.exit(1);\n});\n```\n\n## Security Best Practices\n\n### Non-Root User\n\n```dockerfile\nFROM node:20-alpine\nRUN addgroup -g 1001 -S nodejs\nRUN adduser -S nodejs -u 1001\nUSER nodejs\n```\n\n### Scan for Vulnerabilities\n\n```bash\ndocker scan myapp:latest\n```\n\n### Minimal Base Images\n\n```dockerfile\n# Use Alpine for smaller attack surface\nFROM node:20-alpine\n\n# Or use distroless\nFROM gcr.io/distroless/nodejs20-debian11\n```\n\n## Development vs Production\n\n### Development Dockerfile\n\n```dockerfile\nFROM node:20\nWORKDIR /app\nCOPY package*.json ./\nRUN npm install\nCOPY . .\nCMD [\"npm\", \"run\", \"dev\"]\n```\n\n### Production Dockerfile\n\n```dockerfile\nFROM node:20-alpine AS builder\nWORKDIR /app\nCOPY package*.json ./\nRUN npm ci --only=production\nCOPY . .\nRUN npm run build\n\nFROM node:20-alpine\nWORKDIR /app\nCOPY --from=builder /app/dist ./dist\nCOPY --from=builder /app/node_modules ./node_modules\nUSER node\nCMD [\"node\", \"dist/index.js\"]\n```\n\n## Volume Management\n\n### Named Volumes\n\n```bash\ndocker volume create app_data\ndocker run -v app_data:/data myapp\n```\n\n### Bind Mounts for Development\n\n```bash\ndocker run -v $(pwd):/app myapp\n```\n\n## Networking\n\n### Custom Networks\n\n```bash\ndocker network create app_network\ndocker run --network app_network --name db postgres\ndocker run --network app_network --name api myapp\n```\n\n## Docker BuildKit\n\nEnable for better performance:\n\n```bash\nexport DOCKER_BUILDKIT=1\ndocker build .\n```\n\n### Build Secrets\n\n```dockerfile\n# syntax=docker/dockerfile:1\nFROM node:20-alpine\nRUN --mount=type=secret,id=npm_token \\\n echo \"//registry.npmjs.org/:_authToken=$(cat /run/secrets/npm_token)\" > .npmrc && \\\n npm ci && \\\n rm .npmrc\n```\n\n```bash\ndocker build --secret id=npm_token,src=.npm_token .\n```\n\n## Logging\n\n### JSON Logging\n\n```javascript\nconst logger = {\n info: (msg, meta = {}) => console.log(JSON.stringify({ level: 'info', msg, ...meta })),\n error: (msg, meta = {}) => console.error(JSON.stringify({ level: 'error', msg, ...meta }))\n};\n```\n\n### Log Driver Configuration\n\n```yaml\nservices:\n app:\n logging:\n driver: json-file\n options:\n max-size: \"10m\"\n max-file: \"3\"\n```\n\n## Resource Limits\n\n```yaml\nservices:\n app:\n deploy:\n resources:\n limits:\n cpus: '0.5'\n memory: 512M\n reservations:\n memory: 256M\n```\n\n## Common Pitfalls\n\n1. **Large image sizes** - Use multi-stage builds\n2. **Running as root** - Always use non-root users\n3. **Outdated base images** - Regularly update\n4. **Exposed secrets** - Never commit secrets\n5. **No health checks** - Always implement health checks\n\n## Production Checklist\n\n- [ ] Multi-stage builds implemented\n- [ ] Running as non-root user\n- [ ] Health checks configured\n- [ ] Logs going to stdout/stderr\n- [ ] Resource limits set\n- [ ] Security scanning automated\n- [ ] .dockerignore optimized\n- [ ] Environment variables externalized\n- [ ] Secrets management in place\n- [ ] Monitoring and alerting configured\n\n## Conclusion\n\nDocker is powerful, but with power comes responsibility. Follow these patterns for reliable, secure containers!\n\nNext week: Git workflows that actually work!\n\nlwh\n",{"_7":78,"_9":79,"_11":80,"_13":81,"_15":82,"_17":18,"_19":83,"_24":25,"_26":87},7,"Git Workflows That Actually Work in Teams","Practical Git strategies for team collaboration. From branching models to commit conventions.","2025-06-15","git-workflows",[84,85,86],"Git","Version Control","Team Collaboration","\n# Git Workflows That Actually Work in Teams\n\nEdition #7 covers practical Git workflows for effective team collaboration.\n\n## Branching Strategies\n\n### Git Flow\n\nTraditional but effective for release-based workflows:\n\n```bash\n# Main branches\nmain (production)\ndevelop (integration)\n\n# Supporting branches\nfeature/* (new features)\nrelease/* (release preparation)\nhotfix/* (production fixes)\n```\n\n### GitHub Flow\n\nSimpler, great for continuous deployment:\n\n```bash\nmain (always deployable)\nfeature/* (short-lived feature branches)\n```\n\n### Trunk-Based Development\n\nFor high-velocity teams:\n\n```bash\n# Everyone commits to main\nmain\n\n# Use feature flags for incomplete features\nif (featureFlags.newDesign) {\n return ;\n}\n```\n\n## Commit Conventions\n\n### Conventional Commits\n\n```bash\n(): \n\n\n\n