DEV Community: Subrata Kumar Das

Subra AI: Private Offline On-Device AI

Subrata Kumar Das — Fri, 24 Jul 2026 12:39:23 +0000

Synchronous TurboModules Are Not Automatically Fast

Subrata Kumar Das — Wed, 15 Jul 2026 05:14:04 +0000

React Native’s New Architecture gives JavaScript more direct access to native functionality.

One important capability is synchronous communication through TurboModules.

That can be useful.

It can also introduce a performance problem that is easy to miss:

A native method being synchronous does not mean the native work is fast.

The communication mechanism may be efficient, but the JavaScript thread must still wait for the native operation to finish.

That difference matters in production applications.

The misleading simplicity of a synchronous API

Consider a native method exposed like this:

const token = SecureStorage.getAccessToken();

From the JavaScript side, it looks harmless.

There is no await, no callback and no visible asynchronous workflow.

The value is returned immediately from the developer’s point of view.

But the native implementation may perform several operations before returning:

access Android Keystore or iOS Keychain
decrypt stored data
read from disk
parse JSON
convert native objects into JavaScript-compatible values
communicate with another system service

If this work takes time, JavaScript cannot continue until the method returns.

The API looks simple.

The execution may not be.

What synchronous actually means

A synchronous call means the caller waits for the result.

For example:

const result = NativeModule.getValue();

renderScreen(result);

renderScreen cannot begin until getValue() finishes.

That behaviour is acceptable when the native operation is extremely small and predictable.

It becomes dangerous when the operation has variable latency.

The same method may take:

less than one millisecond when data is cached
several milliseconds when data requires conversion
much longer when storage, cryptography or system services are involved

The JavaScript thread does not care why the native method is delayed.

It simply remains blocked.

Why this affects React Native performance

React Native applications perform important work on the JavaScript thread.

This can include:

processing state updates
running application logic
handling user interactions
preparing React renders
coordinating navigation
executing animation-related JavaScript
responding to events from native modules

When a synchronous native method blocks that thread, other JavaScript work must wait.

A single call may not create an obvious problem.

Repeated calls can.

Imagine that a component reads a secure value during rendering:

function AccountScreen() {
  const token = SecureStorage.getAccessToken();

  return <AccountDetails token={token} />;
}

Now imagine that the component renders multiple times during navigation or state updates.

Every render may trigger another native operation.

If the method accesses storage and performs decryption, the application is repeatedly blocking the JavaScript thread inside the render path.

The visible result may be:

slow navigation
delayed button responses
dropped animation frames
inconsistent screen transitions
temporary UI freezes
performance that becomes worse on lower-end devices

The developer may initially investigate React re-renders.

The real problem is the synchronous native work performed during those renders.

TurboModules reduce overhead, not execution cost

This is the central distinction.

TurboModules improve how JavaScript and native code communicate.

They can reduce some of the overhead associated with the older bridge architecture.

But TurboModules do not make the native operation itself free.

Suppose a native method performs three tasks:

Read secure storage
        ↓
Decrypt the value
        ↓
Convert it into a JavaScript object

The communication layer may be efficient.

The application must still pay for:

storage access
cryptographic processing
object allocation
data conversion
thread coordination

Optimising the path between JavaScript and native code does not eliminate the work happening at the destination.

A faster doorway does not make the room behind it smaller.

When synchronous native methods are appropriate

Synchronous methods are useful when the operation is:

tiny
deterministic
memory-resident
frequently required
guaranteed not to perform slow I/O
predictable across supported devices

Examples may include reading a cached capability:

const supportsBiometrics = DeviceCapabilities.hasBiometricHardware();

Or checking a native constant:

const environment = AppConfiguration.getEnvironment();

Or performing a very small calculation:

const pixels = DisplayUtils.dpToPixels(16);

These operations are generally suitable only when their native implementation remains lightweight.

The important question is not whether the return type is small.

The important question is how the value is produced.

Returning one boolean can still be expensive if the implementation queries a system service every time.

Operations that should usually remain asynchronous

Native methods should normally be asynchronous when they involve:

Storage

const profile = await SecureStorage.getProfile();

Disk and secure-storage access may have unpredictable latency.

Cryptography

const decryptedPayload = await CryptoModule.decrypt(payload);

Cryptographic work can become expensive depending on the algorithm and input size.

Networking

const response = await NativeNetworkClient.fetchConfiguration();

Network operations are naturally unpredictable and should never block JavaScript synchronously.

Large data conversion

const records = await NativeDatabase.getRecords();

Converting thousands of native records into JavaScript objects can consume considerable time.

Image and file processing

const result = await ImageProcessor.compress(filePath);

Media processing is computationally expensive and should normally run away from latency-sensitive application work.

System services

const location = await LocationModule.getCurrentPosition();

The response time may depend on permissions, sensors, device state and operating-system behaviour.

Avoid synchronous work inside rendering

One of the strongest review rules is:

Do not perform synchronous native work inside a React render path unless the operation is proven to be trivial.

This is risky:

function Dashboard() {
  const settings = NativeSettings.getSettings();

  return <DashboardContent settings={settings} />;
}

A better design is to load the value asynchronously and store it in application state:

function Dashboard() {
  const [settings, setSettings] = useState<Settings | null>(null);

  useEffect(() => {
    let active = true;

    async function loadSettings() {
      const value = await NativeSettings.getSettings();

      if (active) {
        setSettings(value);
      }
    }

    loadSettings();

    return () => {
      active = false;
    };
  }, []);

  if (!settings) {
    return <LoadingScreen />;
  }

  return <DashboardContent settings={settings} />;
}

The exact state-management approach may differ.

The principle remains the same:

Do not make rendering wait for native storage, cryptography or system resources.

Cache deliberately, not accidentally

Sometimes a synchronous API is created because the application needs immediate access to a value.

The safer solution may be to load the value earlier and maintain an in-memory cache.

For example:

class SessionStore {
  private token: string | null = null;

  async initialise(): Promise<void> {
    this.token = await SecureStorage.getAccessToken();
  }

  getCachedToken(): string | null {
    return this.token;
  }
}

The native storage operation remains asynchronous:

await sessionStore.initialise();

Later reads are synchronous because they access application memory:

const token = sessionStore.getCachedToken();

This creates a meaningful distinction:

loading from storage is asynchronous
reading an already-loaded value is synchronous

That is much safer than hiding storage access behind a synchronous API.

However, caching introduces its own responsibilities:

cache invalidation
logout handling
token refresh
memory lifecycle
multi-process consistency
protection of sensitive values

The goal is not to make everything synchronous.

The goal is to place expensive work outside latency-sensitive paths.

Measure the whole native method

A common performance mistake is to measure only JavaScript execution.

For example:

const start = performance.now();

const token = SecureStorage.getAccessToken();

console.log(`Completed in ${performance.now() - start} ms`);

This can reveal blocking time from the JavaScript side.

But deeper investigation may require native instrumentation.

On Android, developers can measure sections using native timing tools or platform profilers.

On iOS, Instruments can help identify time spent in storage, cryptography, object conversion and thread blocking.

The useful questions are:

How long does the method take on average?
What is the worst observed latency?
Does the duration change when the value is not cached?
Does the method perform disk access?
Does it allocate or convert large objects?
Is it called during rendering or navigation?
How many times is it called during one user action?
How does it behave on lower-end devices?

Average timing alone is not enough.

A method that normally completes quickly but occasionally blocks for 40 milliseconds can still create visible UI problems.

Watch for repeated synchronous calls

The cost of one method call may appear acceptable.

The call frequency may be the actual problem.

Consider:

items.map(item => NativeFormatter.format(item));

If there are 500 items, the application performs 500 synchronous native calls.

Even if each call takes only a fraction of a millisecond, the combined cost can become significant.

A stronger native API might process the entire collection:

const formattedItems = await NativeFormatter.formatBatch(items);

This can reduce:

repeated boundary crossings
repeated allocations
thread coordination
per-call conversion overhead

Batching is especially useful when working with:

