Frontend is forgiving. Mobile is not.

I’ve spent over a decade building mobile experiences, eventually landing deep in React Native where JavaScript collides with gestures, memory limits, native bridges, and two operating systems that rarely agree with each other. I’ve rewritten apps through the React era, from class components to hooks, often under App Store and Play Store review cycles where “almost correct” still means rejection.

Mobile doesn’t forgive abstractions that leak. It charges interest on every shortcut.

Despite all that churn, nothing boosted my productivity more than mastering Claude Code as a serious mobile/web development tool.

But here’s what most articles get wrong. They list every slash command like a man page and call it a guide. That’s not how a principal engineer thinks.

We don’t think in commands. We think in systems. We think in workflows. We think about which combinations of tools create leverage — where the whole becomes greater than the sum of its parts.

This article is my opinionated, battle-tested guide to the Claude Code commands and features that actually move the needle when building React and React Native applications. Not everything Claude can do but only the things that consistently deliver maximum output in real-world mobile and web codebases.

💡 Principal Insight

The goal isn’t to use every feature Claude offers. It’s to build a workflow where context stays clean, intent stays clear, and Claude operates like a senior engineer on your team & not a fancy autocomplete.

01. The Foundation Layer — CLAUDE.md

Before you type a single command, you need to give Claude a brain for your project. The CLAUDE.md file is the single most impactful thing you can do. Period. It's not optional — it's the difference between Claude generating generic React boilerplate and Claude generating code that fits your architecture like a glove.

Your First Command — Always

claude
/init

The /init command scans your project and generates a starter CLAUDE.md. But don't stop there. A principal-level CLAUDE.md for a React Native project should encode your architectural decisions:

CLAUDE.md — React Native Project (Example)

## Architecture
- React Native 0.76+ with New Architecture enabled
- Navigation: React Navigation v7 (stack + bottom tabs)
- State: Zustand for client state, TanStack Query for server state
- Styling: StyleSheet.create() — no inline styles, no Tailwind

## Code Standards
- Functional components only. No class components.
- Custom hooks for ALL business logic (useAuth, useCart, etc.)
- Barrel exports via index.ts in every feature folder
- Error boundaries at route level minimum

## File Structure
src/
  features/     # Feature-based modules
  shared/       # Shared components, hooks, utils
  navigation/   # Navigation config
  services/     # API layer (Axios + interceptors)
  types/        # Global TypeScript types

## Testing
- Jest + React Native Testing Library
- Test files colocated: Component.test.tsx
- E2E: Detox for critical user flows

## Commands
- Dev: npx react-native start
- Test: jest --watchAll
- Lint: eslint . --fix
- Type check: tsc --noEmit

📊 Impact Metric

In my experience, a well-crafted CLAUDE.md reduces “wrong architecture” suggestions by roughly 70%. Claude stops suggesting Redux when you’ve specified Zustand. It stops creating class components. It follows your conventions. The 30-minute investment compounds across every session.

🎯 Pro Tip

Use /memory during any session to quickly edit your CLAUDE.md without leaving the terminal. Treat it like a living document — update it every time you make an architectural decision.

02. The Command Arsenal: What Actually Matters

Claude Code has dozens of commands. Most articles list all of them. Here’s my tiered ranking based on actual frontend development impact:

Tier 1 — Use These Every Single Session

/initCritical

Generates CLAUDE.md by scanning your codebase. Run it once, then refine manually. This is your project’s DNA for Claude.

/compactCritical

Summarizes conversation history, keeping key decisions while freeing context window. In long React refactoring sessions, this is a lifesaver. Use /compact Focus on the component migration to guide what gets preserved.

Shift+Tab (Plan Mode)Critical

Toggles between plan mode and execution mode. Plan mode means Claude analyzes and strategizes without writing code. I use this 90% of the time before any implementation.

@ (File Reference)Critical

Point Claude at specific files: @src/components/Button.tsx — review this for accessibility. Dramatically reduces hallucination because Claude reads the actual file instead of guessing.

Tier 2 — Use These Weekly

/reviewHigh

Runs a code review against your staged changes. Catches performance anti-patterns like unnecessary re-renders, missing React.memo, and inline object creation in JSX.

/clearHigh

Nuclear reset. Use between completely unrelated tasks. Switching from API work to CSS layout? /clear prevents context pollution.

/contextHigh

Shows how much of the context window you’ve consumed. When this gets above 60%, Claude starts forgetting your earlier architectural decisions. Time to /compact.

Esc + Esc (/rewind)High

Undo Claude’s last action. Invaluable when Claude takes a wrong architectural turn during a React Native navigation refactor.

Tier 3 — Situational But Powerful

/costMedium

Check token usage against plan limits. Useful for staying aware during heavy refactoring sessions.

/agentsMedium

Manage your custom subagents. Worth setting up for recurring FE tasks like design system audits.

! (Bang Command)Medium

Run bash directly: !npx tsc — noEmit to type-check without leaving Claude. Great for quick validation loops.

⚠️ Watch Out

The biggest mistake I see: developers never use /compact or /clear. They have 45-minute sessions where Claude progressively forgets the CLAUDE.md conventions and starts generating garbage. Context management isn't optional it's the skill that separates productive sessions from frustrating ones.

03. Skills & Plugins — Where the Real Leverage Is

Skills are where Claude Code goes from “helpful assistant” to “team member who knows our codebase.” A skill is a SKILL.md file with instructions that Claude automatically applies when the context matches. Think of them as reusable architectural guardrails.

The Must-Install Skills for React/RN Developers

🔥 frontend-design (Built-in Plugin)

Ships with Claude Code. Automatically activates when building UI components. Pushes Claude toward distinctive, production-grade interfaces instead of generic “AI-looking” output. It’s the difference between a Bootstrap clone and something that looks intentionally designed.

/plugins install frontend-design

📱 React Native Best Practices (Callstack)

Just released by Callstack — the team behind React Native’s core tooling. Covers JS performance patterns, native optimization, and bundle size reduction. Claude automatically references these patterns when working in RN codebases.

/plugin marketplace add callstackincubator/agent-skills
/plugin install react-native-best-practices@callstack-agent-skills

⚛️ Vercel React Best Practices

45 actionable rules from Vercel Engineering organized by impact level. Covers waterfalls, bundle issues, server-side patterns, and rendering optimizations. Claude categorizes findings as Critical, High, and Medium during reviews.

pip install skilz
skilz install vercel-labs/agent-skills/vercel-react-best-practices

Building Your Own Custom Skills

The pre-built skills get you started. The custom skills are where you encode your team’s tribal knowledge. Here’s a skill I use for every React Native feature:

.claude/skills/rn-feature/SKILL.md

---
name: rn-feature
description: Scaffold a new React Native feature module with 
  screens, navigation, hooks, types, and tests following our 
  architecture.
---

