Asynchronous and Event-Driven Programming Questions

Clarify assumptions

• 50 independent widgets, each one small JSON endpoint; browser environment; acceptable to render widgets progressively; backend supports caching headers.

Compare strategies (summary)

A) Promise.all (full parallel)

• Latency: minimal time-to-all-complete but head-of-line depends on slowest request.
• CPU/memory: many concurrent XHRs (50); higher memory for inflight promises.
• Network: burst of 50 connections; may hit browser connection limits, cause queuing at TCP level.
• UX: poor if you wait for all; good if you render only when all ready.
• Errors: one rejection fails entire Promise.all unless handled per-request.
• Caching: benefits from HTTP caching; must still dedupe requests.

B) Sequential fetch

• Latency: worst total completion time (sum of latencies).
• CPU/memory: minimal.
• Network: low concurrency, smooth.
• UX: good if you render each as it completes; slow overall.
• Errors: easy per-request retry.
• Caching: same as others.

C) Limited concurrency pool (recommended for many dashboards)

• Latency: trades off total time vs connection limits; faster than sequential, avoids overwhelm.
• CPU/memory: bounded.
• Network: controlled parallelism (e.g., 5–10).
• UX: progressive rendering; predictable performance.
• Errors: handle per-task with retries/backoff.
• Caching: combine with in-memory dedupe and HTTP cache.

Code pattern (C):

// limited concurrency pool
async function fetchWithPool(urls, concurrency = 8) {
  const results = new Array(urls.length);
  let i = 0;
  const worker = async () => {
    while (i < urls.length) {
      const idx = i++;
      try {
        const res = await fetch(urls[idx]);
        results[idx] = await res.json();
      } catch (e) {
        results[idx] = { error: e };
      }
    }
  };
  await Promise.all(Array.from({ length: concurrency }, worker));
  return results;
}

D) Streaming / prioritized incremental rendering (best UX)

• Latency: best perceived latency; users see important widgets first.
• CPU/memory: low, since you render and release resources.
• Network: can still use limited concurrency; long-lived streaming channels (SSE/HTTP2) reduce overhead.
• UX: excellent perceived performance; progressive hydration.
• Errors: isolate per-stream or widget; show placeholders and partial retries.
• Caching: combine server push, revalidation, and client cache.

Code pattern (D):

// prioritized fetch + render as they finish
async function prioritizedFetch(items, render, priorityFn, concurrency = 6) {
  const queue = items.sort((a,b) => priorityFn(b)-priorityFn(a));
  const inFlight = [];
  while (queue.length || inFlight.length) {
    while (inFlight.length < concurrency && queue.length) {
      const item = queue.shift();
      const p = fetch(item.url)
        .then(r => r.json())
        .then(data => { render(item.id, data); })
        .catch(err => { render(item.id, { error: true }); })
        .finally(() => {
          const idx = inFlight.indexOf(p); if (idx>=0) inFlight.splice(idx,1);
        });
      inFlight.push(p);
    }
    await Promise.race(inFlight);
  }
}

When to pick

• Promise.all: small number of widgets (<=6), simple pages, or when you must wait for all.
• Sequential: very tight backend limits or extremely heavy widgets; otherwise avoid.
• Limited concurrency: default choice for dashboards—balance speed and resource limits.
• Streaming/prioritized: best when perceived performance matters (complex dashboards, mobile users), or when you can prioritize critical widgets.

Practical tips

• Use HTTP caching, ETags, and client-side dedupe.
• Retry with exponential backoff for transient errors.
• Show placeholders/skeletons and allow user-driven refresh per-widget.
• Measure real device latencies and tune concurrency (start ~6–8).

Approach (brief)
Model three parts: call stack (implicit), microtask queue (FIFO), macrotask queue (FIFO). runOneTick() pops one macrotask, executes it (it may schedule new tasks), then drains microtasks until empty. Record execution order in a log array for deterministic testing.

Implementation

class EventLoopSimulator {
  constructor() {
    this.micro = []; // microtask FIFO
    this.macro = []; // macrotask FIFO
    this.log = [];
  }

  scheduleMicrotask(fn, label) {
    this.micro.push({ fn, label: label || fn.name || 'micro' });
  }

  scheduleMacrotask(fn, label) {
    this.macro.push({ fn, label: label || fn.name || 'macro' });
  }

  runOneTick() {
    this.log = [];
    const task = this.macro.shift();
    if (!task) return this.log;
    // execute macrotask
    this._exec(task, 'macrotask');
    // drain microtasks until empty (microtasks can enqueue more microtasks)
    while (this.micro.length) {
      const m = this.micro.shift();
      this._exec(m, 'microtask');
    }
    return this.log;
  }

  _exec(task, type) {
    this.log.push({ type, label: task.label });
    try { task.fn(this); } catch (e) { this.log.push({ type: 'error', error: String(e) }); }
  }
}
module.exports = EventLoopSimulator;

Key points & complexity

• Deterministic FIFO behavior matches JS semantics for micro/macrotasks.
• runOneTick is O(n) where n is executed tasks.
• Edge cases: macrotask absent (returns empty log), tasks throwing errors (captured), tasks that schedule both micro and macrotasks.

Example usage
Schedule a macrotask that schedules a microtask; runOneTick() returns macrotask then microtask in order — useful for unit tests and teaching event loop ordering.

Clarify goals (perceived vs actual):

• Perceived: show UI quickly (skeletons, placeholders, progressive rendering).
• Actual: reduce bytes, requests, and CPU.

High-level strategies

