DEV Community: Ray Ch

Why I Chose the 14" MacBook Pro M5 Pro — A Developer's Buying Guide

Ray Ch — Sat, 04 Apr 2026 04:58:28 +0000

As an engineering manager doing full-stack development with Docker Compose, Flutter, and mobile apps, I went through five different MacBook Pro configurations before finding the right one. Here's what I learned about what actually matters for developer workflows — and where most people overspend.

The Problem: 500GB Storage and 16GB RAM Was Killing Me

My daily driver was a 14-inch MacBook Pro (2023) with an M2 Pro and 16GB RAM. The chip itself was fine — still fast, still capable. But 16GB of unified memory was becoming a serious bottleneck. Every 4 days I am out of storage.

My typical workday looks like this: 3-4 Docker containers running via Docker Compose (database, backend, cache, sometimes a frontend dev server), Android Studio or Xcode open for Flutter development, VS Code as my main editor, a browser with a dozen tabs, plus Slack and other tools. That easily pushes past 20GB of memory demand.

When macOS runs out of physical RAM, it swaps to disk. Even with a fast SSD, swap means everything stutters — switching apps takes a beat, builds slow down, and the entire system feels sluggish. The CPU wasn't the bottleneck. RAM was.

The Priority Framework

The most important lesson from this process: for developer workloads, the priority order is clear.

RAM — Critical. Docker containers reserve memory and don't release it until stopped.
CPU — Important. More cores help with parallel builds, but diminishing returns kick in fast.
Storage — Moderate. 1-2TB is the sweet spot. You can supplement with external drives.
GPU — Low priority. Docker, Flutter, and full-stack dev are not GPU workloads.

A faster CPU compiles your Flutter app in 30 seconds instead of 40 seconds. But insufficient RAM means your entire system stutters while you're just switching between apps. One is a minor convenience. The other ruins your flow state constantly.

Five Configs, One Winner

Config 1 — M5 Pro 18-core / 64GB / 4TB ❌ Overkill

RAM and CPU were great, but 4TB SSD was massive overkill for development work. Docker images and Flutter projects don't need that much space. The storage jump from 1TB to 4TB likely added ₹60,000-80,000 for capacity I'd never use.

Config 2 — M5 Pro 15-core / 24GB / 1TB ❌ Too Lean

Only 24GB RAM — a marginal upgrade from 16GB. On a busy day with Docker Compose, an IDE, and a browser, I'd already be hitting 20-27GB. Essentially buying into swap territory again within a year.

Config 3 — M5 Max 18-core / 36GB / 2TB ❌ GPU Overkill

Same 18-core CPU as the M5 Pro but with 32 GPU cores I'd never utilise. Docker, Flutter, and full-stack dev are CPU and RAM workloads — not GPU. I was paying the M5 Max premium for GPU power that would sit idle, while getting less RAM than I actually needed.

Config 4 — M5 Pro 18-core / 48GB / 2TB ⚠️ Almost Perfect

Ideal specs on paper, but this exact configuration wasn't readily available in India without the Nano-texture display upgrade, which added unnecessary cost. The 18-core vs 15-core difference, while nice, wasn't worth the premium or the hassle of finding it.

Config 5 — M5 Pro 15-core / 48GB / 2TB ✅ The One

The sweet spot. 48GB RAM solves the actual bottleneck. 15-core M5 Pro is still a meaningful upgrade over the M2 Pro's 12 cores. 2TB gives room for Docker images without needing external drives. No money wasted on GPU cores or storage I'll never use.

Understanding CPU Cores: The Highway Analogy

The 15-core and 18-core M5 Pro are physically the same chip. Apple disables some cores on the lower tier. The 15-core has 5 "super cores" (high-power, single-threaded) and 10 performance cores. The 18-core has 6 super cores and 12 performance cores.

Think of cores like lanes on a highway. The 15-core is a 15-lane highway. The 18-core is an 18-lane highway. Both have the same speed limit. On a normal day, you're using maybe 8-10 lanes. You'd only notice the difference during absolute peak traffic — like building multiple Docker images simultaneously while running a CI pipeline locally.

Single-core performance is identical between the two. Day-to-day snappiness — opening apps, Flutter hot reload, running a terminal command — feels the same. The extra 3 cores only matter during sustained parallel workloads.

Why Not the Base M5?

I seriously considered the base M5 chip to save money. But it has one hard limitation: the maximum RAM is 32GB. Only the M5 Pro and above can be configured with 48GB or higher.

32GB would have been workable for 2-3 years. But I wanted a machine that would stay comfortable for 4-5 years. The M5 Pro with 48GB provides that runway.

The Final Build

14" MacBook Pro · M5 Pro · Space Black

Spec	Value
CPU	15-core (5 super + 10 performance)
GPU	16-core
RAM	48GB unified memory
Storage	2TB SSD
Display	Standard
Connectivity	3x Thunderbolt 5, HDMI, SDXC, MagSafe 3
Price	₹3,29,900

Before vs After

	M2 Pro (2023)	M5 Pro (2026)
CPU	12-core	15-core
RAM	16GB	48GB (3x)
Storage	512GB–1TB	2TB
Connectivity	Thunderbolt 4	Thunderbolt 5

Post-Setup Tips

Increase Docker Desktop's memory allocation. By default, Docker is conservative with memory. With 48GB, you can comfortably allocate 16-20GB to Docker and still have plenty for everything else.

Run docker system prune regularly. Old images and stopped containers pile up. A monthly prune keeps the 2TB SSD healthy over the years.

Don't forget AppleCare+. On a machine at this price point, the extended warranty and accidental damage coverage is worth the peace of mind.

The Takeaway

For developer workloads, RAM is the single most important spec. Don't get seduced by core counts or GPU benchmarks that don't map to your actual workflow. Buy the RAM, get a sensible CPU, and stop overthinking the rest.

The Claude Code Leak Just Gave Every Developer a Masterclass in AI Agent Orchestration

Ray Ch — Thu, 02 Apr 2026 06:54:26 +0000

On March 31, 2026, Anthropic accidentally shipped the entire source code of Claude Code — its flagship AI coding agent — inside a routine npm update. No hack. No reverse engineering. A missing .npmignore entry exposed 512,000 lines of unobfuscated TypeScript across roughly 1,900 files. Within hours, the codebase was mirrored, dissected, and rewritten in Python and Rust by thousands of developers worldwide.

But beyond the embarrassment for Anthropic and the security implications, something far more significant happened: the AI development community got its first real look at how a production-grade AI agent actually works at scale. And what they found inside is reshaping how everyone thinks about building agents.

Why This Matters More Than a Typical Source Code Leak

Claude Code isn't just a chatbot with a terminal. It's an agentic harness — a sophisticated orchestration layer that wraps around a large language model and gives it the ability to use tools, manage files, run bash commands, coordinate multiple sub-agents, and maintain coherent context across long work sessions. This harness is where much of Claude Code's real capability lives, and it's the part that leaked.

Before this, the AI agent ecosystem was largely built on guesswork. Developers stitched together patterns from blog posts, conference talks, and open-source experiments. Nobody outside the major labs had a reference implementation for how to build a reliable, commercially viable AI agent. Now everyone does.

The Four Breakthroughs Hidden in the Code

1. Solving Context Entropy

Every developer who has built an AI agent has hit the same wall: the longer a session runs, the more confused the model gets. Anthropic internally calls this "context entropy," and their solution is arguably the most valuable thing in the entire leak.

The codebase reveals a four-stage context management pipeline paired with an auto-compaction system. When a session's context grows unwieldy, the system intelligently compresses it — preserving critical information while discarding noise. One internal metric found in the code noted that over 1,200 sessions had experienced 50 or more consecutive compaction failures before a simple three-line fix capped retries at three attempts, saving roughly 250,000 wasted API calls per day globally.