When creating a new feature module:
1. Create the directory structure:
   src/features/<name>/
   ├── screens/        # Screen components
   ├── components/     # Feature-specific components
   ├── hooks/          # Custom hooks for business logic
   ├── types/          # TypeScript types/interfaces
   ├── services/       # API calls (TanStack Query)
   ├── __tests__/      # Colocated tests
   └── index.ts        # Barrel export
2. Every screen gets an Error Boundary wrapper
3. Every API call goes through a custom hook with TanStack Query
4. Navigation types must extend RootStackParamList
5. Run tsc --noEmit after scaffolding to verify types

Now when I type /rn-feature checkout-flow, Claude scaffolds the entire module following our exact architecture. No more explaining the folder structure every session.

💡 Principal Insight

Skills activate automatically when their description matches the task context. This is the key mental model: you’re not running skills manually most of the time. You describe a task, and Claude pulls in the right skill. This only works if your descriptions are specific enough.

04. Subagents — The Principal Engineer’s Secret Weapon

This is where most developers stop exploring, and where the real leverage begins. Subagents are isolated Claude instances that run in separate context windows. They do the heavy investigative work and return concise summaries — without polluting your main session.

Here’s the math that should convince you. In a typical debugging session, Claude reads log files, parses error traces, checks dozens of files. That might consume 170K tokens. A subagent does the same work in its own context and returns a 5K-token summary. Your main context stays clean for actual implementation.

Built-in Subagents

# Explore — Read-only codebase investigation
"Use a subagent to investigate how our auth flow 
handles token refresh across the app"

# Plan - Architecture planning without touching code
"Use a Plan subagent to design the migration 
strategy from Redux to Zustand for our cart module"
# General-purpose - Your Swiss army knife
"Spin up a subagent to audit all our custom hooks 
for missing cleanup in useEffect"

Custom Subagent: The React Native Performance Auditor

.claude/agents/rn-perf-auditor.md

---
name: rn-perf-auditor
description: Audit React Native components for performance issues.
  Use when reviewing FlatList implementations, heavy screens, 
  or before release.
allowed-tools: Read, Grep, Glob
---
You are a React Native performance specialist. Audit the 
codebase for:
1. FlatList without keyExtractor or getItemLayout
2. Inline arrow functions in renderItem causing re-renders
3. Missing React.memo on list item components
4. Heavy computation in render path (move to useMemo)
5. Image components without width/height (causes layout thrash)
6. Animated.Value created inside component body (should be useRef)
7. InteractionManager.runAfterInteractions not used for 
   post-navigation heavy work
Return findings grouped by severity: Critical, Warning, Info.
Include file paths and line numbers.

🎯 Pro Tip

The golden rule of subagents: reads are parallel, writes are serial. You can have multiple subagents reading and analyzing simultaneously. But keep all actual code changes in the main thread to avoid merge conflicts. Think of subagents as your research team — they investigate, you implement.

You can also run background tasks with & (ampersand). Kick off a heavy refactor, switch to another task, and check back:

Background Tasks

# Start a background task
& Refactor the authentication module

# Check running tasks
/tasks
# Teleport into a background session
# Press 't' to jump in

05. Hooks — Deterministic Automation

Skills and subagents rely on Claude’s judgment. Hooks don’t. Hooks are deterministic scripts that fire at specific moments before a tool runs, after a tool runs, when permissions are requested. They always execute the same way, every time.

For frontend development, here are the hooks that have saved me the most time:

#.claude/settings.json - Useful Hooks

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write",
        "command": "echo 'Remember: Run tsc --noEmit after writing .tsx files'"
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Bash(npm install*)",
        "command": "echo 'Verify package.json for unexpected dependency additions'"
      }
    ],
    "Stop": [
      {
        "command": "terminal-notifier -message 'Claude finished the task' -title 'Claude Code'"
      }
    ]
  }
}

💡 Principal Insight

The Stop hook for desktop notifications is a game-changer. I kick off a component scaffolding task, go review a PR, and get a native macOS notification when Claude finishes. No more staring at the terminal.

06. The 10x Workflow — Putting It All Together

Here’s my actual daily workflow for building React Native features. This is where the individual commands compound into something transformative:

The Daily Flow

1. Open Terminal — Split Into 3 Panes
   Pane 1: Main Claude session. Pane 2: Metro bundler + device logs. Pane 3: A second Claude session for investigation/research.
2. Shift+Tab → Plan Mode
   Describe the feature. Let Claude analyze the codebase and propose architecture. Don’t let it write code yet.
3. Subagent: Explore
   “Use a subagent to investigate how similar features are implemented in our codebase.” This gives Claude (and you) real patterns to follow.
4. Review Plan → Shift+Tab → Execute
   Once the plan looks right, switch to execution mode. Claude writes code following your CLAUDE.md conventions and the architecture plan.
5. /review → Iterate
   After implementation, /review catches things like missing error boundaries, inline styles, or untested edge cases.
6. /compact After Each Feature
   Don’t carry feature A’s context into feature B. Compact with specific instructions: /compact Keep the navigation changes, drop the API discussion.

07. The TDD Loop with Claude

TDD is one thing that everyone talks about but are rarely consumed in development cycles. With claude this is the workflow that gives me the highest confidence in production code:

# Step 1: Write failing tests first
"Write failing tests for a PaymentCard component using 
React Native Testing Library:
- Renders masked card number (•••• •••• •••• 4242)
- Shows expiry date in MM/YY format
- onPress fires with card ID
- Disabled state greys out and prevents interaction
- Accessibility: card type announced to screen reader
Save as PaymentCard.test.tsx. Do NOT implement yet."

# Step 2: Review the tests (Plan Mode)
Shift+Tab → Review test coverage, add edge cases
# Step 3: Implement to pass
Shift+Tab → "Now implement PaymentCard.tsx to pass all tests"
# Step 4: Verify
!npx jest PaymentCard --coverage

📊 Impact Metric

When I adopted this TDD loop with Claude, bug reports from QA for new components dropped by about 60%. The tests Claude writes catch edge cases I wouldn’t think of — accessibility states, empty data scenarios, race conditions in async operations.

08. The Mindset Shift

After 10+ years of building frontend at scale, here’s what I’ve learned about using Claude Code effectively: it’s not about the commands. It’s about treating Claude as a system you architect, not a chatbot you prompt.

The principal engineer’s job isn’t to write more code. It’s to make the right trade-offs, encode standards that scale, and build systems where the team (including Claude) produces consistently excellent output.

Claude Code is the first AI tool I’ve used where the investment in configuration actually pays compound returns. The CLAUDE.md you write today saves you from wrong patterns tomorrow. The skills you create this week save your team from inconsistency next month. The subagents you configure once handle the investigative work that used to eat your afternoons.

Start with /init. Refine your CLAUDE.md. Install the Callstack and Vercel skills. Set up one custom subagent. That's your first week. Everything else compounds from there.

Ship well. Ship fast. Ship with intent. ✌️

Claude Code for React & React Native: Workflows That Actually Move the Needle was originally published in Cars24 Engineering Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