database rows
image metadata
sensor records
BLE data
file lists
cryptographic operations
large arrays produced by native SDKs

The correct API shape often matters as much as the implementation.

Synchronous methods create architectural coupling

There is another risk beyond immediate performance.

A synchronous API can become slow later.

Version one may return an in-memory value:

getUserRegion(): string;

A future requirement may change the implementation:

read the region from encrypted storage
migrate an old value
consult remote configuration
query a native SDK
support multiple user profiles

The JavaScript interface remains synchronous, but the native responsibility has become heavier.

Now the team faces a difficult choice:

keep blocking JavaScript
introduce hidden caching
change the public API
maintain both synchronous and asynchronous versions

For values likely to require I/O in the future, starting with an asynchronous contract is often safer.

API design should consider how the operation may evolve, not only how it works today.

A practical decision rule

Before exposing a synchronous TurboModule method, ask:

Can this method always complete quickly without storage, networking, cryptography, large conversion or unpredictable system work?

If the answer is uncertain, use an asynchronous API.

A useful classification is:

Suitable for synchronous execution

constants
cached primitives
tiny calculations
in-memory flags
deterministic capability checks

Better suited for asynchronous execution

file access
secure storage
databases
networking
encryption and decryption
compression
image processing
large data conversion
hardware interaction
operating-system services

The method’s name is not enough.

Review the complete native execution path.

Code-review checklist

When reviewing a synchronous TurboModule method, check:

Does it perform disk or secure-storage access?
Does it call another SDK or system service?
Does it perform cryptography?
Can it return a large object or array?
Does it parse or serialise data?
Can its latency change based on device state?
Is it called during rendering?
Is it called repeatedly inside a loop?
Is the result already available in memory?
Could the method become more expensive later?

One concerning answer may be enough to reconsider the synchronous design.

Final takeaway

TurboModules can improve React Native’s native integration model.

They make direct and synchronous interactions possible where appropriate.

But capability should not become default behaviour.

The safest rule is:

Use synchronous native methods only for tiny, predictable and memory-resident operations.

Keep storage, cryptography, networking, large data processing and unpredictable system work asynchronous.

TurboModules reduce communication overhead.

They do not remove the cost of native execution.

Where have you seen a synchronous native method create unexpected UI latency in a React Native application?

Type Safety Stops at Runtime Boundaries in React Native

Subrata Kumar Das — Mon, 13 Jul 2026 14:31:13 +0000

TypeScript can make a React Native codebase safer.

It can catch missing properties, incorrect function arguments, invalid component props and many other mistakes before the application runs.

But TypeScript has one important limitation:

It cannot verify whether external data actually matches the type you assigned to it.

This becomes especially important in React Native because application data often crosses multiple runtime boundaries.

A value may come from:

a native Android module
an iOS native module
an API response
persisted storage
a deep link
remote configuration
an analytics SDK
an AI-generated JSON response

At each of these boundaries, the actual runtime value may differ from the TypeScript definition.

And TypeScript may not warn you.

A simple example

Assume a React Native application receives battery information from a native module.

type BatteryStatus = {
  level: number;
  isCharging: boolean;
};

The JavaScript layer expects a value like this:

const batteryStatus: BatteryStatus = {
  level: 82,
  isCharging: true,
};

This looks safe.

The level field is a number.

The isCharging field is a boolean.

Now imagine that the Android implementation changes and returns this instead:

{
  level: "82",
  isCharging: true
}

The level value is now a string.

At runtime, JavaScript receives:

typeof batteryStatus.level === "string";

But TypeScript may still believe that level is a number.

How can that happen?

Because the result may have been cast.

const batteryStatus =
  NativeModules.BatteryModule.getStatus() as BatteryStatus;

The cast tells TypeScript:

Trust me. This value is a BatteryStatus.

TypeScript accepts that instruction.

It does not inspect the Android or iOS runtime value.

Casting is not validation

This distinction is important.

A type cast changes what TypeScript believes.

It does not change or verify the actual value.

Consider this example:

const value = "82" as unknown as number;

TypeScript may allow the code.

But the runtime value is still a string.

console.log(typeof value);
// string

This is why the following assumption is dangerous:

const response = externalValue as ExpectedType;

The code may compile successfully while the application remains unsafe.

A better mental model is:

Casting changes the compiler's understanding. Validation checks reality.

Where the failure appears

Boundary problems do not always fail immediately.

That is one reason they can be difficult to diagnose.

The application may receive the incorrect value on one screen, store it in state and fail much later.

For example:

const nextLevel = batteryStatus.level + 10;

If level is a number:

82 + 10;
// 92

If level is a string:

"82" + 10;
// "8210"

The app may not crash.

It may simply produce the wrong result.

That is often worse because the problem can remain hidden.

The value may also fail during:

numeric comparisons
sorting
formatting
progress calculations
conditional rendering
database queries
analytics processing
business-rule evaluation

For example:

if (batteryStatus.level < 20) {
  showLowBatteryWarning();
}

JavaScript may coerce the value and produce a result.

But relying on implicit coercion makes application behaviour fragile.

Compile-time trust should stop at runtime boundaries

Inside a properly typed TypeScript system, values can usually be trusted.

For example:

function showBatteryStatus(status: BatteryStatus) {
  console.log(status.level);
}

If every caller passes a real BatteryStatus, the function is safe.

The problem begins when a value enters the system from outside.

That value has not been created or verified by TypeScript.

Therefore, the safer rule is:

Treat external values as unknown until they have been validated.

Instead of this:

const status =
  NativeModules.BatteryModule.getStatus() as BatteryStatus;

Prefer this:

const status: unknown =
  await NativeModules.BatteryModule.getStatus();

Now the application is forced to prove that the value is safe before using it.

Why `unknown` is better than `any`

Many boundary values are typed as any.

const response: any = await fetchBatteryStatus();

This removes most type protection.

You can access anything:

response.level;
response.invalidProperty;
response.anythingAtAll;

TypeScript will not stop you.

unknown behaves differently.

const response: unknown = await fetchBatteryStatus();

You cannot safely access its properties until you narrow the type.

response.level;
// TypeScript error

This may initially feel inconvenient.

But that inconvenience is useful.

It forces the code to validate the runtime value.

Manual runtime validation

A simple type guard can validate the native response.

type BatteryStatus = {
  level: number;
  isCharging: boolean;
};

function isBatteryStatus(value: unknown): value is BatteryStatus {
  if (typeof value !== "object" || value === null) {
    return false;
  }

  const candidate = value as Record<string, unknown>;

  return (
    typeof candidate.level === "number" &&
    typeof candidate.isCharging === "boolean"
  );
}

Now the boundary can be handled safely.

const rawStatus: unknown =
  await NativeModules.BatteryModule.getStatus();

if (!isBatteryStatus(rawStatus)) {
  throw new Error("Invalid battery status returned by native module");
}

const status: BatteryStatus = rawStatus;

console.log(status.level);

After the validation succeeds, TypeScript knows that rawStatus is a valid BatteryStatus.

This is a safe conversion from an untrusted value into a trusted application type.

Validate business rules, not only field types

Checking whether level is a number may not be enough.

The value may still be invalid.

{
  level: 400,
  isCharging: true
}

The shape is correct.

But a battery percentage of 400 is not valid.

A stronger validator should also verify allowed ranges.

function isBatteryStatus(value: unknown): value is BatteryStatus {
  if (typeof value !== "object" || value === null) {
    return false;
  }

  const candidate = value as Record<string, unknown>;

  return (
    typeof candidate.level === "number" &&
    candidate.level >= 0 &&
    candidate.level <= 100 &&
    typeof candidate.isCharging === "boolean"
  );
}

Runtime validation may need to check:

required fields
primitive types
allowed ranges
enum values
string formats
nested object shapes
array item types
mutually exclusive states
domain-specific rules

A structurally correct object can still be invalid for the application.

Using a schema validation library

Manual validation works well for small objects.

For larger payloads, a schema library can make the code easier to maintain.