Sometimes the best engineering is knowing when to stop trying.

2. Tool Orchestration Done Right

The leaked codebase contains complete libraries of slash commands and built-in tools, showing exactly how a production system decides which tool to invoke, validates inputs, and handles failures. The bash execution tool alone reportedly contains around 2,500 lines of security validation — a number that should give pause to anyone shipping an AI agent with a casual subprocess call.

This isn't just about calling functions. It's about building a permission system, a sandboxing approach, and a validation pipeline that can handle adversarial inputs without compromising the host system. These patterns are now the only fully documented production-grade implementation in the industry.

3. Multi-Agent Coordination

Perhaps the most forward-looking piece of the architecture is its multi-agent orchestration system. The code reveals how Claude Code spawns sub-agents — or "swarms" — to handle complex tasks that exceed what a single agent can manage.

The implementation includes a forked sub-agent model where background tasks run in isolated processes, preventing the main agent's reasoning from being corrupted by its own maintenance routines. This is the pattern that every serious agent builder is trying to figure out right now, and until this leak, there was virtually no public reference material for doing it at production quality.

4. Memory That Actually Works

The most futuristic component revealed in the leak is an internal system codenamed "KAIROS" — from the Ancient Greek concept of "the right moment." Referenced over 150 times in the source code, KAIROS represents an autonomous daemon mode where Claude Code continues working while the user is idle.

At its core is a process called autoDream: a memory consolidation routine that merges scattered observations, removes logical contradictions, and converts vague insights into concrete, actionable facts. When the user returns, the agent's context is clean and highly relevant. It's not just persistence — it's self-improvement between interactions.

The Competitive Implications

The leak hands every competitor — from established players to nimble startups — a detailed blueprint for building a production-grade AI coding agent. Clean-room rewrites appeared almost immediately. One Python port hit 50,000 GitHub stars in under two hours, making it likely the fastest-growing repository in GitHub history.

But the real question is whether this changes the competitive landscape in a meaningful way. The answer is nuanced.

The orchestration layer — the harness, the tool system, the context management — is important, but it's ultimately a shell. The models themselves were not leaked. And it's increasingly clear that model capability is the true moat. Google's Gemini CLI and OpenAI's Codex are already open source. Multiple voices in the developer community have argued that Claude Code's CLI should have been open from the start.

What the leak does change is the floor. Before March 31, building a reliable AI agent required significant trial-and-error investment. Now, any developer can study battle-tested architectural patterns and build on them. The gap between the best agents and the rest just narrowed considerably.

What Builders Should Take Away

If you're building AI agents today, the leaked Claude Code architecture offers several concrete lessons worth internalizing.

First, context management is the hardest problem in agent development, and it deserves the most engineering investment. The fact that Anthropic built a four-stage pipeline for it tells you everything about where complexity lives.

Second, security in agentic systems is not an afterthought. Thousands of lines of bash validation exist for a reason. If your agent can execute code, you need a permission model that assumes adversarial input.

Third, multi-agent coordination is the future, but isolation is critical. Running background tasks in forked sub-agents — rather than in the main reasoning loop — is a pattern that prevents subtle corruption of the agent's primary task.

Finally, memory is more than persistence. The autoDream approach of actively consolidating and cleaning context — rather than simply appending to a growing log — is a fundamentally different way to think about agent memory. It's closer to how human memory works: not a tape recorder, but an active process of synthesis and forgetting.

The Bottom Line

The Claude Code leak won't sink Anthropic. Their models remain their moat, and Claude Code's revenue trajectory speaks for itself. But it will accelerate the entire AI agent ecosystem by giving every developer on Earth a reference implementation for what "production-grade" actually looks like.

For the first time, the orchestration layer is no longer a secret. The question now is what everyone builds with it.

How We Solve Integration Issues

Ray Ch — Tue, 03 Mar 2026 18:36:58 +0000

The core problem is always the same: you have multiple systems that need to work together, and bugs only appear at the boundaries. The solution is to build confidence layer by layer, starting from the outermost dependency inward.

The Mental Model

Before writing any backend code, prove the external system works and you understand it. Build the simplest possible script that calls it directly — no framework, no DI, no abstractions. This becomes your ground truth. If you can't call it from 20 lines of code, you can't call it from the backend either.

Only once you understand what the external system actually expects do you start wiring your services to it.

The Four Layers

1. Parity Tests — "Does my abstraction produce the same output as doing it manually?"

Before involving any app infrastructure, test that your service classes produce identical output to doing the thing by hand. If MyBuilder and raw manual construction diverge, you've found a bug in your abstraction. These run in milliseconds with no dependencies.

2. Fast Service Tests — "Do my services work with a real DB but no network?"

Spin up a real database (isolated port, in-memory/tmpfs, wiped and re-seeded each run). Instantiate services directly — no framework DI overhead. Run the full service orchestration pipeline. These should finish in a few seconds, which means you run them on every change. This layer catches config bugs, seed data problems, logic errors, and bad service wiring.

3. Controller/App Tests — "Does the full framework stack work?"

Boot the real app (NestJS, Express, whatever) via its test harness. Hit actual HTTP endpoints. This layer surfaces bugs that only appear with the full stack — things like env variables overriding test config, missing module registrations, middleware interference, or serialization mismatches. You can't find these in service tests.

4. Live Integration — "Does the external system accept what we produce?"

Call the real external service (API, queue, database, third-party). Read back the result — don't just check the status code. Verify that the system's state actually changed the way you expected. This is the final proof.

Why This Order Matters

Each layer has a narrow blast radius. When a parity test fails, you know the bug is in your abstraction, not your DB config or your HTTP routing. When a service test fails, you know it's a logic or config issue, not a framework problem. When a controller test fails, you know the services are fine and the issue is in the wiring.

Debugging a signing bug inside a full app boot cycle is painful. Debugging it in a 20-line script takes 30 seconds.

The Debugging Sequence

When something breaks, walk the layers top-down:

Can you call the external system from a standalone script? If not — it's an API contract problem (wrong format, wrong auth, wrong endpoint).
Does your abstraction produce the same output as doing it manually? If not — it's a bug in your builder/adapter/client.
Do service tests pass with a real DB? If not — it's a config, seed, or orchestration bug.
Does the controller test pass? If not — check env bleed, module registration, middleware, serialization.
Does the external system reflect the expected state after the call? If not — re-read the external system's validation rules. The contract is always right.

The Principles That Don't Change

Start from the external dependency. Understand what it actually expects before building anything around it.
Test abstractions in isolation. Parity checks (your code vs manual) catch the largest class of subtle bugs fastest.
Real dependencies, fast feedback. A real DB with in-memory storage and a seed script gives you production fidelity in seconds.
Full stack tests find glue bugs. Env override, missing registrations, serialization — these only appear with everything wired together.
Verification is not a status code. Read back the actual state from the external system. If the state didn't change correctly, the integration isn't working regardless of what the response said.
Keep test environments isolated. Separate ports, wipe and re-seed between runs. Shared state between test runs is how you get flaky tests that are impossible to debug.

AWS OIDC Setup for CircleCI

Ray Ch — Mon, 19 Jan 2026 09:45:20 +0000

This guide explains how to configure AWS IAM with OIDC (OpenID Connect) for secure CircleCI authentication without storing long-lived credentials.

Overview

Why OIDC?

Access Keys (Old)	OIDC (Recommended)
Long-lived credentials	Temporary tokens (auto-expire)
Stored in CircleCI	No stored secrets
Can be leaked	Nothing to leak
Manual rotation needed	Automatic rotation