CARS24's BFF layer now handles millions of requests across multiple countries, orchestrating data from multiple microservices. It powers superapp, home pages, car listings, search, checkout, and everything in between. When it works, nobody notices. When it fails, the business notices immediately.

These aren’t theoretical patterns from a side project. They’re solutions that survived the test of real traffic, real failures, and real business consequences. They’re the hard-won lessons from outages, incidents, and countless hours of debugging.

I won’t promise you’ll never face another production issue. But maybe, just maybe, you’ll recognise the warning signs a little earlier. You’ll avoid some of the mistakes we made. You’ll have a better mental model for why things fail in ways you never expected.

So grab your coffee (or tea, I don’t judge), and let’s dive into the messy, beautiful reality of building resilient systems in production. This is the story of what actually works, warts and all.

Welcome to the real world of BFF architecture. I’m glad you’re here

Problem #1: Promise.all() is a Footgun for Production BFFs

The Trap Everyone Falls Into

You learn about Promise.all() and think you're done with parallel execution:

const [users, orders, inventory] = await Promise.all([
  getUserData(userId),
  getOrders(userId),
  getInventory(userId)
]);

This works great until one service throws an error. Then everything fails.

In production, this means:

• Inventory service has a hiccup → entire user dashboard crashes
• One timeout → user sees error page
• Partial failures become total failures

The Real Solution: Layered Failure Handling

// Layer 1: Critical dependencies that MUST succeed
async function getCriticalData(userId) {
  try {
    return await Promise.all([
      getAuthContext(userId),
      getUserProfile(userId)
    ]);
  } catch (error) {
    // If critical fails, the request should fail
    throw new Error('Critical dependency failure');
  }
}

// Layer 2: Important but degradable dependencies
async function getImportantData(userId) {
  const results = await Promise.allSettled([
    getOrders(userId),
    getPaymentStatus(userId)
  ]);
  
  // Return what succeeded, log what failed
  return results.map((result, idx) => {
    if (result.status === 'fulfilled') {
      return result.value;
    }
    
    logger.warn({ 
      service: ['orders', 'payment'][idx],
      reason: result.reason.message 
    });
    return null;
  });
}

// Layer 3: Optional enrichments (fire and don't wait)
async function startOptionalEnrichments(userId, responseId) {
  // Don't await - let these run in background
  Promise.allSettled([
    getRecommendations(userId),
    trackAnalytics(userId),
    prefetchRelatedData(userId)
  ]).then(results => {
    // Push updates via WebSocket or cache for next request
    notifyClient(responseId, results.filter(r => r.status === 'fulfilled'));
  });
}

The key insight: Not all data needs to be in the initial response. Split your dependencies into:

1. Blocking critical (must have)
2. Blocking degradable (nice to have in response, handle failures)
3. Non-blocking (can arrive later via WebSocket/polling)

This pattern reduced our error rate from 15% to <1% during downstream instability.

Problem #2: Axios Timeout Doesn’t Actually Cancel Requests

The Misconception

await axios.get(url, { timeout: 1000 });

What developers think: “Request will be cancelled after 1 second”

What actually happens:

• Promise rejects after 1 second ✓
• Socket connection stays open ✗
• Memory isn’t freed ✗
• Database connection on the downstream service keeps running ✗

Under load, this causes:

• Socket pool exhaustion
• Memory leaks
• Cascading failures on downstream services
• “Connection reset by peer” errors

The Actual Solution: AbortController + Proper Cleanup

class ServiceClient {
  constructor(baseURL, defaultTimeout = 1000) {
    this.axios = axios.create({
      baseURL,
      httpAgent: new http.Agent({
        keepAlive: true,
        keepAliveMsecs: 30000,
        maxSockets: 50,
        maxFreeSockets: 10,
        timeout: 60000  // Socket timeout (different from request timeout)
      })
    });
  }
  
  async request(url, options = {}) {
    const timeout = options.timeout || this.defaultTimeout;
    const controller = new AbortController();
    
    const timeoutId = setTimeout(() => {
      controller.abort();
      logger.warn({
        url,
        timeout,
        message: 'Request aborted due to timeout'
      });
    }, timeout);
    
    try {
      const response = await this.axios.get(url, {
        ...options,
        signal: controller.signal,
        timeout: timeout  // Still set axios timeout as fallback
      });
      
      return response.data;
    } catch (error) {
      // Differentiate timeout vs other errors
      if (axios.isCancel(error) || error.code === 'ECONNABORTED') {
        throw new TimeoutError(`Request to ${url} timed out after ${timeout}ms`);
      }
      throw error;
    } finally {
      clearTimeout(timeoutId);
      // AbortController cleanup is automatic, but clearing timeout prevents memory leaks
    }
  }
}

Critical details that must be remembered:

1. httpAgent.timeout vs axios.timeout:

• httpAgent.timeout: How long a socket can be idle before closure
• axios.timeout: Maximum time for the entire request
• You need both for different failure modes

2. AbortSignal actually cancels the underlying request:

• Closes the socket immediately
• Frees memory
• Stops waiting for response

3. Connection pooling matters:

• maxSockets: Limit concurrent connections per host
• keepAlive: Reuse TCP connections (massive perf win)
• Without pooling, you’ll hit EMFILE (too many open files) errors

This reduced our socket exhaustion incidents from daily to never.

Problem #3: The Event Loop Lag You Can’t See

The Silent Killer

Your BFF is serving requests fine. Latency looks good in metrics. Then suddenly during peak traffic:

• Timeouts spike
• Requests queue up
• Nothing appears to be CPU-bound in profiling

The culprit: Event loop blocking from unexpected sources

Common blockers we found:

// 1. Synchronous JSON parsing of large payloads
app.post('/upload', (req, res) => {
  const data = JSON.parse(req.body);  // Blocks if body is 10MB+
});

// 2. Large object stringification in logging
logger.info('Response:', JSON.stringify(hugeObject));  // Blocks event loop

// 3. Regex on untrusted input
const matches = userInput.match(/complex.*regex/gi);  // Can be O(2^n)

// 4. Synchronous crypto operations
const hash = crypto.createHash('sha256').update(data).digest('hex');  // Blocks

The Solution: Measure and Offload

First, make event loop lag visible:

const { performance } = require('perf_hooks');

class EventLoopMonitor {
  constructor(threshold = 50) {
    this.threshold = threshold;
    this.lastCheck = performance.now();
    
    setInterval(() => {
      const now = performance.now();
      const lag = now - this.lastCheck - 100;  // Expected interval is 100ms
      
      if (lag > this.threshold) {
        logger.warn({
          eventLoopLag: Math.round(lag),
          message: 'Event loop blocked'
        });
      }
      
      this.lastCheck = now;
    }, 100);
  }
}

// Start monitoring
new EventLoopMonitor(50);

Then offload blocking operations:

const { Worker } = require('worker_threads');

// worker.js
const { parentPort } = require('worker_threads');