A common approach is to define a schema and derive the TypeScript type from it.

For example, using Zod:

import { z } from "zod";

const BatteryStatusSchema = z.object({
  level: z.number().min(0).max(100),
  isCharging: z.boolean(),
});

type BatteryStatus = z.infer<typeof BatteryStatusSchema>;

The external value can then be parsed.

const rawStatus: unknown =
  await NativeModules.BatteryModule.getStatus();

const result = BatteryStatusSchema.safeParse(rawStatus);

if (!result.success) {
  console.error(result.error);
  throw new Error("Invalid battery status");
}

const status = result.data;

The important part is not the specific library.

The important part is the boundary discipline:

Receive untrusted data.
Validate it.
Convert it into a trusted type.
Use it inside the application.

Runtime boundaries in React Native

React Native applications contain more boundaries than many teams realise.

1. Native modules

Native modules may return different types across Android and iOS.

For example:

Android returns an integer
iOS returns a floating-point number
one platform returns null
the other platform omits the field
a native SDK returns a string representation

Generated TurboModule specifications can improve contract safety, but runtime validation may still be useful when data originates from external native SDKs, persisted native state or platform APIs.

2. Network responses

An API client may declare a generic response type:

const response = await api.get<User>("/user");

This does not guarantee that the server returned a valid User.

It only tells TypeScript how the code intends to use the response.

The backend may return:

{
  "id": "123",
  "age": "42"
}

while the application expects:

type User = {
  id: string;
  age: number;
};

API types are expectations until runtime validation confirms them.

3. Persisted storage

Data stored in AsyncStorage, MMKV, SQLite or another persistence layer can become stale.

The application model may change between releases.

An older app version may have saved:

{
  "theme": "dark"
}

A newer version may expect:

type Settings = {
  theme: "light" | "dark";
  fontScale: number;
};

Reading stored JSON and casting it directly can create hidden problems.

const settings =
  JSON.parse(storedValue) as Settings;

Parsing confirms only that the value is valid JSON.

It does not confirm that it matches Settings.

4. Deep links

Deep-link parameters are external input.

A link may contain missing, malformed or unexpected values.

myapp://payment?amount=abc

The application should not assume that amount is a valid number merely because the navigation type expects one.

5. Remote configuration

Remote configuration can change without an application release.

A field that was previously boolean may accidentally be configured as a string.

{
  "newCheckoutEnabled": "true"
}

Without validation, the application may treat a non-empty string as truthy and enable behaviour unexpectedly.

6. AI-generated structured output

AI-generated JSON should always be treated as untrusted.

Even when a model is instructed to follow a specific schema, it may:

omit required fields
return additional fields
use incorrect enum values
produce malformed JSON
return numbers as strings
generate semantically invalid combinations

For example:

{
  "priority": "extremely_urgent",
  "retryCount": "-3"
}

The response may look structured while still violating the application contract.

AI output requires both structural validation and business-rule validation.

Validate once at the edge

Runtime validation should not be scattered throughout the entire application.

That creates repetitive and inconsistent checks.

A stronger architecture validates values at the edge.

async function getBatteryStatus(): Promise<BatteryStatus> {
  const rawStatus: unknown =
    await NativeModules.BatteryModule.getStatus();

  return BatteryStatusSchema.parse(rawStatus);
}

The rest of the application can now depend on the trusted function.

const status = await getBatteryStatus();

renderBatteryLevel(status.level);

This gives the codebase a clear separation:

Untrusted external data
        ↓
Boundary validation
        ↓
Trusted application model
        ↓
Business logic and UI

The validation cost is paid once.

The trusted type can then flow safely through the internal system.

Parse, do not merely check

In some cases, the application may intentionally transform external data.

Suppose the native module returns:

{
  level: "82",
  isCharging: true
}

The application may decide that numeric strings are acceptable.

Instead of rejecting the value, the boundary parser can normalise it.

function parseBatteryStatus(value: unknown): BatteryStatus {
  if (typeof value !== "object" || value === null) {
    throw new Error("Battery status must be an object");
  }

  const candidate = value as Record<string, unknown>;

  const level =
    typeof candidate.level === "string"
      ? Number(candidate.level)
      : candidate.level;

  if (
    typeof level !== "number" ||
    Number.isNaN(level) ||
    level < 0 ||
    level > 100
  ) {
    throw new Error("Invalid battery level");
  }

  if (typeof candidate.isCharging !== "boolean") {
    throw new Error("Invalid charging state");
  }

  return {
    level,
    isCharging: candidate.isCharging,
  };
}

This approach is often called parsing rather than validation.

Validation asks:

Is this value already valid?

Parsing asks:

Can this value be safely converted into the trusted form?

Both approaches are useful.

The choice should be explicit.

A practical code-review checklist

Whenever a value enters a React Native application, ask:

Where did this value come from?
Is the source controlled by the TypeScript compiler?
Is the value typed as any or cast using as?
What happens if a field is missing?
What happens if a number arrives as a string?
Are null and undefined handled differently?
Are allowed ranges and enum values checked?
Is validation performed once at the boundary?
Is the failure logged with enough context?
Can the application recover safely from invalid data?

These questions are especially important during:

native-module reviews
API integration
storage migrations
SDK upgrades
backend contract changes
AI feature development
platform-specific debugging

Final takeaway

TypeScript is excellent at preserving correctness inside a typed system.

But it does not control the values coming from outside that system.

A type definition describes what the application expects.

A type cast tells the compiler what to believe.

Runtime validation checks what the application actually received.

The engineering rule is simple:

Treat external values as unknown, validate them at the boundary and only then convert them into trusted application types.

Because in production React Native applications:

Casting is not validation.

Which runtime boundary has caused the most unexpected type failure in your React Native application?

Your Offline-First App Can Lose Correct Data Without Showing Any Error

Subrata Kumar Das — Sun, 12 Jul 2026 07:07:30 +0000

An offline-first application can complete synchronization successfully and still produce the wrong result.

The API may return 200 OK.

The local mutation queue may become empty.

The device may show that all changes are synchronized.

And yet, one valid update may have silently overwritten another.

This is one of the most dangerous offline-first failures because nothing appears broken technically.

There is no crash.

There is no network error.

There is no failed request.

The system behaves exactly as implemented.

The problem is that the implementation never defined which version of the data should win.

The Failure Scenario

Consider a maintenance application used by field technicians and supervisors.

A technician opens a maintenance request while working in an area with poor connectivity.

The current request contains:

{
  id: "REQ-1042",
  status: "OPEN",
  priority: "MEDIUM",
  notes: "Initial inspection pending",
  version: 4
}

The technician goes offline and updates the request:

{
  status: "IN_PROGRESS",
  notes: "Inspection started at the site"
}

Before the technician reconnects, a supervisor opens the same request through a web dashboard and changes the priority:

{
  priority: "HIGH",
  notes: "Potential safety risk reported"
}

Now two valid versions exist.

The technician’s device contains one valid update.

The server contains another valid update.

When the device reconnects, the mobile application sends its pending mutation.

The difficult question is not:

How do we upload the local data?

The difficult question is:

Which version should be trusted?

Why Last-Write-Wins Is Not Always Conflict Resolution

A common implementation compares timestamps and keeps the latest update.

This is known as last-write-wins.

For some fields, this may be acceptable.

For example:

a profile description
a temporary draft
a non-critical display preference
an editable note where losing an earlier version is acceptable

But last-write-wins becomes dangerous when the conflicting data includes:

approval status
inspection findings
financial values
compliance records
safety-related decisions
healthcare information
task ownership
inventory quantities

Imagine that the technician’s update is submitted five seconds after the supervisor’s update.

A timestamp-based strategy may replace the supervisor’s high-priority safety warning with the technician’s older local copy.

The synchronization request succeeds.

The server accepts the payload.

The local queue is cleared.

But an important update has been lost.

That is not a networking failure.

It is an architecture failure.

Offline-First Is a Business-Rules Problem

Offline-first architecture is often described using technical components:

SQLite or Realm
local persistence
mutation queues
retries
background synchronization
connectivity listeners
optimistic UI updates

These components are important.

But they only solve the mechanics of storing and transporting data.

They do not decide what should happen when two correct versions disagree.

That decision belongs to business rules.

Before building the synchronization engine, every important field or operation should have a conflict-resolution policy.

A useful starting point is to define four possible outcomes:

Merge
Reject
Overwrite
Review

1. Merge

Use merging when both updates can safely coexist.

Suppose the server contains:

{
  tags: ["electrical"]
}

The offline device adds:

{
  tags: ["urgent"]
}

Instead of replacing one array with the other, the system can merge them:

{
  tags: ["electrical", "urgent"]
}

Append-only activity logs are another good candidate for merging.

type ActivityEvent = {
  id: string;
  requestId: string;
  type: string;
  createdAt: string;
  createdBy: string;
};

Each action becomes a separate immutable event.

The system adds new events instead of replacing the complete history.

This makes synchronization safer because concurrent actions do not compete for ownership of the same record.

2. Reject

Some fields should be controlled only by the server.

For example:

{
  approvedBy: "manager-id",
  approvedAt: "2026-07-12T10:30:00Z",
  complianceStatus: "VERIFIED"
}

A mobile device should not be allowed to overwrite these values from an old local snapshot.

If an offline mutation contains server-owned fields, the backend should reject those parts of the update.

A field ownership model may look like this:

const fieldOwnership = {
  approvedBy: "server",
  approvedAt: "server",
  complianceStatus: "server",
  notes: "shared",
  description: "shared",
  localDraft: "client"
} as const;

The client can still display server-owned fields while offline.

But it should not treat them as locally authoritative.

3. Overwrite

Overwriting is acceptable when the business explicitly allows one side to win.

For example, a user may edit a local draft on multiple devices, and the product may intentionally use the latest saved version.

The important point is that overwrite should be a documented rule, not an accidental side effect.

Instead of saying:

The latest request happened to win.

The architecture should say:

This field uses last-write-wins because losing the earlier value is acceptable.

That difference matters.

An accidental overwrite is a bug.

An intentional overwrite is a policy.

4. Review

Some conflicts cannot be resolved safely by software.

Consider these two changes:

// Technician update
{
  inspectionResult: "SAFE"
}

// Supervisor update
{
  inspectionResult: "REQUIRES_REVIEW"
}

Automatically choosing either version may create operational risk.

The correct outcome may be to preserve both versions and require a person to resolve the conflict.

A conflict record could look like this:

type SyncConflict = {
  entityId: string;
  field: string;
  localValue: unknown;
  serverValue: unknown;
  localUpdatedAt: string;
  serverUpdatedAt: string;
  resolutionStatus: "PENDING" | "RESOLVED";
};

The application can show a dedicated conflict-resolution screen:

Inspection result changed in two places.

Local version:
SAFE

Server version:
REQUIRES_REVIEW

Choose a value or escalate for supervisor review.

This is less convenient than automatic synchronization.

But convenience should not override correctness for critical data.

Use Version Numbers, Not Only Timestamps

Timestamps are useful, but they are not always reliable enough for concurrency control.

Devices may have incorrect clocks.

Requests may be delayed.

Two updates may happen within the same timestamp precision.

A stronger approach is optimistic concurrency control using version numbers.

The server stores:

{
  id: "REQ-1042",
  status: "OPEN",
  version: 4
}

The client sends the version it originally edited:

PATCH /maintenance-requests/REQ-1042
If-Match: 4

The payload may contain:

{
  "status": "IN_PROGRESS"
}

If the server still has version 4, the mutation can be accepted.

The server updates the record to version 5.

If the server already has version 5, the client edited an outdated copy.

The server can return a conflict response:

409 Conflict

Example response:

{
  "code": "VERSION_CONFLICT",
  "currentVersion": 5,
  "serverRecord": {
    "id": "REQ-1042",
    "status": "OPEN",
    "priority": "HIGH",
    "version": 5
  }
}

The client now has enough information to merge, reject, overwrite or request human review.

A Simple React Native Mutation Queue

An offline mutation should contain more than an endpoint and payload.

It should also preserve the version that the user originally edited.

type PendingMutation = {
  id: string;
  entityType: "maintenanceRequest";
  entityId: string;
  operation: "UPDATE";
  baseVersion: number;
  changes: Record<string, unknown>;
  createdAt: string;
  retryCount: number;
};

Example mutation:

const mutation: PendingMutation = {
  id: "mutation-501",
  entityType: "maintenanceRequest",
  entityId: "REQ-1042",
  operation: "UPDATE",
  baseVersion: 4,
  changes: {
    status: "IN_PROGRESS",
    notes: "Inspection started at the site"
  },
  createdAt: new Date().toISOString(),
  retryCount: 0
};

During synchronization:

async function syncMutation(mutation: PendingMutation) {
  const response = await fetch(
    `/maintenance-requests/${mutation.entityId}`,
    {
      method: "PATCH",
      headers: {
        "Content-Type": "application/json",
        "If-Match": String(mutation.baseVersion)
      },
      body: JSON.stringify(mutation.changes)
    }
  );

  if (response.status === 409) {
    const conflict = await response.json();

    return {
      type: "CONFLICT",
      mutation,
      serverRecord: conflict.serverRecord
    };
  }

  if (!response.ok) {
    throw new Error(`Sync failed with status ${response.status}`);
  }

  return {
    type: "SUCCESS",
    record: await response.json()
  };
}

The important part is that a 409 Conflict should not be treated like a normal retryable network error.

Retrying the same request repeatedly will not resolve a semantic conflict.

The system needs a conflict-resolution rule.

Classify Sync Failures Correctly

Not every failed synchronization attempt means the same thing.

A useful classification is:

Network failure

Examples:

no connectivity
request timeout
DNS failure
temporary server unavailability

Action:

retry with backoff

Authentication failure

Examples:

expired token
revoked session
missing permission

Action:

refresh credentials or require authentication

Validation failure

Examples:

invalid field value
required field missing
unsupported state transition

Action:

show the user what must be corrected

Version conflict

Examples:

server record changed after the local copy was created
two users edited the same field
an approval occurred while the device was offline

Action:

merge, reject, overwrite or review

Treating all four categories as “sync failed” creates weak architecture and confusing user experiences.

Do Not Delete the Local Mutation Too Early

A dangerous synchronization pattern looks like this:

await sendMutation(mutation);
await removeMutationFromQueue(mutation.id);

This is safe only when the server has confirmed that the mutation was accepted and correctly applied.

The mutation should remain available when:

the server returns a conflict
only part of the payload was accepted
conflict review is pending
the response cannot be validated
the application crashes before local state is updated

A safer state machine might be:

type MutationStatus =
  | "PENDING"
  | "SYNCING"
  | "CONFLICT"
  | "FAILED"
  | "COMPLETED";

The queue entry should move to COMPLETED only after the client has processed the final server response.

Conflict Resolution Should Be Field-Aware

Record-level conflict resolution is often too broad.

Suppose the local version changes:

{
  notes: "Inspection completed"
}

At the same time, the server changes:

{
  priority: "HIGH"
}

These updates affect different fields.

Rejecting the entire local mutation would be unnecessary.

A field-aware merge can preserve both changes:

{
  notes: "Inspection completed",
  priority: "HIGH"
}

But consider this case:

// Local
{
  status: "COMPLETED"
}

// Server
{
  status: "CANCELLED"
}

Both updates affect the same field.

The conflict policy for status must now decide whether to:

reject the local transition
keep the server value
ask for review
apply a domain-specific state machine

This is why conflict resolution must understand business meaning, not only JSON structure.

Define the Rules Before Selecting the Database

Teams often begin offline-first discussions with questions such as:

Should we use Realm?
Should we use SQLite?
Should we use WatermelonDB?
How should we structure the retry queue?
Which connectivity library should we use?

These are useful implementation questions.

But they come after more important architecture questions:

Which fields are client-owned?
Which fields are server-owned?
Which operations are append-only?
Which fields can use last-write-wins?
Which conflicts require human review?
How long should unresolved conflicts be retained?
Can users continue editing while a conflict is pending?
What audit trail is required?

A database can persist conflicting data.

It cannot decide which version is correct.

A Practical Conflict-Policy Table

Before implementation, document the policy for important fields.

Field or Operation	Ownership	Resolution Strategy	Human Review
User notes	Shared	Last-write-wins or merge history	No
Approval status	Server	Reject local overwrite	Yes
Activity log	Append-only	Merge	No
Inspection result	Shared	Compare versions	Sometimes
Compliance status	Server	Server wins	Yes
Draft description	Client	Local overwrite allowed	No
Assigned technician	Server	Reject stale update	Yes

This table becomes a shared contract between:

mobile developers
backend developers
product managers
QA engineers
security teams
compliance stakeholders

Without this contract, each layer may implement a different interpretation of “sync.”

Questions to Ask During Architecture Review

Before calling an application offline-first, ask:

What happens when local and server records both change?
Does every mutation include a base version?
Which fields are controlled by the server?
Which data can be merged safely?
Which fields may use last-write-wins?
Which conflicts must be reviewed by a person?
Is conflict history preserved for auditing?
Can the user see when synchronization is blocked?
Are semantic conflicts separated from network failures?
When is a mutation permanently removed from the queue?

If the team cannot answer these questions, the application may support offline storage, but it does not yet have a complete offline-first architecture.

Final Takeaway

Offline-first architecture is not only about local databases, queues and retry mechanisms.

Those components answer:

How will data move when connectivity returns?

Conflict policies answer the more important question:

What should happen when two valid versions disagree?

Before building the synchronization engine, define four possible outcomes:

Merge. Reject. Overwrite. Review.

Make those decisions per field or operation.

Add version numbers to mutations.

Keep unresolved conflicts visible.

And never assume that a successful API response means the correct data survived.

Which field in your application would be dangerous to resolve using last-write-wins?

Your React Native Performance Problem May Actually Be a Memory Leak

Subrata Kumar Das — Sat, 11 Jul 2026 15:15:15 +0000

Your React Native Performance Problem May Actually Be a Memory Leak

A React Native screen can render correctly and still leak memory.

That is why some performance problems are misdiagnosed.

The app feels fine after launch.

Then, after repeated navigation:

screens become slower
callbacks fire more than once
background work keeps increasing
network listeners remain active
timers continue running
state updates happen after a screen has already unmounted

The first reaction is often:

“Let us optimise re-renders.”

But re-rendering may not be the real problem.

The actual issue may be that work created by old screens never stopped.

Why this is easy to misdiagnose

Many React Native performance issues are visible immediately.

A heavy component may:

render slowly
block the JavaScript thread
display a large list inefficiently
perform expensive calculations during render

Memory leaks often behave differently.

They usually appear gradually.

The first navigation works correctly.

The second also looks fine.

But after opening and closing the same screen multiple times, the application may start doing more work than expected.

That gradual degradation makes the issue look like a rendering problem, even when the rendering logic has not changed.

The important question is not only:

What is React rendering now?

You also need to ask:

What is the previous screen still doing?

A simple failure scenario

Consider a screen that subscribes to an event:

import { useEffect } from 'react';
import { DeviceEventEmitter } from 'react-native';

function StatusScreen() {
  useEffect(() => {
    DeviceEventEmitter.addListener('device-status', status => {
      console.log('Device status:', status);
    });
  }, []);

  return null;
}

At first glance, this code looks harmless.

The subscription is created only once for each mount because the dependency array is empty.

But there is no cleanup.

Each time the screen mounts, another listener is registered.

After navigating to the screen five times, the same event may trigger five callbacks.

The screen may not look broken, but the application is now doing unnecessary work.

A safer version removes the listener during cleanup:

import { useEffect } from 'react';
import { DeviceEventEmitter } from 'react-native';

function StatusScreen() {
  useEffect(() => {
    const subscription = DeviceEventEmitter.addListener(
      'device-status',
      status => {
        console.log('Device status:', status);
      }
    );

    return () => {
      subscription.remove();
    };
  }, []);

  return null;
}

The important improvement is not in the render function.

It is in the lifecycle ownership.

Common sources of memory leaks in React Native

1. Event listeners without cleanup

Listeners are one of the most common causes of duplicated work.

Examples include:

DeviceEventEmitter
NativeEventEmitter
keyboard listeners
dimension listeners
custom event buses
navigation listeners

A common mistake is to register the listener correctly but forget to unsubscribe.

useEffect(() => {
  const subscription = Keyboard.addListener(
    'keyboardDidShow',
    handleKeyboardShow
  );

  return () => {
    subscription.remove();
  };
}, []);

Every listener should have a clear cleanup path.

2. Timers that survive screen unmount

Intervals are especially risky because they continue executing until explicitly cleared.

useEffect(() => {
  const intervalId = setInterval(() => {
    refreshStatus();
  }, 5000);

  return () => {
    clearInterval(intervalId);
  };
}, []);

Without cleanup, each screen visit may create another interval.

The result may be:

duplicate API requests
repeated state updates
unnecessary battery usage
unexpected native module calls

The code may still appear correct during a short test session.

The problem becomes visible only after repeated use.

3. AppState and NetInfo subscriptions

App lifecycle and connectivity listeners often live close to application-level logic.

That makes ownership less obvious.

useEffect(() => {
  const subscription = AppState.addEventListener(
    'change',
    handleAppStateChange
  );

  return () => {
    subscription.remove();
  };
}, []);

NetInfo has a similar subscription pattern:

useEffect(() => {
  const unsubscribe = NetInfo.addEventListener(state => {
    console.log('Connected:', state.isConnected);
  });

  return unsubscribe;
}, []);

These subscriptions can be valid at the application level.

The problem starts when the same global-style listener is created inside multiple screens or components.

Before registering one, decide:

should this listener exist once for the app?
once per navigator?
once per screen?
once per active feature?

The cleanup strategy depends on the ownership boundary.

4. Native module callbacks registered multiple times

Native integration makes memory leaks harder to diagnose because the work may continue outside React.

A native module may:

emit Bluetooth events
report sensor data
receive location updates
send foreground service events
notify JavaScript about background tasks

If the JavaScript side registers the callback repeatedly, the native module may continue sending events to multiple active listeners.

useEffect(() => {
  const emitter = new NativeEventEmitter(MyNativeModule);

  const subscription = emitter.addListener(
    'measurement',
    handleMeasurement
  );

  return () => {
    subscription.remove();
  };
}, []);

For native integrations, also verify whether cleanup is required on the native side.

Removing the JavaScript listener may not be enough if the native service itself keeps running.

Sometimes cleanup also requires calling methods such as:

MyNativeModule.stopMonitoring();

The correct lifecycle may therefore look like this:

useEffect(() => {
  MyNativeModule.startMonitoring();

  const emitter = new NativeEventEmitter(MyNativeModule);

  const subscription = emitter.addListener(
    'measurement',
    handleMeasurement
  );

  return () => {
    subscription.remove();
    MyNativeModule.stopMonitoring();
  };
}, []);

This is why memory ownership matters more than simply calling remove().

5. Async work completing after unmount

Async operations do not always create a permanent memory leak, but they can still produce stale work and unnecessary updates.

useEffect(() => {
  fetchProfile().then(profile => {
    setProfile(profile);
  });
}, []);

If the user leaves the screen before the request finishes, the callback may run after unmount.

A simple guard can prevent stale updates:

useEffect(() => {
  let isActive = true;

  async function loadProfile() {
    const profile = await fetchProfile();

    if (isActive) {
      setProfile(profile);
    }
  }

  loadProfile();

  return () => {
    isActive = false;
  };
}, []);

For network requests, cancellation is often better when supported.

With fetch, you can use AbortController:

useEffect(() => {
  const controller = new AbortController();

  async function loadProfile() {
    try {
      const response = await fetch('/profile', {
        signal: controller.signal,
      });

      const data = await response.json();
      setProfile(data);
    } catch (error) {
      if (error instanceof Error && error.name !== 'AbortError') {
        console.error(error);
      }
    }
  }

  loadProfile();

  return () => {
    controller.abort();
  };
}, []);

This avoids unnecessary work instead of only ignoring the result.

The ownership questions every subscription should answer

For every listener, timer, subscription or callback, identify four things.

1. Where is it created?

Is it created inside:

a screen
a custom hook
a context provider
a navigation container
an app-level service

This tells you where cleanup should probably live.

2. Who owns it?

Ownership should be explicit.

A screen-level listener should normally disappear with the screen.

An application-level listener may intentionally survive navigation.

The problem is not long-lived work itself.

The problem is long-lived work without clear ownership.

3. When is it removed?

Do not rely on assumptions.

The cleanup path should be visible and testable.

For React components, this often means returning a cleanup function from useEffect.

useEffect(() => {
  const resource = createResource();

  return () => {
    resource.dispose();
  };
}, []);

4. Can it be registered more than once?

This question catches many production issues.

A listener may be duplicated because:

the component mounts repeatedly
the effect dependency changes
a navigation listener is registered during focus
a retry flow reinitialises the subscription
a native module setup method is called more than once

Always verify whether the registration is idempotent.

`useEffect` dependencies can create hidden duplication

A cleanup function alone does not guarantee correct behaviour.

Consider this effect:

useEffect(() => {
  const subscription = eventBus.subscribe(userId, handleEvent);

  return () => {
    subscription.unsubscribe();
  };
}, [userId, handleEvent]);

If handleEvent is recreated on every render, the effect may unsubscribe and resubscribe repeatedly.

That may be valid, but it may also create unnecessary churn.

Use useCallback when stable function identity is important:

const handleEvent = useCallback((event: EventData) => {
  console.log(event);
}, []);

useEffect(() => {
  const subscription = eventBus.subscribe(userId, handleEvent);

  return () => {
    subscription.unsubscribe();
  };
}, [userId, handleEvent]);

The debugging question is not simply:

Does this effect have cleanup?

It is:

How often does this effect run, and how often does it recreate the resource?

Focus listeners require extra care

React Navigation screens may remain mounted even when they are not focused.

That means screen lifecycle and focus lifecycle are not always the same.

If work should run only while the screen is active, useFocusEffect may be a better fit.

import { useCallback } from 'react';
import { useFocusEffect } from '@react-navigation/native';

useFocusEffect(
  useCallback(() => {
    const subscription = subscribeToLiveData();

    return () => {
      subscription.unsubscribe();
    };
  }, [])
);

This ensures the subscription is active only while the screen is focused.

Use this carefully.

If the subscription should survive temporary navigation changes, screen-level focus cleanup may be too aggressive.

The correct decision depends on ownership.

Why render optimisation alone may not help

Suppose you apply:

React.memo
useMemo
useCallback
list virtualisation
smaller component trees

These changes can improve rendering.

But they do not remove:

old listeners
duplicate timers
native callbacks
background services
stale async tasks

You may make the current screen render faster while previous screens continue consuming resources.

That is why profiling only render behaviour can give an incomplete picture.

Render profiling tells you what React is doing now.

Lifecycle debugging tells you what earlier components may still be doing.

You need both.

A practical debugging process

When a React Native app becomes slower after repeated navigation, use a repeatable process.

Step 1: Reproduce the degradation

Do not test only from a fresh launch.

Repeat the same flow:

open the screen
leave the screen
open it again
repeat several times
trigger the same event or action

Look for callbacks that increase with every cycle.

Step 2: Add temporary registration logs

Log when resources are created and removed.

useEffect(() => {
  console.log('Registering device listener');

  const subscription = registerDeviceListener();

  return () => {
    console.log('Removing device listener');
    subscription.remove();
  };
}, []);

For each registration, you should see a corresponding cleanup when expected.

Step 3: Count callback executions

const callbackCount = useRef(0);

function handleEvent() {
  callbackCount.current += 1;
  console.log('Callback count:', callbackCount.current);
}

If a single event triggers multiple callbacks after repeated navigation, duplicate listeners are likely.

Step 4: Inspect timers and polling

Search for:

setInterval
setTimeout
recursive polling
retry loops
animation loops

Confirm that each one is cancelled correctly.

Step 5: Inspect native services

Check whether native modules continue:

scanning
observing
polling
emitting events
tracking location
maintaining sockets

JavaScript cleanup may not stop native work automatically.

Step 6: Profile memory and activity

Use platform tools when the issue is not obvious.

For Android:

Android Studio Profiler
Memory Profiler
CPU Profiler
Logcat

For iOS:

Xcode Instruments
Allocations
Leaks
Time Profiler
Energy Log

Also use React Native tooling where useful:

React DevTools
Hermes profiling
Flipper, where supported by the project setup

The goal is not only to see memory growth.

Also check whether the number of callbacks, subscriptions or native operations grows with each navigation cycle.

A cleanup checklist for code review

When reviewing React Native lifecycle code, ask:

Does every listener have an unsubscribe path?
Does every interval have a clearInterval?
Does every timeout have a clearTimeout where required?
Does every native subscription expose disposal?
Does every background service have a stop method?
Can this effect register more than once?
Should this resource follow mount lifecycle or focus lifecycle?
Can async work be cancelled?
Can stale results update state?
Is this subscription owned by the correct architectural layer?

This checklist is more useful than asking only whether useEffect has a return function.

Cleanup is not just syntax.

It is an ownership decision.

A stronger engineering rule

Before optimising rendering, check whether the screen leaves behind any long-lived work.

For every subscription, answer:

Where is it created?
Who owns it?
When is it removed?
Can it be registered more than once?

A component may render perfectly and still damage performance over time.

The leak often exists outside the visible render path.

That is why repeated navigation is such an important test.

A fresh launch shows whether the screen works.

Repeated use shows whether the lifecycle works.

Final takeaway

Not every slow React Native screen needs render optimisation.

Sometimes the screen is slow because previous screens are still alive through:

listeners
timers
subscriptions
native callbacks
background tasks

Render profiling tells you what React is doing now.

Lifecycle cleanup tells you what old work never stopped.

When a React Native app becomes slower after repeated navigation, which cleanup path do you inspect first?

Add Web Search Tool to AI Agent | Tool Calling Explained | Microsoft Foundry AI Agent Tutorial #6

Subrata Kumar Das — Wed, 24 Jun 2026 16:20:56 +0000

Deploy Your First AI Model in Microsoft Foundry | System Prompts Explained | AI Agent Course #5

Subrata Kumar Das — Wed, 24 Jun 2026 16:18:12 +0000

Microsoft Foundry Setup Tutorial | Create Your First AI Agent Project (Azure AI Foundry Course) #4

Subrata Kumar Das — Wed, 24 Jun 2026 16:16:35 +0000

What is an AI Agent? AI Agent vs Chatbot Explained | Microsoft Foundry Course #3

Subrata Kumar Das — Wed, 24 Jun 2026 16:14:54 +0000

What is Generative AI? Understanding the Foundation of Modern AI Agents #2

Subrata Kumar Das — Fri, 19 Jun 2026 06:20:04 +0000

Everyone is talking about AI Agents.

But before you build an AI Agent, there is one concept you absolutely need to understand:

Generative AI.

Generative AI is the technology that transformed software from systems that simply follow rules into systems that can understand language, generate responses, reason through instructions, and assist users in a natural way.

As part of my new course:

Develop Your First AI Agent with Microsoft Foundry

I published the first lesson where we explore the journey from traditional software to Generative AI and understand why modern AI Agents became possible.

🎥 Watch the video here:

Why This Topic Matters

Many developers jump directly into AI Agents, prompts, tools, and frameworks.

However, without understanding the evolution of AI, it becomes difficult to understand:

Why AI Agents exist
Why Large Language Models are important
Why prompts work
Why tools are needed
How modern AI systems actually operate

In this lesson, we start from first principles and build the foundation required for the rest of the course.

What You'll Learn

Traditional Software

For decades, software followed a simple pattern:

Input → Rules → Output

Developers explicitly defined every behavior.

This worked well until humans started interacting with software using natural language.

Why Rule-Based Systems Break

Imagine building a dietician chatbot.

Users might ask:

What should I eat?
Suggest a healthy breakfast.
What foods contain protein?
Can I eat oats daily?

All of these questions are similar.

Yet they are phrased differently.

Supporting thousands of variations quickly becomes impossible with manually written rules.

Predictive AI

Machine Learning introduced a new approach.

Instead of writing rules, we train models using data.

Examples include:

Spam Detection
Fraud Detection
Recommendation Systems

Predictive AI can make decisions.

But it still cannot create content.

Prediction vs Creation

A predictive model can answer:

Fraud probability: 87%

But can it explain why?

Can it write a detailed report?

Can it create a personalized recommendation?

Not naturally.

This limitation led to the rise of Generative AI.

Generative AI

Generative AI creates new content.

It can generate:

Text
Images
Audio
Video
Code

Instead of selecting predefined responses, it dynamically creates new outputs based on user prompts.

Large Language Models (LLMs)

At the heart of Generative AI are Large Language Models.

LLMs learn language patterns from enormous amounts of data and use those patterns to generate human-like responses.

This is the technology behind modern AI systems such as ChatGPT, Microsoft Copilot, Gemini, Claude, and many others.

The Generative AI Flow

Every Generative AI application follows a simple architecture:

User Prompt → LLM → Generated Response

Understanding this flow is critical because it becomes the foundation of AI Agent architectures.

AI Agent Architecture

In the second half of the course, we will build an AI Agent using Microsoft Foundry.

The architecture we'll implement is:

User
↓
React + Vite Frontend
↓
Microsoft Foundry Agent
├── Instructions
├── Generative AI Model
└── Web Search Tool
↓
Response

Understanding Generative AI is the first step toward understanding this architecture.

Introducing Subra AI Dietician

Throughout the course, we will build:

Subra AI Dietician

A practical AI-powered dietician assistant that can:

Answer nutrition questions
Provide healthy food suggestions
Follow custom instructions
Use web search when required
Respond through a modern web interface

By the end of the course, you'll have a complete working AI Agent built using Microsoft Foundry.

Video Chapters

00:00 Introduction

01:30 The Problem With Traditional Software

02:30 Why Rule-Based Systems Break

03:51 The Rise of Predictive AI

05:06 Prediction vs Creation

05:55 What is Generative AI

06:43 What is LLM?

07:36 The Generative AI Flow

08:18 AI Agent Architecture

09:06 Subra AI Dietician

What's Coming Next?

In the next lesson, we'll answer a very important question:

If Generative AI can already answer questions, why do we need AI Agents?

We'll explore:

AI Assistant vs AI Agent
Instructions
Tools
Reasoning
Agent Workflows

and prepare for building our first Microsoft Foundry Agent.

If you're interested in AI Engineering, Microsoft Foundry, Azure AI, Agentic AI, or building practical AI applications, this series is designed for you.

Happy learning!

— Subrata Kumar Das
🌐 subraatakumar.com

Develop Your First AI Agent with Microsoft Foundry

Subrata Kumar Das — Thu, 18 Jun 2026 06:11:35 +0000

Develop Your First AI Agent with Microsoft Foundry – Course Launch

AI Agents are quickly moving from experimental technology to real-world software engineering solutions.

As developers, we are entering a phase where applications can not only respond to user input but also reason, use tools, search for information, and perform tasks on behalf of users.

To help software engineers get started with this technology, I've launched a new hands-on course:

Develop Your First AI Agent with Microsoft Foundry

This course focuses on practical implementation rather than AI theory.

Throughout the series, we'll build a complete application called Subra AI Dietician, an intelligent AI Agent powered by Microsoft Foundry and Azure AI Foundry Agent Service.

What You'll Build

By the end of the course, you'll have built:

A Microsoft Foundry AI Agent
Custom Agent Instructions
Web Search Tool Integration
Agent Testing and Evaluation
A Deployed AI Agent
A React Frontend Connected to the Agent
A Complete End-to-End AI Application

Technology Stack

Microsoft Foundry
Azure AI Foundry Agent Service
Visual Studio Code
GitHub Copilot
React
Vite

Who Is This Course For?

This course is designed for:

Software Engineers
React Developers
React Native Developers
Full Stack Developers
Technical Leads

No prior AI experience is required.

Lesson 1 Is Now Available

The first lesson introduces the course, explains what we'll build, and walks through the complete project roadmap.

📺 Watch the video:

🌐 Course Website:
https://rnm.subraatakumar.com

What's Next?

In the next lesson, we'll answer an important question:

What exactly is an AI Agent, and how is it different from traditional software applications?

I'd love to hear from the community:

What AI Agent would you build for your organization or personal projects?

ai #microsoft #azure #aifoundry #microsoftfoundry #aiagents #softwareengineering #react #reactnative #webdevelopment #githubcopilot

Lesson 1.3 - GraphQL for Screen Complexity and App Changes

Subrata Kumar Das — Wed, 17 Jun 2026 05:07:25 +0000

Good morning, class! Welcome back. In our last lesson, we explored how GraphQL fundamentally addresses the issues of over-fetching and under-fetching.

Today, we are going to connect those architectural concepts directly to real-world React Native screen complexity. Our Goal today is to understand how GraphQL simplifies your codebase when a screen demands multiple data sources, when different screens require entirely unique variations of the same resource, and when your mobile application changes and evolves over time.

1. Problem One: Codebase Complexity via Multiple API Calls

Making multiple API calls is not inherently wrong, but from a mobile product engineering perspective, it introduces a significant amount of state-tracking boilerplate inside your components.

In a traditional React Native screen driven by REST, managing multiple endpoints often forces you into a state management pattern that looks like this:

const [products, setProducts] = useState([]);
const [categories, setCategories] = useState([]);
const [loadingProducts, setLoadingProducts] = useState(false);
const [loadingCategories, setLoadingCategories] = useState(false);
const [productsError, setProductsError] = useState<string | null>(null);
const [categoriesError, setCategoriesError] = useState<string | null>(null);

Class, look closely at this block of code. We haven't even written a single line of JSX or rendered any UI yet, and our component is already drowning in individual state hooks just to track the network layer.

The moment a single screen relies on multiple independent asynchronous requests, you are forced to programmatically answer complex state orchestration questions:

Is the entire screen considered to be in a loading state, or are individual sub-sections loading independently?
What happens visually if the product list resolves successfully, but the category chip request fails?
When a user triggers a pull-to-refresh action, should it aggressively retry every single request?
Should a localized network failure on a non-critical widget block the user from interacting with the rest of the screen?

2. GraphQL Fix One: Consolidated Screen-Level Operations

Instead of forcing your UI components to orchestrate several disconnected REST endpoints, a single GraphQL operation lets you fetch the precise combination of data pieces your screen needs in one single network round-trip:

query HomeScreenData {
  categories
  products(page: 1, size: 10) {
    meta {
      total
      page
      pages
    }
    data {
      id
      name
      price
      imageUrl
      category
    }
  }
}

Now, let's be entirely clear: this does not magically erase the necessity for loading spinners or error screens. You still need to design and implement resilient UI fallbacks.

However, it vastly simplifies your frontend state logic. It collapses multiple asynchronous workflows down into one single operation for your component to reason about, dramatically reducing the state variables you need to manually track.

3. Problem Two: Screen-Specific Data Requirements

As an application grows, different mobile screens will inevitably demand entirely different variations of the exact same data model. Let’s map out a standard e-commerce flow:

Product List Screen Layout: Only needs id, name, price, and imageUrl.
Product Details Screen Layout: Requires id, name, price, imageUrl, description, brand, rating, discount, and inStock.
Cart Summary Screen Layout: Demands id, name, price, quantity, and inStock.