Prerequisites

AWS Account with Admin access
CircleCI Organization ID (found in CircleCI → Organization Settings → Overview)
AWS Account ID

Step 1: Create OIDC Identity Provider

AWS Console

Go to IAM → Identity Providers → Add Provider
Fill in:

Field	Value
Provider type	`OpenID Connect`
Provider URL	`https://oidc.circleci.com/org/<CIRCLECI_ORG_ID>`
Audience	`<CIRCLECI_ORG_ID>`

Click Get thumbprint
Click Add provider

AWS CLI

aws iam create-open-id-connect-provider \
  --url "https://oidc.circleci.com/org/<CIRCLECI_ORG_ID>" \
  --client-id-list "<CIRCLECI_ORG_ID>" \
  --thumbprint-list "9e99a48a9960b14926bb7f3b02e22da2b0ab7280"

Step 2: Create IAM Policy

CircleCI-Deployment-Policy

Create this policy in IAM → Policies → Create Policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ECRAuthToken",
            "Effect": "Allow",
            "Action": "ecr:GetAuthorizationToken",
            "Resource": "*"
        },
        {
            "Sid": "ECRPushImages",
            "Effect": "Allow",
            "Action": [
                "ecr:BatchCheckLayerAvailability",
                "ecr:GetDownloadUrlForLayer",
                "ecr:BatchGetImage",
                "ecr:PutImage",
                "ecr:InitiateLayerUpload",
                "ecr:UploadLayerPart",
                "ecr:CompleteLayerUpload"
            ],
            "Resource": "arn:aws:ecr:<REGION>:<ACCOUNT_ID>:repository/<ECR_REPO_NAME>"
        },
        {
            "Sid": "AppRunnerDeploy",
            "Effect": "Allow",
            "Action": [
                "apprunner:StartDeployment",
                "apprunner:DescribeService"
            ],
            "Resource": "arn:aws:apprunner:<REGION>:<ACCOUNT_ID>:service/<SERVICE_NAME>/*"
        },
        {
            "Sid": "AmplifyDeploy",
            "Effect": "Allow",
            "Action": [
                "amplify:StartJob",
                "amplify:GetJob"
            ],
            "Resource": "arn:aws:amplify:<REGION>:<ACCOUNT_ID>:apps/<AMPLIFY_APP_ID>/*"
        }
    ]
}

Note: Replace <REGION>, <ACCOUNT_ID>, <ECR_REPO_NAME>, <SERVICE_NAME>, and <AMPLIFY_APP_ID> with your actual values. For quick setup, you can use "Resource": "*" but this is less secure.

Step 3: Create IAM Role

AWS Console

Go to IAM → Roles → Create Role
Select Web identity as trusted entity type
Select your OIDC provider from the dropdown
Set Audience to your CircleCI Org ID
Click Next
Attach CircleCI-Deployment-Policy
Name the role: CircleCI-OIDC-Role
Click Create role

Trust Policy

After creating the role, update the trust policy for additional security:

IAM → Roles → CircleCI-OIDC-Role → Trust relationships → Edit

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<ACCOUNT_ID>:oidc-provider/oidc.circleci.com/org/<CIRCLECI_ORG_ID>"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.circleci.com/org/<CIRCLECI_ORG_ID>:aud": "<CIRCLECI_ORG_ID>"
        }
      }
    }
  ]
}

Optional: Restrict to Specific Project

Add this condition to limit access to a specific CircleCI project:

"StringLike": {
  "oidc.circleci.com/org/<CIRCLECI_ORG_ID>:sub": "org/<CIRCLECI_ORG_ID>/project/<PROJECT_ID>/user/*"
}

Step 4: Update CircleCI Configuration

Update .circleci/config.yml to use OIDC authentication:

version: 2.1

orbs:
  node: circleci/node@5.2.0
  aws-cli: circleci/aws-cli@4.1.2
  aws-ecr: circleci/aws-ecr@9.0.2

executors:
  node-executor:
    docker:
      - image: cimg/node:20.11
    working_directory: ~/project

jobs:
  push-backend-to-ecr:
    executor: node-executor
    steps:
      - checkout
      - setup_remote_docker:
          version: 20.10.24
      - aws-cli/setup:
          role_arn: ${AWS_ROLE_ARN}
          region: ${AWS_REGION}
      - run:
          name: Build and Push Backend Docker Image
          command: |
            aws ecr get-login-password --region $AWS_REGION | docker login --username AWS --password-stdin $AWS_ECR_REGISTRY
            docker build -t $AWS_ECR_REGISTRY/demo-backend:$CIRCLE_SHA1 -t $AWS_ECR_REGISTRY/demo-backend:latest ./backend
            docker push $AWS_ECR_REGISTRY/demo-backend:$CIRCLE_SHA1
            docker push $AWS_ECR_REGISTRY/demo-backend:latest

  deploy-backend-to-apprunner:
    executor: node-executor
    steps:
      - aws-cli/setup:
          role_arn: ${AWS_ROLE_ARN}
          region: ${AWS_REGION}
      - run:
          name: Trigger App Runner Deployment
          command: |
            aws apprunner start-deployment --service-arn $AWS_APP_RUNNER_SERVICE_ARN

  deploy-frontend-to-amplify:
    executor: node-executor
    steps:
      - checkout
      - aws-cli/setup:
          role_arn: ${AWS_ROLE_ARN}
          region: ${AWS_REGION}
      - run:
          name: Trigger Amplify Deployment
          command: |
            aws amplify start-job --app-id $AWS_AMPLIFY_APP_ID --branch-name main --job-type RELEASE

Step 5: Configure CircleCI Environment Variables

Add These Variables

In CircleCI → Project Settings → Environment Variables:

Variable	Value	Description
`AWS_ROLE_ARN`	`arn:aws:iam::<ACCOUNT_ID>:role/CircleCI-OIDC-Role`	IAM role ARN
`AWS_REGION`	`us-east-1`	AWS region
`AWS_ECR_REGISTRY`	`<ACCOUNT_ID>.dkr.ecr.<REGION>.amazonaws.com`	ECR registry URL
`AWS_APP_RUNNER_SERVICE_ARN`	`arn:aws:apprunner:...`	App Runner service ARN
`AWS_AMPLIFY_APP_ID`	`<APP_ID>`	Amplify app ID

Remove These Variables (After Testing)

Variable	Reason
`AWS_ACCESS_KEY_ID`	No longer needed with OIDC
`AWS_SECRET_ACCESS_KEY`	No longer needed with OIDC

Step 6: Test OIDC Authentication

Add a test job to verify the setup:

jobs:
  test-oidc-auth:
    docker:
      - image: cimg/base:current
    steps:
      - aws-cli/setup:
          role_arn: ${AWS_ROLE_ARN}
          region: ${AWS_REGION}
      - run:
          name: Verify AWS Identity
          command: aws sts get-caller-identity

Expected Output

{
  "UserId": "AROA...:circleci-test-oidc-auth",
  "Account": "<ACCOUNT_ID>",
  "Arn": "arn:aws:sts::<ACCOUNT_ID>:assumed-role/CircleCI-OIDC-Role/circleci-test-oidc-auth"
}

Troubleshooting

Error: "Not authorized to perform sts:AssumeRoleWithWebIdentity"

Verify the OIDC provider URL matches exactly
Check the audience claim matches your CircleCI Org ID
Ensure the trust policy has the correct Principal ARN

Error: "Token is expired"

OIDC tokens are short-lived; ensure the job runs promptly
Check for clock skew issues

Error: "Invalid identity token"

Verify CircleCI Org ID is correct
Check OIDC provider thumbprint

Security Best Practices