parentPort.on('message', ({ action, data }) => {
  switch(action) {
    case 'parse-json':
      try {
        const parsed = JSON.parse(data);
        parentPort.postMessage({ success: true, result: parsed });
      } catch (error) {
        parentPort.postMessage({ success: false, error: error.message });
      }
      break;
      
    case 'hash-data':
      const hash = crypto.createHash('sha256').update(data).digest('hex');
      parentPort.postMessage({ success: true, result: hash });
      break;
  }
});

// main.js
class WorkerPool {
  constructor(workerPath, size = 4) {
    this.workers = Array.from({ length: size }, () => ({
      worker: new Worker(workerPath),
      busy: false
    }));
    this.queue = [];
  }
  
  async execute(action, data, timeout = 5000) {
    return new Promise((resolve, reject) => {
      const worker = this.workers.find(w => !w.busy);
      
      if (!worker) {
        // Queue if all workers busy
        this.queue.push({ action, data, resolve, reject });
        return;
      }
      
      worker.busy = true;
      
      const timeoutId = setTimeout(() => {
        worker.worker.terminate();  // Kill stuck worker
        worker.worker = new Worker(workerPath);  // Spawn new one
        worker.busy = false;
        reject(new Error('Worker timeout'));
        this.processQueue();
      }, timeout);
      
      worker.worker.once('message', (result) => {
        clearTimeout(timeoutId);
        worker.busy = false;
        
        if (result.success) {
          resolve(result.result);
        } else {
          reject(new Error(result.error));
        }
        
        this.processQueue();
      });
      
      worker.worker.postMessage({ action, data });
    });
  }
  
  processQueue() {
    if (this.queue.length === 0) return;
    
    const worker = this.workers.find(w => !w.busy);
    if (worker) {
      const task = this.queue.shift();
      this.execute(task.action, task.data)
        .then(task.resolve)
        .catch(task.reject);
    }
  }
}

// Usage
const workerPool = new WorkerPool('./worker.js');

app.post('/upload', async (req, res) => {
  try {
    const parsed = await workerPool.execute('parse-json', req.body);
    res.json({ success: true, data: parsed });
  } catch (error) {
    res.status(400).json({ error: error.message });
  }
});

When to use worker threads (our rule of thumb):

• JSON parsing/stringifying of objects >100KB
• Crypto operations on data >10KB
• Any synchronous operation taking >10ms in profiling
• Regex on untrusted user input

This reduced our P99 event loop lag from 300ms to <5ms.

You may use some 3rd party libs for managing the worker thread if its adding overhead to your application eg: Piscina, Workerpool

Problem #4: Cache Stampede During Downstream Outages

The Scenario

Your cache has a 5-minute TTL. Downstream service goes down. What happens?

async function getData(key) {
  const cached = await cache.get(key);
  if (cached) return cached;
  
  const fresh = await downstreamService.fetch(key);  // This fails
  await cache.set(key, fresh, 300);
  return fresh;
}

At scale:

1. Cache expires for popular key
2. 100 requests try to fetch simultaneously
3. All 100 requests hit the failing downstream
4. Downstream gets overwhelmed further
5. None of the requests cache the result (because fetch failed)
6. Next 100 requests repeat the cycle

This is a cache stampede amplified by downstream failure.

The Solution: Request Coalescing + Stale-While-Revalidate

class ResilientCache {
  constructor(redisClient) {
    this.cache = redisClient;
    this.inflightRequests = new Map();
  }
  
  async get(key, fetchFn, options = {}) {
    const { ttl = 300, staleWhileRevalidate = 600 } = options;
    
    // 1. Check cache
    const cached = await this.cache.get(key);
    
    if (cached) {
      const { data, cachedAt, staleAt } = JSON.parse(cached);
      const now = Date.now();
      
      // Fresh data - return immediately
      if (now < staleAt) {
        return data;
      }
      
      // Stale but within grace period - return stale, refresh in background
      if (now < cachedAt + staleWhileRevalidate * 1000) {
        // Fire and forget background refresh
        this.backgroundRefresh(key, fetchFn, ttl, staleWhileRevalidate)
          .catch(err => logger.warn({ key, error: err.message }));
        
        return data;  // Return stale data immediately
      }
    }
    
    // 2. Check if another request is already fetching this key
    if (this.inflightRequests.has(key)) {
      return this.inflightRequests.get(key);
    }
    
    // 3. Fetch fresh data (only one request does this)
    const fetchPromise = this.fetchAndCache(key, fetchFn, ttl, staleWhileRevalidate);
    this.inflightRequests.set(key, fetchPromise);
    
    try {
      const result = await fetchPromise;
      return result;
    } finally {
      this.inflightRequests.delete(key);
    }
  }
  
  async fetchAndCache(key, fetchFn, ttl, staleWhileRevalidate) {
    try {
      const data = await fetchFn();
      const now = Date.now();
      
      await this.cache.set(
        key,
        JSON.stringify({
          data,
          cachedAt: now,
          staleAt: now + ttl * 1000
        }),
        'EX',
        ttl + staleWhileRevalidate
      );
      
      return data;
    } catch (error) {
      // On fetch failure, try to return stale data even if expired
      // Note: For repeatedly failing services, consider adding a circuit breaker
      // to stop retry attempts temporarily and fail fast
      const stale = await this.cache.get(key);
      
      if (stale) {
        const { data } = JSON.parse(stale);
        logger.warn({
          key,
          message: 'Returning stale data due to fetch failure',
          error: error.message
        });
        return data;
      }
      
      throw error;
    }
  }
  
  async backgroundRefresh(key, fetchFn, ttl, staleWhileRevalidate) {
    try {
      await this.fetchAndCache(key, fetchFn, ttl, staleWhileRevalidate);
    } catch (error) {
      // Silently fail background refreshes
      logger.debug({ key, message: 'Background refresh failed' });
    }
  }
}

// Usage
const cache = new ResilientCache(redisClient);

async function getUserData(userId) {
  return cache.get(
    `user:${userId}`,
    () => userService.fetch(userId),
    { 
      ttl: 300,              // Fresh for 5 minutes
      staleWhileRevalidate: 600  // Serve stale for up to 10 more minutes
    }
  );
}

Why this works:

1. Request coalescing: Only one request fetches data for a key, others wait for that result
2. Stale-while-revalidate: During outages, serve stale data instead of failing
3. Background refresh: Users get instant responses with stale data while fresh data loads
4. Graceful degradation: System stays up even when downstream is completely down

This pattern eliminated our cache stampede incidents entirely and kept availability >99.9% even during downstream outages.

Problem #5: Memory Leaks from Forgotten Cleanup

The Subtle Leak

async function processWithTimeout(fn, timeout) {
  return Promise.race([
    fn(),
    new Promise((_, reject) => 
      setTimeout(() => reject(new Error('Timeout')), timeout)
    )
  ]);
}

This leaks memory. If fn() resolves after timeout, the setTimeout timer still exists. Over thousands of requests, you accumulate thousands of timers.

The Proper Pattern