In a traditional REST architecture, backend teams typically handle these evolving variations by creating specific hyper-targeted endpoints (like /api/v1/products/cart-view) or by adding heavy configurations of query parameters (like /products?include=details).

While this can get the job done, over time it causes your API surface area to balloon into a tangled, unmanageable mess simply because every new screen design requires a slightly modified data payload shape.

4. GraphQL Fix Two: Component-Driven Selection Sets

GraphQL shifts data model ownership back to the client application. Instead of waiting on backend adjustments, each specific screen explicitly declares its own data requirements.

Furthermore, you can parameterize these operations dynamically using GraphQL Variables:

query ProductListScreen($page: Int!, $size: Int!, $category: String) {
  products(page: $page, size: $size, category: $category) {
    meta {
      total
      page
      pages
    }
    data {
      id
      name
      price
      imageUrl
      inStock
    }
  }
}

To execute this operation with dynamic filtering, you pass a separate Variables object alongside the query:

{
  "page": 1,
  "size": 10,
  "category": "fruits"
}

The underlying structural template of the query remains completely stable. The runtime variables change fluidly based on user interaction. This exact paradigm is exactly what makes building mobile filters, search views, and infinite-scrolling lists highly predictable and clean.

5. Problem Three: The Production Reality of App Versioning

Unlike web applications where a new deployment updates all users instantly, mobile applications stay installed on user devices for months or even years.

If a backend team alters or refactors a REST response payload, older, un-updated installations of your mobile app out in the wild can instantly crash. Because of this, mobile engineering teams are traditionally forced to implement strict, complex API versioning policies (like /api/v1/ vs /api/v2/).

GraphQL does not replace architectural discipline, but it offers natural protection against breaking changes because the client must explicitly request the fields it intends to use. If an older mobile app build doesn't know about a new rating field, it simply won't request it. If a newer build needs to display it, you append it inline without affecting old versions:

query ProductCards {
  products(page: 1, size: 10) {
    data {
      id
      name
      price
      rating # Added seamlessly for new app versions
    }
  }
}

Because the backend server knows exactly which fields are being requested by current active users, the client app is no longer tightly coupled to a monolithic, fixed response shape.

6. The Blueprint: Predictable Response Mirroring

One of the most beginner-friendly and elegant aspects of working with GraphQL is that the response payload shape directly mirrors your request query structure.

Let’s trace an active transaction:

Client Query Document:

query CategoriesAndProducts {
  categories
  products(page: 1, size: 2) {
    data {
      id
      name
    }
  }
}

JSON Server Response:

{
  "data": {
    "categories": ["Fruits", "Vegetables"],
    "products": {
      "data": [
        { "id": 1, "name": "Apple" },
        { "id": 2, "name": "Tomato" }
      ]
    }
  }
}

While the literal data values inside the strings and arrays will change based on database records, the structural nesting matches your query word-for-word, making data binding inside React Native components entirely intuitive.

7. Guided Practice in GraphiQL

Before we jump back into our mobile IDEs, let's build muscular memory by sandbox testing this query layout inside GraphiQL:

Navigate your web browser to https://backend.ecom.subraatakumar.com/graphiql.
Paste the parameterized ProductListScreen query into the main editor panel.
Open the Query Variables drawer at the bottom left and pass valid page/category variables.
Hit the Play button to execute.
Experiment: adjust the category string to another value and re-run.
Delete imageUrl from the selection set and observe the updated JSON structure.
Append rating to the selection set, execute, and verify the structural response mirrors your query change instantly.

This iterative feedback loop is the core day-to-day workflow of a productive GraphQL developer.

8. React Native Low-Level Implementation

Let’s observe how this complete multi-resource request compiles into a low-level JavaScript module using our temporary native fetch client:

async function loadProductList(page: number, category?: string) {
  const response = await fetch("https://backend.ecom.subraatakumar.com/graphql", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      query: `
        query ProductListScreen($page: Int!, $size: Int!, $category: String) {
          products(page: $page, size: $size, category: $category) {
            meta {
              total
              page
              pages
            }
            data {
              id
              name
              price
              imageUrl
              inStock
            }
          }
        }
      `,
      variables: {
        page,
        size: 10,
        category: category ?? null,
      },
    }),
  });

  const json = await response.json();

  if (json.errors) {
    throw new Error(json.errors[0].message);
  }

  return json.data.products.data;
}

Check Your Understanding

Before we wrap up this theory session and head into our practical labs, make sure you can answer these three questions clearly:

How do multiple independent REST calls compound the structural complexity of component loading and error states in React Native?
What does it mean for a screen to "own its data requirement," and how does this prevent API endpoint bloat on the backend?
What is the relationship between the structural layout of a GraphQL query document and the eventual JSON payload returned by the server?

Great work today, class. Review your notes, spend 10 minutes testing variations in the GraphiQL playground, and I will see you all in our next session!

Connect with me:

GitHub: https://github.com/TechCraft-By-Subrata
LinkedIn: https://www.linkedin.com/in/subraatakumar/
YouTube: https://www.youtube.com/@techcraftclub
Instagram: https://www.instagram.com/subraatakumar/
Reddit: https://www.reddit.com/r/ReactNativeMastery/
DEV.to: https://dev.to/subraatakumar
Discord: https://discord.gg/cA5fhVT8
WhatsApp: https://whatsapp.com/channel/0029VbCz72vFCCoUsMV4K30M
Topmate: https://topmate.io/subrata
React Native Mastery: https://rnm.subraatakumar.com/

DEV Community: Subrata Kumar Das

Subra AI: Private Offline On-Device AI

Synchronous TurboModules Are Not Automatically Fast

The misleading simplicity of a synchronous API

What synchronous actually means

Why this affects React Native performance

TurboModules reduce overhead, not execution cost

When synchronous native methods are appropriate

Operations that should usually remain asynchronous

Storage

Cryptography

Networking

Large data conversion

Image and file processing

System services

Avoid synchronous work inside rendering

Cache deliberately, not accidentally

Measure the whole native method

Watch for repeated synchronous calls

Synchronous methods create architectural coupling

A practical decision rule

Suitable for synchronous execution

Better suited for asynchronous execution

Code-review checklist

Final takeaway

Type Safety Stops at Runtime Boundaries in React Native

A simple example

Casting is not validation

Where the failure appears

Compile-time trust should stop at runtime boundaries

Why unknown is better than any

Manual runtime validation

Validate business rules, not only field types

Using a schema validation library

Runtime boundaries in React Native

1. Native modules

2. Network responses

3. Persisted storage

4. Deep links

5. Remote configuration

6. AI-generated structured output

Validate once at the edge

Parse, do not merely check

A practical code-review checklist

Final takeaway

Your Offline-First App Can Lose Correct Data Without Showing Any Error

The Failure Scenario

Why Last-Write-Wins Is Not Always Conflict Resolution

Offline-First Is a Business-Rules Problem

1. Merge

2. Reject

3. Overwrite

4. Review

Use Version Numbers, Not Only Timestamps

A Simple React Native Mutation Queue

Classify Sync Failures Correctly

Network failure

Authentication failure

Validation failure

Version conflict

Do Not Delete the Local Mutation Too Early

Conflict Resolution Should Be Field-Aware

Define the Rules Before Selecting the Database

A Practical Conflict-Policy Table

Questions to Ask During Architecture Review

Final Takeaway

Your React Native Performance Problem May Actually Be a Memory Leak

Your React Native Performance Problem May Actually Be a Memory Leak

Why this is easy to misdiagnose

A simple failure scenario

Common sources of memory leaks in React Native

1. Event listeners without cleanup

2. Timers that survive screen unmount

3. AppState and NetInfo subscriptions

4. Native module callbacks registered multiple times

5. Async work completing after unmount

The ownership questions every subscription should answer

1. Where is it created?

2. Who owns it?

3. When is it removed?

Why `unknown` is better than `any`

`useEffect` dependencies can create hidden duplication