Practice	Description
Restrict resources	Use specific ARNs instead of `*` in policies
Limit by project	Add project ID condition to trust policy
Enable CloudTrail	Audit all role assumptions
Separate environments	Use different roles for staging/production
Regular review	Periodically audit IAM policies and roles

Developer Access (Separate from CI/CD)

Developers should have their own IAM users/roles with appropriate permissions. See AWS_DEVELOPER_ACCESS.md for developer IAM setup.

Cost

OIDC authentication is free. No additional AWS charges for:

OIDC Identity Provider
IAM Roles and Policies
STS AssumeRoleWithWebIdentity calls

References

Fixing "Network Error" in React Native When Connecting to QA Servers with HTTPS

Ray Ch — Tue, 09 Dec 2025 18:14:04 +0000

You're developing a React Native app using React Native CLI, testing on a physical device, and trying to connect to your QA server (like https://qa.example.com/api/). You keep getting this frustrating error:

Network Error
message: "Network Error"

This happens because your QA server likely uses a self-signed certificate or an untrusted/invalid SSL certificate, and both iOS and Android block these connections by default for security reasons.

Understanding Why This Happens

Modern mobile operating systems (Android 7+ and iOS 9+) enforce strict transport security:

Android: Starting from Android 7 (Nougat, API 24), apps no longer trust user-installed certificates by default
iOS: App Transport Security (ATS) requires all connections to use HTTPS with valid certificates

When your QA environment uses a self-signed certificate or a certificate from a non-public Certificate Authority (CA), your app refuses the connection - hence the "Network Error".

✅ Verified Solutions

Based on official Android and iOS documentation, here are the proven solutions that actually work:

Solution 1: Android - Network Security Configuration

This is the recommended approach for Android. It allows you to specify which certificates your app should trust without compromising security.

Step 1: Create Network Security Config

Create this file: android/app/src/main/res/xml/network_security_config.xml

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <!-- Configuration for your QA server -->
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">qa.example.com</domain>
        <trust-anchors>
            <!-- Trust system certificates -->
            <certificates src="system" />
            <!-- Trust user-installed certificates -->
            <certificates src="user" />
        </trust-anchors>
    </domain-config>
</network-security-config>

What this does:

Allows HTTPS connections to qa.example.com and all its subdomains
Trusts both system certificates AND user-installed certificates
Keeps security enabled (cleartextTrafficPermitted="false")

Step 2: Reference it in AndroidManifest.xml

Update android/app/src/main/AndroidManifest.xml:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.yourapp">

    <application
        android:name=".MainApplication"
        android:label="@string/app_name"
        android:networkSecurityConfig="@xml/network_security_config"
        ...>
        <!-- Your other application settings -->
    </application>
</manifest>

Alternative: Trust All User Certificates (Easier but Less Secure)

If you want to trust user certificates globally (not recommended for production):

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config>
        <trust-anchors>
            <certificates src="system" />
            <certificates src="user" />
        </trust-anchors>
    </base-config>
</network-security-config>

Solution 2: iOS - App Transport Security Exceptions

For iOS, you need to add exceptions to your Info.plist file.

Step 1: Locate Your Info.plist

Find the file: ios/YourAppName/Info.plist

Step 2: Add ATS Exception

Add this configuration to allow insecure connections to your QA server:

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSExceptionDomains</key>
    <dict>
        <key>qa.example.com</key>
        <dict>
            <key>NSIncludesSubdomains</key>
            <true/>
            <key>NSExceptionAllowsInsecureHTTPLoads</key>
            <true/>
        </dict>
    </dict>
</dict>

What this does:

Allows insecure connections specifically to qa.example.com
Includes all subdomains
Keeps ATS enabled for all other domains (secure by default)

Alternative: Disable ATS Globally (Not Recommended)

If you need to disable ATS entirely (only for development):

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <true/>
</dict>

⚠️ Warning: Apple may reject apps that use NSAllowsArbitraryLoads without proper justification.

🔧 Complete Implementation Example

Here's your complete setup for connecting to https://qa.example.com/api/:

1. API Service Configuration

// src/services/apiService.js
import axios from 'axios';

const API_BASE_URL = 'https://qa.example.com/api';

const api = axios.create({
  baseURL: API_BASE_URL,
  timeout: 30000,
  headers: {
    'Content-Type': 'application/json',
  },
});

// Request interceptor
api.interceptors.request.use(
  (config) => {
    console.log('Making request to:', config.url);
    return config;
  },
  (error) => {
    return Promise.reject(error);
  }
);

// Response interceptor
api.interceptors.response.use(
  (response) => {
    return response;
  },
  (error) => {
    console.error('API Error:', {
      message: error.message,
      code: error.code,
      response: error.response?.data,
      status: error.response?.status
    });
    return Promise.reject(error);
  }
);

export default api;

2. Login Screen Example

// src/screens/LoginScreen.js
import React, { useState } from 'react';
import { View, TextInput, Button, Alert } from 'react-native';
import api from '../services/apiService';

const LoginScreen = () => {
  const [email, setEmail] = useState('');
  const [password, setPassword] = useState('');
  const [loading, setLoading] = useState(false);

  const handleLogin = async () => {
    try {
      setLoading(true);

      const response = await api.post('/login', {
        email,
        password
      });

      console.log('Login successful:', response.data);
      Alert.alert('Success', 'Login successful!');

      // Handle successful login (save token, navigate, etc.)

    } catch (error) {
      console.error('Login error:', error);

      Alert.alert(
        'Login Failed',
        error.response?.data?.message || 'Network error occurred'
      );
    } finally {
      setLoading(false);
    }
  };

  return (
    <View style={{ padding: 20 }}>
      <TextInput
        placeholder="Email"
        value={email}
        onChangeText={setEmail}
        style={{ borderWidth: 1, marginBottom: 10, padding: 10 }}
      />
      <TextInput
        placeholder="Password"
        value={password}
        onChangeText={setPassword}
        secureTextEntry
        style={{ borderWidth: 1, marginBottom: 10, padding: 10 }}
      />
      <Button 
        title={loading ? "Logging in..." : "Login"} 
        onPress={handleLogin}
        disabled={loading}
      />
    </View>
  );
};

export default LoginScreen;

📱 Rebuild and Test

After making these changes, you must rebuild your app:

# For Android
npx react-native run-android

# For iOS
cd ios && pod install && cd ..
npx react-native run-ios

🔍 Debugging Tips

If you're still experiencing issues, try these debugging steps:

1. Check the Certificate

Verify your QA server's certificate:

# Check certificate details
openssl s_client -connect qa.example.com:443 -showcerts

# Get certificate
echo | openssl s_client -servername qa.example.com -connect qa.example.com:443 2>/dev/null | openssl x509 -text

2. Test the Endpoint

Use curl to test if the endpoint is accessible:

curl -v https://qa.example.com/api/health

3. Enable Detailed Logging

Add detailed error logging to your API calls:

catch (error) {
  console.log('=== Full Error Details ===');
  console.log('Message:', error.message);
  console.log('Code:', error.code);
  console.log('Config:', error.config);
  console.log('Response Data:', error.response?.data);
  console.log('Response Status:', error.response?.status);
  console.log('Response Headers:', error.response?.headers);
  console.log('========================');
}

4. Check Network Connectivity

Ensure your device can reach the QA server:

# On your computer, check if QA server is reachable
ping qa.example.com

# Check if HTTPS port is open
telnet qa.example.com 443

🔐 Security Best Practices

For Development/QA:

✅ DO:

Use domain-specific exceptions (not global)
Document why each exception is necessary
Keep exceptions to minimum required domains
Use includeSubdomains carefully

❌ DON'T:

Disable ATS/Network Security completely
Use these configurations in production builds
Trust all certificates globally
Commit sensitive certificates to version control

Before Production:

Remove all development exceptions
Get a proper SSL certificate for production (Let's Encrypt, DigiCert, etc.)
Test on real HTTPS endpoints
Use SSL pinning for sensitive apps

// For production, consider using react-native-ssl-pinning
import { fetch } from 'react-native-ssl-pinning';

fetch('https://your-production-api.com/endpoint', {
  method: 'POST',
  sslPinning: {
    certs: ['production-cert'] // Certificate in android/app/src/main/assets/
  },
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({ data: 'value' })
});

📦 Alternative: Use SSL Pinning Library

For more robust SSL handling, especially in production, consider using a dedicated library:

npm install react-native-ssl-pinning

Then implement certificate pinning:

import { fetch } from 'react-native-ssl-pinning';

const response = await fetch('https://qa.example.com/api/login', {
  method: 'POST',
  timeoutInterval: 10000,
  sslPinning: {
    certs: ['qa-cert'] // Place qa-cert.cer in android/app/src/main/assets/
  },
  headers: {
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ email, password })
});

🎯 Summary Checklist

For Android:

Create network_security_config.xml in res/xml/
Add domain configuration with trust anchors
Reference config in AndroidManifest.xml
Rebuild app with npx react-native run-android

For iOS:

Open Info.plist in Xcode or text editor
Add NSAppTransportSecurity exceptions
Specify your QA domain in NSExceptionDomains
Run pod install in ios folder
Rebuild app with npx react-native run-ios

For Both:

Verify API base URL is correct
Test network connectivity to QA server
Check device logs for detailed errors
Document why exceptions are needed
Plan to remove exceptions before production

🔗 Official Documentation References

💡 Common Issues & Solutions

Issue: Still getting "Network Error" after configuration

Solution: Make sure you've rebuilt the app completely. Sometimes a clean build is needed:

# Android
cd android && ./gradlew clean && cd ..
npx react-native run-android

# iOS
cd ios && pod deintegrate && pod install && cd ..
npx react-native run-ios

Issue: Works on Android but not iOS

Solution: iOS requires more specific ATS exceptions. Make sure you've added the domain to NSExceptionDomains and set NSExceptionAllowsInsecureHTTPLoads to true.

Issue: Certificate verification fails

Solution: Install the QA certificate on your device manually:

Android: Settings → Security → Install from storage
iOS: Email certificate → Install → Trust in Settings

Issue: Works in development but fails in release build

Solution: Release builds may strip debugging configurations. Ensure your Network Security Config and Info.plist exceptions are properly included in release builds.

🎉 Conclusion

The "Network Error" when connecting to HTTPS QA servers in React Native is a security feature, not a bug. By properly configuring Network Security Config for Android and App Transport Security for iOS, you can safely connect to your QA environment during development while maintaining security for other connections.

Remember: These configurations are for development and testing only. Always use proper SSL certificates in production and remove these exceptions before shipping your app to users.

Questions or issues? Drop a comment below or check the official documentation links above.

Found this helpful? Share it with your fellow React Native developers! 🚀

Fixing React Error #306 in Next.js App Router

Ray Ch — Wed, 26 Nov 2025 10:45:12 +0000

What is React Error #306?

React Error #306 occurs when you try to pass a non-serializable object (like a function, class instance, or complex object) across the server/client component boundary in Next.js App Router.

The full error message is:

Objects are not valid as a React child (found: [object Object]). If you meant to render a collection of children, use an array instead.

In production, you'll see the minified version:

Error: Minified React error #306; visit https://react.dev/errors/306?args[]=%5Bobject%20Object%5D&args[]= for the full message

Why Does It Work Locally But Fail in Production?

Environment	Behavior
Development (`npm run dev`)	React is lenient and allows some serialization issues to pass silently
Production (`npm run build && npm start`)	React strictly enforces serialization rules and throws errors

This happens because:

Development mode prioritizes developer experience with helpful warnings
Production mode optimizes for performance with strict validation
Minification in production removes detailed error messages

Common Causes

1. Missing `'use client'` Directive

Components using hooks, browser APIs, or UI libraries like MUI must be client components.

Problem:

// ❌ Server component by default - will fail with MUI
import Box from '@mui/material/Box';

export default function Page() {
  return <Box>Hello</Box>;
}

Solution:

// ✅ Explicitly mark as client component
'use client';

import Box from '@mui/material/Box';

export default function Page() {
  return <Box>Hello</Box>;
}

2. Router Object in Dependency Arrays

The router object from useRouter() contains non-serializable functions and symbols.

Problem:

'use client';
import { useRouter } from 'next/navigation';
import { useEffect } from 'react';

export function ProtectedRoute({ children }) {
  const router = useRouter();

  useEffect(() => {
    router.push('/login');
  }, [router]); // ❌ Router in dependency array causes serialization issues

  return <>{children}</>;
}

Solution:

'use client';
import { useRouter } from 'next/navigation';
import { useEffect } from 'react';