async function processWithTimeout(fn, timeout) {
  let timeoutId;
  
  const timeoutPromise = new Promise((_, reject) => {
    timeoutId = setTimeout(() => reject(new Error('Timeout')), timeout);
  });
  
  try {
    return await Promise.race([fn(), timeoutPromise]);
  } finally {
    clearTimeout(timeoutId);  // Always cleanup
  }
}

Other common leak sources:

// Event listeners that aren't removed
class RequestHandler {
  constructor() {
    this.controller = new AbortController();
    
    // BAD: Listener never removed
    this.controller.signal.addEventListener('abort', () => {
      this.cleanup();
    });
  }
}

// GOOD: Remove listeners
class RequestHandler {
  constructor() {
    this.controller = new AbortController();
    this.abortHandler = () => this.cleanup();
    this.controller.signal.addEventListener('abort', this.abortHandler);
  }
  
  destroy() {
    this.controller.signal.removeEventListener('abort', this.abortHandler);
  }
}

// Axios interceptors that accumulate
// BAD: Adds a new interceptor on every request
app.use((req, res, next) => {
  axios.interceptors.request.use(config => {
    config.headers['X-Request-ID'] = req.id;
    return config;
  });
  next();
});

// GOOD: Add interceptor once at startup
const requestInterceptor = axios.interceptors.request.use(config => {
  config.headers['X-Request-ID'] = asyncLocalStorage.getStore()?.requestId;
  return config;
});

We found these leaks by running heap snapshots at 1-hour intervals and comparing:

// Memory profiling in staging
if (process.env.NODE_ENV === 'staging') {
  const v8 = require('v8');
  const fs = require('fs');
  
  setInterval(() => {
    const snapshot = v8.writeHeapSnapshot();
    logger.info({ heapSnapshot: snapshot });
  }, 3600000);  // Every hour
}

Problem #6: Logging at Scale Kills Performance

The Innocent Looking Code

logger.info('Request received', {
  userId: req.user.id,
  body: req.body,
  timestamp: new Date().toISOString()
});

At 1000 RPS:

• JSON.stringify(req.body) runs 1000 times/second
• If body is 50KB, that’s 50MB/s of serialization
• Blocks event loop 1–5ms per call
• Cumulative blocking: 1–5 seconds of event loop time per second

Your logs are causing the latency you’re logging about.

The Solution: Sampling + Async Logging

class SmartLogger {
  constructor(options = {}) {
    this.sampleRate = options.sampleRate || 0.1;  // Log 10% of requests
    this.alwaysLogErrors = options.alwaysLogErrors !== false;
    this.queue = [];
    this.flushInterval = options.flushInterval || 1000;
    
    // Async flush to transport
    setInterval(() => this.flush(), this.flushInterval);
  }
  
  shouldSample() {
    return Math.random() < this.sampleRate;
  }
  
  info(message, meta = {}) {
    // Sample normal requests
    if (!this.shouldSample()) return;
    
    this.queue.push({
      level: 'info',
      message,
      ...this.sanitizeMeta(meta),
      timestamp: Date.now()
    });
  }
  
  error(message, meta = {}) {
    // Always log errors
    this.queue.push({
      level: 'error',
      message,
      ...this.sanitizeMeta(meta),
      timestamp: Date.now()
    });
  }
  
  sanitizeMeta(meta) {
    // Don't log large objects - log their size instead
    return Object.entries(meta).reduce((acc, [key, value]) => {
      if (typeof value === 'object' && value !== null) {
        const size = Buffer.byteLength(JSON.stringify(value));
        acc[`${key}Size`] = size;
        
        // Only include full object if small
        if (size < 1024) {
          acc[key] = value;
        }
      } else {
        acc[key] = value;
      }
      return acc;
    }, {});
  }
  
  async flush() {
    if (this.queue.length === 0) return;
    
    const batch = this.queue.splice(0, this.queue.length);
    
    // Async write - doesn't block event loop
    setImmediate(() => {
      // Send to logging service
      this.transport.write(batch).catch(err => {
        console.error('Failed to flush logs:', err);
      });
    });
  }
}

// Usage with adaptive sampling
class AdaptiveLogger extends SmartLogger {
  constructor(options) {
    super(options);
    this.errorRate = 0;
    this.lastMinuteErrors = [];
  }
  
  error(message, meta) {
    super.error(message, meta);
    
    // Track error rate
    this.lastMinuteErrors.push(Date.now());
    this.lastMinuteErrors = this.lastMinuteErrors.filter(
      t => t > Date.now() - 60000
    );
    
    this.errorRate = this.lastMinuteErrors.length / 60;
    
    // Increase sampling when error rate is high
    if (this.errorRate > 10) {
      this.sampleRate = 1.0;  // Log everything
    } else if (this.errorRate > 5) {
      this.sampleRate = 0.5;  // Log 50%
    } else {
      this.sampleRate = 0.1;  // Log 10%
    }
  }
}

This reduced our logging overhead from 15% CPU to <2% CPU while maintaining debuggability.

The Complete BFF Request Pattern

const { AsyncLocalStorage } = require('async_hooks');
const asyncLocalStorage = new AsyncLocalStorage();

class BFFHandler {
  constructor() {
    this.cache = new ResilientCache(redis);
    this.logger = new AdaptiveLogger();
    this.workerPool = new WorkerPool('./worker.js');
  }
  
  async handleRequest(req, res) {
    const requestId = req.headers['x-request-id'] || generateId();
    const startTime = Date.now();
    
    // Store request context for access anywhere
    return asyncLocalStorage.run({ requestId }, async () => {
      try {
        const userId = req.user.id;
        
        // Phase 1: Critical data (must succeed)
        const critical = await this.getCriticalData(userId);
        
        // Phase 2: Important data (degrade gracefully)
        const important = await this.getImportantData(userId);
        
        // Phase 3: Optional data (fire and forget)
        this.startOptionalEnrichments(userId, requestId);
        
        // Phase 4: Transform (offload if needed)
        const response = await this.transformResponse(critical, important);
        
        // Log success
        this.logger.info('request_completed', {
          userId,
          latency: Date.now() - startTime,
          path: req.path
        });
        
        res.json(response);
        
      } catch (error) {
        this.logger.error('request_failed', {
          error: error.message,
          stack: error.stack,
          userId: req.user?.id,
          latency: Date.now() - startTime
        });
        
        res.status(500).json({ error: 'Internal server error' });
      }
    });
  }
  
  async getCriticalData(userId) {
    const timeout = 800;
    const controller = new AbortController();
    const timeoutId = setTimeout(() => controller.abort(), timeout);
    
    try {
      return await Promise.all([
        serviceClient.request('/auth', { userId, signal: controller.signal }),
        serviceClient.request('/profile', { userId, signal: controller.signal })
      ]);
    } finally {
      clearTimeout(timeoutId);
    }
  }
  