• Batching: combine many small requests into one bulk API to reduce overhead.
• Deduplication: coalesce identical requests in-flight and reuse results.
• Caching: HTTP caching (ETag, Cache-Control), and in-memory (Map) for reuse within session.
• Concurrency limiting: cap parallel fetches (e.g., 6) to avoid TCP/CPU contention.
• Lazy-loading / priority: load viewport avatars first; defer offscreen with IntersectionObserver.
• Streaming / incremental rendering: render as each chunk/response arrives.

Client-side batching + dedupe (pseudocode)

// simple in-memory cache and in-flight dedupe + batcher
const cache = new Map();           // id -> data
const inflight = new Map();        // id -> Promise
let batchQueue = new Set();
let batchTimer = null;

function requestAvatar(id) {
  if (cache.has(id)) return Promise.resolve(cache.get(id));
  if (inflight.has(id)) return inflight.get(id);

  // add to batch
  batchQueue.add(id);
  const p = new Promise((resolve, reject) => {
    if (!batchTimer) batchTimer = setTimeout(flushBatch, 10); // micro-batch window
    inflight.set(id, { resolve, reject }); // store resolvers
  });
  // wrap to match Promise stored earlier
  const wrapped = new Promise((res, rej) => p.then(res).catch(rej));
  inflight.set(id, wrapped);
  return wrapped;
}

async function flushBatch() {
  const ids = Array.from(batchQueue);
  batchQueue.clear();
  batchTimer = null;
  try {
    const res = await fetch('/api/avatars?ids=' + ids.join(','));
    const json = await res.json(); // { id: data }
    ids.forEach(id => {
      const data = json[id];
      cache.set(id, data);
      const promise = inflight.get(id);
      if (promise && promise.resolve) promise.resolve(data);
      else if (promise) promise.then(()=>{}); // safe no-op
      inflight.delete(id);
    });
  } catch (err) {
    ids.forEach(id => {
      const promise = inflight.get(id);
      if (promise && promise.reject) promise.reject(err);
      inflight.delete(id);
    });
  }
}

Notes & trade-offs

• Batch window balances latency vs fewer requests.
• HTTP caching reduces backend cost; use short-lived in-memory cache for navigation.
• Concurrency limiting + lazy-load improves perceived speed on mobile.
• Monitor and measure (TTI, LCP, waterfall) to tune parameters.

Differences (brief)

• Callback-based: pass a function to be invoked later. Simple but leads to nesting ("callback hell") and error-first patterns.
• Promises: represent a future value; chainable with .then/.catch, avoid deep nesting. Can produce unhandled rejection if not caught.
• async/await: syntactic sugar over Promises; write asynchronous code like synchronous with try/catch for errors.

Examples (equivalent flow: fetch data, handle success/error)

(1) Callback-style

// callback: (err, data) => {}
function fetchDataCallback(url, cb) {
  fetch(url)
    .then(res => res.json())
    .then(data => cb(null, data))
    .catch(err => cb(err));
}

// usage
fetchDataCallback('/api/items', (err, data) => {
  if (err) {
    console.error('Callback error', err);
    return;
  }
  console.log('Callback data', data);
});

(2) Promise-based

function fetchDataPromise(url) {
  return fetch(url).then(res => res.json());
}

// usage
fetchDataPromise('/api/items')
  .then(data => console.log('Promise data', data))
  .catch(err => console.error('Promise error', err));

(3) async/await

async function fetchDataAsync(url) {
  const res = await fetch(url);
  return res.json();
}

// usage
(async () => {
  try {
    const data = await fetchDataAsync('/api/items');
    console.log('Async data', data);
  } catch (err) {
    console.error('Async error', err);
  }
})();

Error handling behaviors

• Callbacks: use error-first callback; errors must be passed to cb or thrown inside async contexts (won't be caught).
• Promises: rejected promise propagates until .catch; forgetting .catch causes unhandledrejection.
• async/await: use try/catch around await; an uncaught error rejects the returned Promise.

Common pitfalls

• Callbacks: deep nesting, inconsistent error handling, double-callback invocation.
• Promises: forgetting to return in chains, swallowing errors in .then, unhandled rejections.
• async/await: forgetting try/catch, awaiting non-Promise values incorrectly, blocking UI with long synchronous work after await.

Use Promises/async-await for modern frontend code; keep callbacks for simple event handlers or legacy APIs.

Lifecycle & state transitions

• Pending — initial state; neither fulfilled nor rejected.
• Fulfilled (resolved) — completed successfully with a value.
• Rejected — failed with a reason (error).

Once settled (fulfilled or rejected) the state is immutable.

Handlers before vs after resolution

Example: handlers attached before resolution

const p = new Promise((res) => {
  setTimeout(() => res(42), 10);
});
p.then(v => console.log('before-resolve:', v));

Handlers attached after resolution

const q = Promise.resolve(7);
q.then(v => console.log('after-resolve:', v)); // still called

Both run — promises remember their settled value and call handlers even if attached later.

Why .then callbacks are always asynchronous

.then callbacks run in the microtask queue (per spec), so even if a promise is already resolved, its .then callbacks execute after the current call stack finishes:

Promise.resolve(1).then(() => console.log('microtask'));
console.log('sync');
// Output:
// sync
// microtask

This guarantees consistent, predictable ordering and avoids surprising re-entrancy.

Thenables and resolution

If resolve receives a thenable (object with a .then), Promise resolution will call that thenable’s .then and adopt its eventual state (unwrapping). This lets interoperability with other promise-like implementations:

const thenable = { then: (onF) => onF('unwrapped') };
Promise.resolve(thenable).then(v => console.log(v)); // 'unwrapped'

Takeaway: Promises move pending → fulfilled/rejected once, handlers always run (even if attached later), .then is asynchronous via microtasks, and thenables are unwrapped during resolution.