export function ProtectedRoute({ children }) {
  const router = useRouter();

  useEffect(() => {
    router.push('/login');
    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, []); // ✅ Router is stable, safe to omit from deps

  return <>{children}</>;
}

3. Non-Memoized Context Values

Creating a new object on every render causes React to attempt serialization.

Problem:

'use client';

export const AuthProvider = ({ children }) => {
  const [isAuthenticated, setIsAuthenticated] = useState(false);

  const login = () => { /* ... */ };
  const logout = () => { /* ... */ };

  return (
    <AuthContext.Provider
      value={{ isAuthenticated, login, logout }} // ❌ New object every render
    >
      {children}
    </AuthContext.Provider>
  );
};

Solution:

'use client';
import React, { useState, useCallback, useMemo } from 'react';

export const AuthProvider = ({ children }) => {
  const [isAuthenticated, setIsAuthenticated] = useState(false);

  const login = useCallback(() => { /* ... */ }, []);
  const logout = useCallback(() => { /* ... */ }, []);

  const contextValue = useMemo(
    () => ({ isAuthenticated, login, logout }),
    [isAuthenticated, login, logout]
  ); // ✅ Memoized object

  return (
    <AuthContext.Provider value={contextValue}>
      {children}
    </AuthContext.Provider>
  );
};

4. Functions Without useCallback in Context

Functions recreated on every render cause context value changes.

Problem:

const searchInvestors = async (query) => { // ❌ Recreated every render
  return investors.filter(i => i.name.includes(query));
};

Solution:

const searchInvestors = useCallback(async (query) => { // ✅ Stable reference
  return investors.filter(i => i.name.includes(query));
}, [investors]);

Real-World Cases & Fixes

Case 1: Dashboard Layout Missing Client Directive

File: src/app/dashboard/layout.tsx

Before:

import { ProtectedRoute } from '@/components/ProtectedRoute';
import { SideNav } from '@/components/dashboard/layout/side-nav';

export default function Layout({ children }) {
  return (
    <ProtectedRoute>
      <SideNav />
      {children}
    </ProtectedRoute>
  );
}

After:

'use client';

import { ProtectedRoute } from '@/components/ProtectedRoute';
import { SideNav } from '@/components/dashboard/layout/side-nav';

export default function Layout({ children }) {
  return (
    <ProtectedRoute>
      <SideNav />
      {children}
    </ProtectedRoute>
  );
}

Case 2: AuthProvider with Router and Unmemoized Context

File: src/components/AuthProvider.tsx

Before:

'use client';
import { useRouter } from 'next/navigation';

export const AuthProvider = ({ children }) => {
  const [isAuthenticated, setIsAuthenticated] = useState(false);
  const router = useRouter();

  useEffect(() => {
    checkAuth();
  }, []); // Missing router but using it

  const login = (tokens) => {
    setIsAuthenticated(true);
    router.push('/dashboard/');
  };

  const logout = () => {
    setIsAuthenticated(false);
    router.push('/auth/login');
  };

  return (
    <AuthContext.Provider value={{ isAuthenticated, login, logout }}>
      {children}
    </AuthContext.Provider>
  );
};

After:

'use client';
import React, { useState, useCallback, useMemo, useEffect } from 'react';
import { useRouter } from 'next/navigation';

export const AuthProvider = ({ children }) => {
  const [isAuthenticated, setIsAuthenticated] = useState(false);
  const router = useRouter();

  useEffect(() => {
    checkAuth();
    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, []);

  const login = useCallback((tokens) => {
    setIsAuthenticated(true);
    router.replace('/dashboard/');
    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, []);

  const logout = useCallback(() => {
    setIsAuthenticated(false);
    window.location.href = '/portal/auth/login'; // Full redirect avoids basePath issues
    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, []);

  const contextValue = useMemo(
    () => ({ isAuthenticated, login, logout }),
    [isAuthenticated, login, logout]
  );

  return (
    <AuthContext.Provider value={contextValue}>
      {children}
    </AuthContext.Provider>
  );
};

Case 3: ProtectedRoute with Router Dependency

File: src/components/ProtectedRoute.tsx

Before:

'use client';
import { useRouter } from 'next/navigation';
import { useEffect } from 'react';

export const ProtectedRoute = ({ children }) => {
  const { isAuthenticated, isLoading } = useAuth();
  const router = useRouter();

  useEffect(() => {
    if (!isLoading && !isAuthenticated) {
      router.push('/auth/login');
    }
  }, [isLoading, isAuthenticated, router]); // ❌ Router in deps

  return <>{children}</>;
};

After:

'use client';
import { useRouter } from 'next/navigation';
import { useEffect } from 'react';

export const ProtectedRoute = ({ children }) => {
  const { isAuthenticated, isLoading } = useAuth();
  const router = useRouter();

  useEffect(() => {
    if (!isLoading && !isAuthenticated) {
      router.push('/auth/login');
    }
    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, [isLoading, isAuthenticated]); // ✅ Router omitted

  return <>{children}</>;
};

Case 4: SupportContext with Multiple Functions

File: src/components/support/context/SupportContext.tsx

Before:

'use client';

export const SupportProvider = ({ children }) => {
  const [investors, setInvestors] = useState([]);

  const searchInvestors = async (query) => { /* ... */ };
  const addInvestorTab = (investor) => { /* ... */ };
  const removeInvestorTab = (id) => { /* ... */ };

  return (
    <SupportContext.Provider value={{
      investors,
      searchInvestors,
      addInvestorTab,
      removeInvestorTab,
    }}>
      {children}
    </SupportContext.Provider>
  );
};

After:

'use client';
import React, { useState, useCallback, useMemo } from 'react';

export const SupportProvider = ({ children }) => {
  const [investors, setInvestors] = useState([]);

  const searchInvestors = useCallback(async (query) => { /* ... */ }, [investors]);
  const addInvestorTab = useCallback((investor) => { /* ... */ }, []);
  const removeInvestorTab = useCallback((id) => { /* ... */ }, []);

  const contextValue = useMemo(() => ({
    investors,
    searchInvestors,
    addInvestorTab,
    removeInvestorTab,
  }), [investors, searchInvestors, addInvestorTab, removeInvestorTab]);

  return (
    <SupportContext.Provider value={contextValue}>
      {children}
    </SupportContext.Provider>
  );
};

Best Practices Checklist

When to Use `'use client'`

Add 'use client' directive when your component:

Uses React hooks (useState, useEffect, useContext, etc.)
Uses browser APIs (window, document, localStorage)
Uses UI libraries like MUI, Chakra UI, or styled-components
Imports client-only components (like ProtectedRoute)
Uses event handlers (onClick, onChange, etc.)

Context Best Practices

Wrap all context functions with useCallback
Memoize context value object with useMemo
Keep context providers as client components
Avoid passing router or non-serializable objects through context

Router Usage

Never include router in useEffect dependency arrays
Use eslint-disable-next-line comment when omitting required deps
Consider window.location.href for full-page redirects to avoid basePath issues
Use router.replace() instead of router.push() for auth redirects

Debugging Tips

1. Enhanced Error Logging

Create an error.tsx file with detailed logging:

'use client';
import { useEffect } from 'react';

export default function GlobalError({
  error,
  reset,
}: {
  error: Error & { digest?: string };
  reset: () => void;
}) {
  useEffect(() => {
    console.error('Global app error:', error);
    console.error('Error name:', error.name);
    console.error('Error message:', error.message);
    console.error('Error stack:', error.stack);
    console.error('Error digest:', error.digest);
    console.error('Full error:', JSON.stringify(error, Object.getOwnPropertyNames(error)));
  }, [error]);

  return (
    <html>
      <body>
        <h1>Something went wrong</h1>
        <p>{error.message}</p>
        {error.stack && <pre>{error.stack}</pre>}
        <button onClick={reset}>Try again</button>
      </body>
    </html>
  );
}

2. Temporarily Disable Minification

Add to next.config.mjs to see full error messages:

const nextConfig = {
  // ... other config
  webpack: (config, { dev, isServer }) => {
    if (!dev && !isServer) {
      config.optimization.minimize = false;
    }
    return config;
  },
};

Warning: Remove this before deploying to production as it significantly increases bundle size.

3. Enable Source Maps

const nextConfig = {
  productionBrowserSourceMaps: true,
  // ... other config
};

4. Check Component Hierarchy

Use React DevTools to trace where non-serializable props might be passed:

Look for components crossing server/client boundaries
Check what props are being passed to client components
Verify all layouts and pages have correct directives

Quick Reference

Symptom	Likely Cause	Fix
Error only in production	Serialization issue	Add `'use client'` or memoize
Error mentions `[object Object]`	Non-serializable prop	Use `useMemo`/`useCallback`
Error in layout/page with MUI	Missing client directive	Add `'use client'`
Error after adding router to deps	Router serialization	Remove router from deps
Error in context provider	Unmemoized context value	Memoize with `useMemo`

From Patches to Perfection: How Multi-Stage Docker Builds Solved Our Containerization Nightmare

Ray Ch — Wed, 02 Jul 2025 12:06:37 +0000

Sometimes the best solution isn't fixing what's broken—it's stepping back and doing it right from the start. This is the story of how we spent days fighting Docker containerization issues with increasingly complex patches, only to discover that the industry-standard approach would have saved us all that trouble.

The Nightmare Begins

What started as a simple task—containerizing a React/Vite frontend application—quickly spiraled into a multi-day debugging marathon. Our builds were failing with cryptic errors about missing platform-specific binaries, dependency resolution conflicts, and architecture mismatches.

The symptoms were clear, but we were about to learn the hard way that treating symptoms instead of addressing root causes leads to an ever-growing pile of technical debt.

The Wrong Turn: Fighting Individual Symptoms

Our Misguided Approach

Like many developers facing build issues, we fell into the classic trap of incremental patching. Each error message led to a new "fix" that seemed logical in isolation:

Attempt 1-2: Added platform-specific optional dependencies

@rollup/rollup-linux-x64-musl
@esbuild/linux-x64 with pinned versions

Attempt 3-4: Switched between base images

Alpine to Debian and back
Different Node.js versions

Attempt 5: Changed build commands

npm ci vs npm install
Various npx configurations
Modified TypeScript compilation flags

Why This Approach Failed

Each "fix" created new problems because we were fighting the fundamental architecture issues:

Platform Mismatch: We were trying to run macOS/Windows-specific binaries inside Linux containers
Dependency Contamination: Host system node_modules and lock files were interfering with container builds
Complex Resolution Logic: Fighting npm's optional dependency system instead of working with it
Non-Standard Architecture: Creating a custom build process instead of following proven patterns

The telltale sign we were on the wrong path? Every fix made the package.json more complex and the build process more fragile.

The Breakthrough: Embracing Multi-Stage Builds

After hours of frustration, we stepped back and asked a crucial question: "How do production applications actually handle this?"

The answer was staring us in the face: multi-stage Docker builds.

The Industry Standard Solution

Instead of fighting platform-specific binaries and complex dependency resolution, we separated build complexity from runtime simplicity:

# STAGE 1: Build Environment
FROM node:20-alpine AS builder
WORKDIR /app

# Install dependencies in clean container environment
COPY package*.json ./
RUN npm install

# Build the application
COPY . .
RUN npm run build

# STAGE 2: Production Runtime
FROM node:20-alpine AS production
RUN npm install -g serve

# Copy only the built assets
COPY --from=builder /app/dist /app
WORKDIR /app

EXPOSE 3000
CMD ["serve", "-s", ".", "-l", "3000"]

The Critical Supporting Changes

The Dockerfile was just part of the solution. We also needed:

.dockerignore to prevent host contamination:

node_modules/
package-lock.json
npm-debug.log
dist/
.git/

Clean package.json - removed all the optional dependency hacks we'd added.

Why This Approach Works Brilliantly

1. True Separation of Concerns

Build Stage: Handles all the complexity

TypeScript compilation
Vite bundling
Platform-specific binary resolution
Development dependencies

Runtime Stage: Simple and reliable

Just serves static files
Minimal attack surface
Small final image size (~50MB vs 500MB+)

2. Platform-Native Resolution

When npm install runs inside the Linux container, it automatically:

Downloads Linux-appropriate native binaries
Resolves dependencies for the target platform
Eliminates host system contamination

No more manual dependency management or architecture-specific patches needed.

3. Industry Battle-Tested Pattern

This isn't a clever hack—it's how major companies containerize frontend applications:

Netflix: Uses multi-stage builds for their React applications
Airbnb: Standard pattern across their frontend infrastructure
Spotify: Multi-stage builds for all Node.js applications

4. Performance and Maintainability

Build Performance:

Docker layer caching works optimally
Dependencies only rebuild when package.json changes
Parallel stage execution where possible

Maintainability:

No complex optional dependencies to manage
Standard patterns that any developer can understand
Easy to modify and extend

The Dramatic Results

Before: The Nightmare

❌ 45+ minute build times (when they succeeded)
❌ 60% build failure rate
❌ 500MB+ final images
❌ Platform-specific issues
❌ Complex dependency management
❌ Difficult debugging

After: The Dream

✅ 3-5 minute build times
✅ 99%+ build success rate
✅ ~50MB final images
✅ Platform agnostic
✅ Standard dependency resolution
✅ Clear, debuggable process

The Deeper Lessons

1. Question Your Assumptions Early

We assumed our approach was correct and spent days optimizing the wrong solution. A few minutes researching "React Docker containerization best practices" would have saved hours.

2. Complexity Is Usually a Warning Sign

When your package.json starts filling with platform-specific hacks and optional dependencies, that's usually a sign you're fighting the tooling instead of working with it.

3. Industry Standards Exist for a Reason

Multi-stage Docker builds weren't invented for fun—they solve real problems that every team eventually encounters. Following established patterns usually beats clever custom solutions.

4. Step Back Before Stepping Forward

Sometimes the best debugging approach is to stop debugging and ask: "Is there a fundamentally different way to approach this problem?"

Key Technical Takeaways

For Docker Builds:

Always use multi-stage builds for applications with build steps
Let containers resolve their own dependencies rather than copying from host
Use .dockerignore to prevent host file contamination
Separate build and runtime concerns into different stages

For Team Processes:

Set time limits on incremental fixes - if you're not making progress, try a different approach
Research industry standards before implementing custom solutions
Document architectural decisions to prevent repeating mistakes

The Bottom Line

What felt like a Docker problem was actually an architecture problem. We were trying to force a complex, host-dependent build process into a simple container when we should have been leveraging Docker's strengths to separate and simplify concerns.

The multi-stage build approach didn't just fix our immediate issues—it gave us a more robust, maintainable, and scalable foundation for the future. Sometimes the solution isn't to fix what you have, but to do it right from the beginning.

The core insight: Multi-stage Docker builds exist precisely to solve the build-vs-runtime complexity issues we were struggling with. When the industry has already solved your problem, use their solution rather than inventing your own.

Now our frontend builds are fast, reliable, and follow patterns that any developer on the team can understand and maintain. That's what good architecture looks like.

Regenerate Xcode automatic signing

Ray Ch — Sat, 23 Dec 2023 05:24:23 +0000

Dealing with issues related to Xcode's automatic signing can be tricky, especially when it seems to hold onto outdated provisioning profiles. Here's a step-by-step approach to resolve this:

Disable Automatic Signing:
- Open your project in Xcode.
- Select the project in the Project Navigator.
- Choose the target for which you want to change the signing settings.
- Go to the "Signing & Capabilities" tab.
- Uncheck the "Automatically manage signing" option.
- After unchecking, you'll be able to manually select your provisioning profile and signing certificate.
Clear Existing Provisioning Profiles:
- On your Mac, navigate to the folder ~/Library/MobileDevice/Provisioning Profiles/.
- Delete any outdated or unnecessary provisioning profiles. These can sometimes be cached and reused by Xcode.
- It's often safe to delete all the profiles in this directory, as Xcode will regenerate or you can manually download what you need.
Clean the Build Folder:
- In Xcode, perform a clean operation (Product > Clean Build Folder).
- This ensures that any cached data from previous builds is removed.
Restart Xcode:
- Close Xcode and then reopen it. This can help in clearing any cached settings.
Manually Set Signing:
- After reopening your project, go back to the "Signing & Capabilities" section for your target.
- Manually select the correct provisioning profile and signing certificate.
Rebuild and Archive:
- Rebuild your project.
- If you're preparing for an App Store submission, create a new archive.
Validate and Submit:
- Use the “Validate App” feature in Xcode to check for any issues before submitting to the App Store.

If after these steps you continue to face issues, you might want to consider reviewing your Apple Developer account to ensure that all certificates and provisioning profiles are up to date and correctly configured. Sometimes, issues with signing can stem from expired certificates or profiles that haven't been properly set up in the Apple Developer portal.

Short-circuiting

Ray Ch — Sat, 16 Sep 2023 06:56:51 +0000

Short-circuiting is not unique to Python; it's a feature found in many programming languages, including but not limited to JavaScript, Java, C++, and C#

The core principle remains consistent: evaluation stops as soon as the final outcome is determined.

In Python, Short-circuiting behavior is evident in the use of logical operators like or and and. The key principle is that these operators will stop evaluating as soon as the outcome is determined. This feature has several implications, both for performance and functionality.

`or` Operator

As you've seen in the previous example, the or operator will evaluate operands from left to right and return the first "truthy" value it encounters. If no "truthy" value is found, it returns the last "falsy" value.

result = None or '' or 0 or 'first_truthy' or 'second_truthy'
# result will be 'first_truthy'

`and` Operator

The and operator also evaluates operands from left to right but stops as soon as it encounters a "falsy" value and returns it. If all operands are "truthy," it returns the last "truthy" value.

result = 1 and 2 and 'third_truthy' and None and 'not_evaluated'
# result will be None

`if` and `elif` Statements

Short-circuiting can also occur in if and elif statements, where later conditions aren't evaluated if an earlier condition has already been met:

if cheaper_function() or expensive_function():
    # expensive_function will not be called if cheaper_function returns True

Nested Logical Operations

You can combine or and and in nested conditions. Be cautious here, as readability can become an issue.

result = func1() or (func2() and func3())
# If func1() is truthy, neither func2() nor func3() will be evaluated.

Implications

Performance Optimization: Short-circuiting can be leveraged to improve performance by placing less expensive or faster-to-evaluate conditions earlier in the logic chain.
Conditional Side Effects: If a function or operation inside a logical expression has side-effects (like database operations), those side-effects may not occur if short-circuiting prevents their evaluation.
Readability and Maintenance: While short-circuiting can make code more efficient, it can also make it less readable if overused or implemented without clarity.

Tuple Immutability

Ray Ch — Sat, 16 Sep 2023 06:37:19 +0000

In Python, the immutability of a tuple refers to the fact that once a tuple is created, its structure cannot be altered. Specifically, you cannot add, remove, or change elements within the tuple itself.

However, this immutability is shallow, which means that if a tuple contains mutable elements—like lists or dictionaries—those elements themselves can be modified.

What Does Immutability Mean?

When we say tuples are immutable, it implies that the tuple object itself cannot change after its creation:

# Immutable: Cannot change the tuple itself
my_tuple = (1, 2, 3)
# The following line would cause an error
# my_tuple[1] = 4

Mutable Objects Inside Tuples

Despite the tuple's immutability, any mutable objects inside the tuple can be modified:

# Tuple with a list (mutable object) inside
my_tuple = (1, 2, [3, 4])

# Modifying the internal list is possible
my_tuple[2][0] = 5
# my_tuple becomes (1, 2, [5, 4])

Implications in a Professional Setting

Understanding the shallow immutability of tuples is crucial in various scenarios:

Data Integrity: If you are dealing with configurations or settings that should remain constant throughout the program, using tuples makes sense. However, you must be cautious if these tuples contain mutable types, as those can still be altered.
Performance: Given that tuples are immutable, they are generally faster for read-only operations compared to lists. This could be advantageous in performance-critical sections of your code.
Multi-threading: The immutability of tuples makes them inherently thread-safe for the tuple elements themselves, but not necessarily for mutable objects contained within.
Program Architecture: If your application requires a constant set of parameters, especially in a complex system architecture where parameters are passed through multiple functions or layers, using tuples can serve as a form of documentation that these should not be modified.

Resolving ImagePullBackOff and Accessing a LoadBalancer Service in Minikube

Ray Ch — Sat, 15 Apr 2023 06:56:12 +0000

Summary: This document details the steps taken to resolve the ImagePullBackOff error and access a LoadBalancer service in a Kubernetes cluster running on Minikube.

Issue

The ImagePullBackOff error occurred while deploying the hello-world-microservice in a Kubernetes cluster running on Minikube. This issue prevented the deployment from starting. Additionally, accessing the LoadBalancer service using the curl command did not return any output.

Resolution

Fixing the ImagePullBackOff error

Update the image name in the Kubernetes deployment manifest to use the correct image name available in the container registry.
Apply the updated deployment manifest:

kubectl apply -f k8s-deployment.yaml

In terraform terraform apply

Accessing the LoadBalancer service

Check the logs of the running pods to see if there is any error or if the application has started properly:

kubectl logs hello-world-microservice-b849675f-gns8s -n hello-world
kubectl logs hello-world-microservice-b849675f-jrgpp -n hello-world

Access the service from within the cluster using a temporary pod with the curl command:

kubectl run curl-test --image=curlimages/curl:latest --rm -it --restart=Never --namespace=hello-world --command -- sh

Then, within the curl-test, Run:
curl hello-world-microservice:80

I am doing this because it's a web application. This depends on and defer based on the program.

My issue with Minikube

The actual problem I had was not with code and image but Minikube.

Since Minikube doesn't support the LoadBalancer service type out-of-the-box, run the minikube tunnel command in a separate terminal to create a network route on the host to the service CIDR of the cluster using the cluster's IP address as a gateway:

minikube tunnel

Check if the service's external IP:
kubectl get svc hello-world-microservice -n hello-world

Access the service using the external IP and port:
curl http://<EXTERNAL_IP>:80

Conclusion
By updating the image name in the Kubernetes deployment manifest and using the minikube tunnel command, I was successful in resolving the ImagePullBackOff error and accessed the LoadBalancer service in the Minikube Kubernetes cluster.

Microservice with Kubernetes, Terraform, and Nest.js in Mac

Ray Ch — Sat, 15 Apr 2023 06:44:17 +0000

Prerequisites:*

Install Node.js: https://nodejs.org/en/download/
Install Docker: https://www.docker.com/products/docker-desktop
Install Kubernetes CLI (kubectl): https://kubernetes.io/docs/tasks/tools/install-kubectl-macos/
Install Minikube (for local Kubernetes cluster): https://minikube.sigs.k8s.io/docs/start/
Install Terraform: https://learn.hashicorp.com/tutorials/terraform/install-cli

1. Creating Nest.js

I won't tell about Nest.js because it runs in 3000 port which already has pre-built "Hello World!" in the base boilerplate. So, I won't do anything new.

Install Nest.js CLI globally: npm install -g @nestjs/cli
Create a new Nest.js project: nest new hello-world-microservice

2: Containerize the Nest.js application

Create a Dockerfile in the project root with the following content:

FROM node:lts

RUN npm i -g pnpm

WORKDIR /app

COPY package.json pnpm-lock.yaml ./

RUN pnpm install

COPY . .

RUN pnpm run build

EXPOSE 3000

CMD ["pnpm", "run", "start:prod"]

Build the Docker image: docker build -t hello-world-microservice .

3: Set up Kubernetes deployment and service

Start Minikube: minikube start
Set Docker environment: eval $(minikube docker-env)

4: Set up Terraform

This is the crucial part of running the micro service.

provider "kubernetes" {
  config_path = "~/.kube/config"
}

resource "kubernetes_namespace" "hello-world" {
  metadata {
    name = "hello-world"
  }
}

resource "kubernetes_deployment" "hello-world-microservice" {
  metadata {
    name      = "hello-world-microservice"
    namespace = kubernetes_namespace.hello-world.metadata.0.name
  }

  spec {
    replicas = 2

    selector {
      match_labels = {
        app = "hello-world-microservice"
      }
    }

    template {
      metadata {
        labels = {
          app = "hello-world-microservice"
        }
      }

      spec {
        container {
          name  = "hello-world-microservice"
          image = "hello-world-microservice"
          image_pull_policy = "Never"

          port {
            container_port = 3000
          }
        }
      }
    }
  }
}

resource "kubernetes_service" "hello-world-microservice" {
  metadata {
    name      = "hello-world-microservice"
    namespace = kubernetes_namespace.hello-world.metadata.0.name
  }

  spec {
    selector = {
      app = "hello-world-microservice"
    }

    port {
      port        = 80
      target_port = 3000
    }

    type = "LoadBalancer"
  }
}

Initialize Terraform: terraform init
Apply the Terraform configuration: terraform apply

5: Test the "Hello World" Microservice

Get the Minikube IP: minikube ip
Get the service's external port: kubectl get services -n hello-world
Combine the Minikube IP and the external port, and open the URL in your browser or use curl. For example, if Minikube IP is 192.168.49.2 and the external port is 32000, you can use curl http://192.168.49.2:32000 to see the "Hello World!" message.
This doesn't work for few in that case you have to work should use minikube tunnel