  async getImportantData(userId) {
    const results = await Promise.allSettled([
      this.cache.get(`orders:${userId}`, () => 
        serviceClient.request('/orders', { userId }), 
        { ttl: 60, staleWhileRevalidate: 300 }
      ),
      this.cache.get(`payment:${userId}`, () =>
        serviceClient.request('/payment', { userId }),
        { ttl: 30, staleWhileRevalidate: 120 }
      )
    ]);
    
    return results.map(r => r.status === 'fulfilled' ? r.value : null);
  }
  
  startOptionalEnrichments(userId, requestId) {
    Promise.allSettled([
      serviceClient.request('/recommendations', { userId }),
      serviceClient.request('/analytics', { userId })
    ]).then(results => {
      // Send via WebSocket or cache for next request
      this.notifyClient(requestId, results);
    });
  }
  
  async transformResponse(critical, important) {
    const combined = { ...critical, ...important };
    
    // Check if transformation is CPU-intensive
    const dataSize = Buffer.byteLength(JSON.stringify(combined));
    
    if (dataSize > 100000) {
      // Offload to worker thread
      return this.workerPool.execute('transform', combined);
    }
    
    // Simple transformation on main thread
    return this.transform(combined);
  }
}

Key Takeaways

1. Promise.all() vs Promise.allSettled() vs fire-and-forget — Know when to use each based on criticality
2. Timeouts need AbortController — Otherwise you’re not actually cancelling requests
3. Event loop lag is invisible — Instrument it explicitly or you’ll never know what’s blocking
4. Cache stampedes amplify outages — Use request coalescing + stale-while-revalidate
5. Memory leaks are cumulative — Always cleanup timers, listeners, and interceptors
6. Logging at scale requires sampling — Adaptive sampling based on error rate works well

Conclusion

These aren’t beginner problems. They’re the issues that emerge when “basic” Node.js patterns meet production traffic.

The difference between a BFF that handles 100rps and one that handles 10,000rps isn’t some magical framework; it’s understanding these failure modes and designing around them.

Most importantly: These patterns compound. Each one individually gives modest improvements. Together, they’re the difference between a system that falls over and one that stays up.

If this helped you pause, reflect, and look at your systems with a little more care, do give it a clap.

Building Resilient Node.js BFFs at Scale: Hard-Earned Lessons from Production was originally published in Cars24 Engineering Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

As the CARS24 product scaled across web and mobile, a familiar problem emerged not performance, not tooling, but logic drift.

The same business rules were being re-implemented in React and React Native. Edge cases behaved slightly differently. Fixes landed on one platform and lagged on the other. Engineers spent more time coordinating correctness than delivering features.

This wasn’t a people problem. It was a structural problem.

React and React Native are excellent delivery layers. But once validation, orchestration, and decision-making logic starts living inside UI code, platforms slowly become owners of business correctness. Duplication becomes inevitable, and consistency becomes a coordination exercise.

This post describes how we moved business logic out of platforms entirely and what changed once the domain became the single source of truth.

Architectural Goal

The architectural goal was deliberately simple:

Define business rules once. Execute them everywhere.

Instead of asking “how do we keep web and mobile in sync?”, we asked a different question:

What if platforms were no longer responsible for correctness at all?

To achieve this, we introduced a shared, platform-agnostic domain layer that:

• Explicitly models business concepts
• Exposes behavior through use cases
• Is consumed uniformly by web and mobile

Once in place, platform teams could move independently — without fear of drifting business behavior. Core Design Principle: Domain Ownership Over Platform Ownership

Traditional frontend architectures often split responsibility like this:

web/
mobile/

In practice, this means:

• Validation logic lives inside components
• Edge cases are handled locally
• Business correctness is enforced socially, not structurally

Over time, platforms stop being delivery layers and start becoming business rule engines.

We intentionally broke this model.

Instead, we introduced explicit domain ownership:

shared-domain/
  domain/
  application/
  ports/

In this structure:

• The domain owns correctness
• Platforms own rendering and interaction
• Dependencies flow inward and never outward

This single decision removed an entire category of coordination overhead.

Domain Layer: Explicit Business Concepts

Domain entities represent what the business is, not how it is displayed.

export class Vehicle {
  constructor(private readonly props: VehicleProps) {
    if (!props.id) throw new Error('Vehicle id is required');
    if (!props.title) throw new Error('Vehicle title is required');
    Object.freeze(this.props);
  }
  get id() { return this.props.id; }
  get title() { return this.props.title; }
}

Why this matters once implemented

• Certain classes of invalid states are prevented at construction time.
• Business rules are enforced at creation boundaries
• UI layers cannot accidentally corrupt domain data
• The same conceptual model can be reused, even if implementations differ.

Many mutation and state-corruption bugs are eliminated.

Application Layer: Use Cases as the System API

Use cases define what the system can do.

export class GetVehicleDetailsUseCase {
  constructor(private repo: VehicleRepoPort) {}
  async execute(ctx: PlatformContextPort, input: Input) {
    if (!input.vehicleId) {
      throw new Error('vehicleId is required');
    }
    return {
      vehicle: await this.repo.getVehicleDetails(input.vehicleId, ctx),
    };
  }
}

What this gives you structurally

• A clear, discoverable application API
• No business logic inside UI components
• Consistent business outcomes across platforms.
• Testable logic without platform dependencies

Once implemented, feature discussions shift from “where do we code this?” to “what is the correct use case?”.

Ports: Stable Contracts at the Boundary

Ports define what the application needs, not how it is fulfilled.

export interface VehicleRepoPort {
  getVehicleDetails(id: string, ctx: PlatformContextPort): Promise<Vehicle>;
}

Platform-specific adapters implement these contracts.

Web Adapter

class VehicleRepoWeb implements VehicleRepoPort {
  async getVehicleDetails(id) {
    const res = await fetch(`/api/vehicles/${id}`);
    return new Vehicle(await res.json());
  }
}

Mobile Adapter

class VehicleRepoMobile implements VehicleRepoPort {
  async getVehicleDetails(id) {
    const cached = await AsyncStorage.getItem(id);
    if (cached) return new Vehicle(JSON.parse(cached));
    // fallback to API
  }
}

Why this works long-term

• Infrastructure decisions remain local to platforms
• Business logic never changes when transport changes
• Offline, caching, and performance strategies evolve independently

Once ports are in place, platform evolution stops leaking into business logic.

Platform Context: Explicit and Controlled Variance

When platform-specific behavior is genuinely required, we pass it explicitly.

export interface PlatformContextPort {
  platform: 'web' | 'ios' | 'android';
  dimensions?: { width: number; height: number };
}

Structural benefits

• Platform branching is intentional, not accidental
• Use cases remain deterministic and reviewable
• Platform-specific logic is isolated and auditable

Most use cases never need this — when they do, the dependency is visible.

Shared Logic Example: Filtering System

We implemented complex filter logic entirely within the domain:

• Operator resolution
• Query composition
• Grouped filter interpretation

Both platforms consume this logic and render it differently.

What this guarantees

• Identical filtering behavior across platforms
• Single-point fixes for edge cases
• UI teams focus purely on interaction and UX

Once implemented, platform-specific filter bugs stop occurring by design.

Consumption Model: Thin UI Layers

React

useCase.execute(ctx, { vehicleId }).then(setVehicle);

React Native

useCase.execute(ctx, { vehicleId }).then(setVehicle);

Why this scales

• UI components remain declarative
• State transitions are predictable
• Business logic changes do not ripple through UI code

The UI becomes a true presentation layer.

Dependency Injection at the Boundary

export function createContainer(repo: VehicleRepoPort) {
  return {
    getVehicleDetails: new GetVehicleDetailsUseCase(repo),
  };
}

Dependencies are resolved once, at app startup.

Structural advantages

• Easy test substitution
• No hidden singletons
• Explicit dependency graphs

Testing: Business Logic as a First-Class Citizen

class MockVehicleRepo implements VehicleRepoPort {
  async getVehicleDetails() {
    return new Vehicle({ id: '1', title: 'Test Car', make: 'Toyota', model: 'Camry', year: 2023 });
  }
}

What this enables

• Fast, deterministic tests
• No network or platform mocking
• High confidence in business rules

Once implemented, testing shifts from integration-heavy to logic-first.

What Teams Get Once This Is in Place

This architecture guarantees:

• Single source of truth for business rules
• Predictable cross-platform behavior
• Lower cognitive load for engineers
• Safer refactors with localized impact
• Faster onboarding through clear boundaries

Velocity improves not by pushing harder but by removing structural friction.

Adoption Strategy

This architecture is designed to be introduced:

• Incrementally
• Feature-by-feature
• Without pausing delivery

Teams naturally adopt it once the benefits become apparent.

Conclusion

This domain-driven frontend architecture is not about abstraction for its own sake.
It is about clear ownership, explicit boundaries, and predictable behavior at scale.

By treating React and React Native as delivery layers and the domain as the source of truth, teams achieve:

• Alignment without constant coordination
• Quality without duplication
• Velocity without shortcuts

Once adopted, this pattern quietly becomes foundational.

Not because it’s clever but because it removes friction engineers didn’t realise they were carrying.

If you believe business rules shouldn’t depend on UI frameworks, share this with your team and leave a 👏 to keep the conversation going.

Sharing Business Logic Across React and React Native Using Domain-Driven Design was originally published in Cars24 Engineering Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Nobody likes a sluggish app. Users expect instant responses — whether they’re scrolling, tapping, or buying their next dream car. A slow app? That’s a one-way ticket to frustration and the uninstall button. But there’s a secret weapon to keep your app fast, efficient, and buttery smooth: Caching!

55% of the users will blame the mobile app for the performance issues, no matter the actual cause; while 37% of the users who experience a mobile app that crashed or froze will think less of the company that made the app

What are the key challenges for app performance

Not all users have access to high-speed WiFi or unlimited 5G. Many depend on unstable connections and data plans with strict limits (specially in developing countries). Additionally, mobile devices have limited processing power, making every optimisation crucial. Here’s what you’re dealing with

• Network Latency: Fetching data from servers takes time, especially on slow networks. In turn making the application slow and thus impacting user experience.
• Battery Drain: Excessive API calls and processing can be a battery killer.
• Data Costs: A data-hungry app might send users running for cheaper alternatives. You certainly do not want that!
• App Freezes & Crashes: Poor performance equals bad user experience (and bad reviews!).

Caching to the rescue

What is Caching?

Imagine you’re ordering a pizza from your favourite restaurant. The first time you call, you provide your address, favourite toppings, and crust preference. It takes 30 minutes to get your pizza. Now, what if you call again tomorrow and order the same pizza? Instead of asking for all your details again, the restaurant remembers (caches) your information, making the process faster. This is caching — storing frequently used data so that it can be retrieved quickly without reprocessing the request.

Why Caching is a Game-changer

• Lower data consumption: Caching allows apps to function better in lower network or unstable network conditions by serving locally stored data instead of making repeated API calls.
• Faster loading time & Smoother, more responsive UI: Apps that load instantly and provide smooth navigation retain users better. Studies show that a 1-second delay in load time can lead to a 7% drop in conversions [A metric that is used for web but we can assume the same here as user responsiveness is similar].
• Boosts battery efficiency: Frequent API requests and image loads can drain a device’s battery quickly. Caching reduces network calls and CPU usage, leading to a more energy-efficient application.

Determining what to cache depends on your app’s needs. There is no universal answer; it must be tailored to your specific use case. If your app is image-heavy, prioritising an image caching strategy is crucial. On the other hand, if your app relies on multiple API calls at launch (5 to 10 or more), you should strongly consider caching API responses using libraries like react-query or WatermelonDB. These tools ensure efficient data handling, reducing load times and enhancing user experience while avoiding stale data issues. Touching point on few strategies that I commonly use as a practice.

1. Caching Images

Images are one of the most commonly cached assets in apps. Imagine you’re browsing a car showroom’s online catalog. If you had to download high-quality car images every time you opened the app, it would be slow and waste internet data. Instead, your phone caches (saves) these images so that the next time you visit, they load instantly.

Using an efficient caching library like react-native-fast-image ensures that car images load instantly without repeated downloads, giving you a smooth user experience.

// ForDevelopers
import FastImage from 'react-native-fast-image';

const CachedImage = ({ uri }) => {
  return (
    <FastImage
      style={{ width: 100, height: 100 }}
      source={{ uri }}
      resizeMode={FastImage.resizeMode.cover}
    />
  );
};

FastImage provides different caching modes such as immutable, web, and cacheOnly, allowing developers to optimise caching behavior based on their needs. Choosing the right cache control ensures minimal redundant network requests while keeping images up-to-date.
In conjunction with this, invest in a good CDN that dynamically serves optimised images tailored to the device’s resolution and screen density, reducing load times and bandwidth usage eg: Akamai, CacheFly, cloudflare, fastly etc.

2. Caching API Responses

Imagine a pizza delivery app where the server acts like an overly enthusiastic waiter who keeps running to the kitchen every five seconds yelling, “Any new orders?!” The chefs are overwhelmed, orders are delayed, and chaos ensues. Now, introduce caching — it’s like giving the waiter a notepad where they jot down the last known orders, so they can just glance at it instead of sprinting back and forth. Meanwhile, in the background, the app quietly checks for updates without disturbing the already stressed-out digital kitchen.

Latest libs like react-query make this process effortless, ensuring fast load times and keeping the users (and the kitchen) happy.

// ForDevelopers
import { QueryClient, QueryClientProvider, useQuery } from 'react-query';
import axios from 'axios';

const queryClient = new QueryClient();
const fetchPosts = async () => {
  const { data } = await axios.get('https://jsonplaceholder.typicode.com/posts');
  return data;
};
const Posts = () => {
  const { data, error, isLoading } = useQuery('posts', fetchPosts, {
    staleTime: 1000 * 60 * 5, // Cache API data for 5 minutes
    cacheTime: 1000 * 60 * 10, // Data stays in cache for 10 minutes
  });
  if (isLoading) return <Text>Loading...</Text>;
  if (error) return <Text>Error fetching posts</Text>;
  return data.map(post => <Text key={post.id}>{post.title}</Text>);
};
const App = () => (
  <QueryClientProvider client={queryClient}>
    <Posts />
  </QueryClientProvider>
);

You can also try out SWR(Stale-While-Revalidate) which is a data-fetching library that provides a simple and efficient caching mechanism. It follows a strategy where it first returns cached (stale) data, then fetches the latest data in the background (revalidate), and finally updates the UI when fresh data arrives.

// ForDevelopers
import useSWR, { mutate } from 'swr';

const { data, error } = useSWR('https://api.example.com/cars', fetcher, {
  refreshInterval: 5000, // Fetch new data every 5 seconds
});

// Update cache without re-fetching
mutate('https://api.example.com/cars', [...data, newCar], false);

// Offline first approach - Show last available data if offline
const { data, error } = useSWR('https://api.example.com/cars', fetcher, {
  fallbackData: cachedData, 
});

3. Caching Database Queries

React Native apps using local databases (e.g., SQLite, WatermelonDB, or MMKV) can optimize query performance by leveraging in-memory caching, indexing, and background synchronisation. WatermelonDB, for example, ensures offline-first functionality with real-time sync capabilities, while MMKV provides ultra-fast key-value storage for frequently accessed data, enhancing app responsiveness.

// ForDevelopers
import { Database } from '@nozbe/watermelondb';
import SQLiteAdapter from '@nozbe/watermelondb/adapters/sqlite';
import schema from './model/schema';
import Post from './model/Post';

const adapter = new SQLiteAdapter({ schema });
const database = new Database({ adapter, modelClasses: [Post] });

const fetchPosts = async () => {
  const posts = await database.get('posts').query().fetch();
  return posts;
};

// ForDevelopers
import SQLite from 'react-native-sqlite-storage';

const db = SQLite.openDatabase({ name: 'mydb.db', location: 'default' });

const getCachedData = (query, params = []) => {
  return new Promise((resolve, reject) => {
    db.transaction((tx) => {
      tx.executeSql(query, params, (_, results) => resolve(results.rows.raw()), reject);
    });
  });
};

4. Caching UI Elements

Dynamic UI components such as lists and grids should use virtualisation techniques to minimise rendering overhead. React Native provides hooks like useMemo useCallback and React.memo which assists in setting up caching of UI.

// ForDevelopers
const renderItem = useCallback(({item}) => (
   <View key={item.key}>
      <Text>{item.title}</Text>
   </View>
 ), []);

return (
  <FlatList data={items} renderItem={renderItem} />;
);

// ForDevelopers
import React, {memo} from 'react';
import {View, Text} from 'react-native';

const MyListItem = memo(
  ({title}: {title: string}) => (
    <View>
      <Text>{title}</Text>
    </View>
  ),
  (prevProps, nextProps) => {
    return prevProps.title === nextProps.title;
  },
);

export default MyListItem;

Best Practices for Effective Caching

1. Define a Caching Strategy — Identify critical resources and define clear expiration rules. [Some samples shared above]
2. Use Appropriate Storage Mechanisms — Choose between in-memory caching, local databases, or disk storage based on data type and usage
3. Implement Cache Invalidation — Regularly refresh stale data using proper eviction policies such as LRU (Least Recently Used)
4. Monitor — Use analytics to track cache hit/miss ratios and adjust cache policies accordingly. You can use tools like Sentry / bugsnag / rollbar / embrace etc.
5. Ensure Security — Avoid caching sensitive user data or encrypt cache storage to prevent leaks. Use keychain / keystore / EncryptedSharedPreferences to store sensitive data.

Conclusion

Caching is both a boon and a bane. When implemented wisely, it can be a game-changer, significantly enhancing app performance and user experience. However, if mismanaged, it can lead to outdated data, memory bloat, and unexpected bugs, ultimately degrading the app’s reliability.

By following best practices and continuously optimising caching mechanisms, you can strike the right balance between performance and reliability, delivering a seamless experience to users.

So, is caching a boon or a bane? The answer lies in how you use it!

If you like this please subscribe for more such content. Happy Coding!

Caching in ReactNative apps — Boon or Bane? was originally published in Cars24 Engineering Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is React Native?

A framework developed and promoted by Facebook contains all the goods of web and React and bundles it for cross-platform mobile and web application development.

How does it affect your application development?

Unlike Native Development, where you write code individually for iOS (swift/Obj C) and Android (Kotlin/Java), RN gets powered by JS and uses a single code base to render the UI. In addition to this, it also gives you the discretion to write code on the native side (iOS and Android) if need be.

BENEFITS

1. Faster time to market and high execution speed: Building applications with a single code base gives you more power to develop features in a centralized place. So launching to market is done faster.
2. Fewer resources required for the same amount of work: It cut short the dependencies of having multiple teams doing redundant development for both platforms.
3. Mingle with website codebase: You get the power to reuse the code written in a React Website. It helps you to reduce the time of development and easy rollout of sprints.
4. Growing community: The day by day increasing RN community gives us a cutting edge over other platforms’ application development tools. The latest updates in RN have increased the build creation speed and added better debugging tools.
5. Power of Native is still there: In need of an hour, you can use the native side of mobile development. For some heavy lifting operations, it does come in handy.
6. On the fly changes: The most powerful tool that comes along with RN is appcenter code push that enables you to push your bundle/changes live without deploying your application again and going through that exhausting review process, primarily from Apple.

Also, ReactNative now provides ReactNative web, and by switching to RN web, we can use the same codebase to create websites, thus gives us more freedom to explore web options and be fast in execution if our goal is to build web apps. I will not stress it as this blog is more in comparison with Native app development.

It is hard to coin everything or every aspect of the actual requirement at hand. Selecting the right tech stack is always a challenge; mobile developers or managers have the above-stated points as their primary objective while picking up any tech stack.

Why go with React Native

1. Faster execution and time to market
2. Fewer resources at the disposal
3. Have the same scope defining for both platforms (iOS and Android)
4. Want to have more focus on more immediate maintenance

Why go with Native Application

1. When you already have a team of experts in both areas (iOS and Android). More resources in hand.
2. Have time in hand to execute things
3. Willing to maintain multiple code base for the exact scope of work
4. Want to perform some heavy lifting jobs like running AR/VR induced screens or rendering 3D spaces in the app.

CONCLUSION:

With growing technologies, companies have started following the mobile-first approach, and everyone is aiming to launch apps first to market. I feel that it’s inefficient to maintain three different code bases of the web, iOS, and Android with this intent in mind. With this growing tech, we need better solutions to handle this in one centralized place and give the same or better results. React Native is one such approach that can surely provide an edge in terms of productivity (faster time to market as execution speed increases with one centralized codebase), quality (maintenance of the code becomes easy), and scope (not to worry about redundant development in multiple platforms)

If you like this article please don’t forget to press on 👏.