Mid-Level Full Stack Developer Interview Preparation Guide - FAANG Standards

What is prop drilling?
Prop drilling is passing props through intermediate components that don’t need them, just to reach a deep child. It creates noisy component interfaces and makes refactors harder.

When to use React Context
Use Context to provide data (theme, auth, locale) to many nested components without passing props at each level. Good for mostly static or infrequently changing values.

Concise example (replace prop drilling with Context)

// ThemeContext.js
import React from "react";
export const ThemeContext = React.createContext("light");

// App.jsx
import { ThemeContext } from "./ThemeContext";
import Page from "./Page";

function App(){ 
  const theme = "dark";
  return (
    <ThemeContext.Provider value={theme}>
      <Page />
    </ThemeContext.Provider>
  );
}

// DeepButton.jsx (consumer)
import React, { useContext } from "react";
import { ThemeContext } from "./ThemeContext";

function DeepButton(){
  const theme = useContext(ThemeContext);
  return <button className={theme}>Click</button>;
}

When Context is not appropriate

• Frequent updates (e.g., high-frequency numeric state): entire consumer subtree re-renders on change — can hurt performance.
• Complex global state with many actions: prefer Redux, Zustand, or colocated state + callbacks.
• For isolated state, prefer passing callbacks or local component state.

Use Context for cross-cutting, low-frequency data; for performance-sensitive or rapidly changing state, choose alternative patterns.

Direct answer

Size a cache cluster from the actual working set, not the total dataset, then add replication and fragmentation headroom on top; node count and per-node memory come out of that total, not the other way around.

Structured elaboration

• Working set versus total data size: the total dataset (200 GB, gigabytes, in a typical example) is not what needs to fit in cache; the working set (20 GB, the subset actually read repeatedly within a relevant time window) is the real sizing driver, since the whole point of caching is serving the repeatedly-accessed subset, not the entire dataset.
• Replication factor: for high availability, each byte of the working set is stored on more than one node (replication factor 2 doubles the effective memory requirement, since every item exists on a primary and at least one replica).
• Fragmentation and metadata headroom: real-world memory usage is always somewhat higher than the raw data size, due to per-key overhead (metadata, pointers) and memory fragmentation from the allocator; a 20 percent headroom is a reasonable starting estimate, refined with actual measurement once running.
• Calculating node count and per-node memory: total required memory equals working set size times replication factor times (1 plus headroom fraction); node count times per-node memory must exceed that total, with per-node memory chosen based on available instance types and a preference for more, smaller nodes (better fault isolation, smaller blast radius per node loss) versus fewer, larger nodes (simpler operations, less network overhead).
• Accounting for future growth: size with headroom for expected growth over a planning horizon (e.g., 6 to 12 months), not just current working-set size, since scaling a cache cluster up later involves the same resharding/migration considerations covered elsewhere in this topic.

Worked example

Working set 20 GB, replication factor 2, 20 percent headroom: required memory is $20 \text{ GB} \times 2 \times 1.2 = 48 \text{ GB}$. Choosing nodes with 8 GB of usable cache memory each (leaving room for the node's own operational overhead), that requires $\lceil 48 / 8 \rceil = 6$ nodes. If 6-month growth projections suggest the working set could grow to 30 GB, planning for $30 \times 2 \times 1.2 = 72 \text{ GB}$, or 9 nodes at the same per-node size, avoids a resharding event shortly after initial rollout.

Trade-offs and pitfalls

Sizing off total dataset size instead of working set drastically overestimates the memory needed for most read-heavy workloads with meaningful access skew (a small fraction of data accounting for most reads); always validate the working-set assumption with real access-pattern data where available, not just an estimate. Under-provisioning headroom for fragmentation and metadata is a common source of "sized correctly on paper, still evicting more than expected in production" surprises; treat the headroom percentage as a starting estimate to refine with real measurement, not a fixed constant to trust blindly.

Direct answer

When an application accepts social identity federation (signing in via Google or Facebook as the identity provider, or IdP) and suspects credential stuffing and account takeover through a weak external IdP, the core problem is that the application has delegated its trust decision to a third party it does not control and cannot fully audit; the defense has to happen at the boundary where a federated identity assertion is accepted, not by trying to fix the external IdP's own authentication strength. Concretely: treat the IdP's own identity assurance level as an input to the application's own risk decision rather than blanket trust, validate every claim in the returned assertion rather than accepting the subject identifier alone, run the federated sign-in event itself through risk-based authentication, require conditional multi-factor authentication (MFA) when risk or IdP weakness warrants it, throttle federated login and account-linking attempts specifically, and keep an alternative, non-federated verification path available for exactly the moments when the federated channel itself is the thing under suspicion.

Structured elaboration

Identity assurance levels. Not every IdP, and not every authentication event at a given IdP, carries the same assurance that the person behind it is who they claim to be. A framework like NIST 800-63 formalizes this as separate Identity Assurance Level (IAL, how strongly the person's real-world identity was verified during account creation) and Authenticator Assurance Level (AAL, how strongly a specific login event proves control of the account) ratings; a consumer social IdP account, created with just an email address and no real-world identity proofing, sits at a low IAL regardless of how the login itself is authenticated. The practical design consequence: the application should not treat "user authenticated via Google" as equivalent proof of identity to "user authenticated via a corporate IdP with verified employment," and should scale what the federated identity is trusted to do accordingly, low-risk actions freely, higher-value actions (linking a payment method, elevating administrative privileges) with additional verification regardless of how clean the federated sign-in looked.

Attribute validation. A federated assertion carries claims beyond the bare subject identifier: email, email_verified, the token's issuer (iss), audience (aud), and issuance/expiry timestamps at minimum. Each has to be checked, not assumed: email_verified must actually be true before the application treats the email as a trustworthy identifier for account linking or communication (a social IdP can, in some configurations, return an email the user entered but never confirmed); iss and aud must match the exact expected values to prevent a token issued for a different application, or by an unexpected provider, from being accepted; and the assertion's freshness (issued-at and expiry) must be checked to prevent an old, possibly-compromised token from being replayed well after the fact. Skipping any of these is a common, quiet implementation gap, since a login "succeeds" either way from the user's point of view, and the difference is invisible until it is exploited.

Risk-based authentication applied to the federation event itself. The same risk-scoring approach covered for direct-credential logins (IP reputation, device fingerprint, geolocation anomalies, behavioral deviation from the account's own history) applies to the federated sign-in event, not just to a password-based one; a federated login is still a login, and an attacker who has compromised a weak external IdP account (via credential stuffing against that IdP itself, which the application has no visibility into) presents through the same application login endpoint the same anomalous signals a direct-credential attacker would, an unfamiliar device, an implausible location jump, unusual timing. Scoring the federation event on these signals, not just trusting the fact that a valid-looking assertion arrived, is what lets the application catch an account takeover that originated entirely outside its own authentication system.

Conditional MFA. When either the risk score from the federation event is elevated, or the IdP's own assurance is known to be weak for the action being attempted, require an application-level MFA step-up (a code sent to a previously-verified phone number or email, a passkey the application itself registered, never a factor the same potentially-compromised IdP account could also satisfy) before allowing the action to proceed. This is the concrete mechanism that turns "we know this IdP is weak" into an actual control rather than an observation: a step-up factor that is independent of the federated identity's own security posture means a compromised Google or Facebook account alone is not sufficient to reach a sensitive action inside the application.

Throttling. Rate limiting needs to apply specifically to federation-related events, not only to a traditional password field: repeated failed or unusual federated sign-in attempts against the same application account, and especially repeated new-account-linking attempts (an attacker trying many stolen social-IdP credentials against the "sign in with Google" button to find one that maps to an existing, valuable application account) are both signals that benefit from the same per-account and per-source throttling discipline as password-based stuffing. Account-linking specifically deserves its own, tighter throttle, since a successful link (associating a new external identity with an existing application account) is a higher-value action than a mere failed login attempt.

Alternative verification flows. The whole design above still depends on the federated channel being available and, to some degree, trustworthy at the moment of the decision; when the application has active reason to distrust it (an ongoing suspected campaign against that specific IdP, a spike in federation-related anomalies), it needs a path that does not depend on that channel at all. Concretely: allow a user to fall back to a direct, application-owned verification method (a magic link to a previously-verified email the application itself controls, not the federated identity's own email claim; a code to a previously-verified phone number on file) to prove account ownership independent of whatever is happening with the external IdP, and consider temporarily requiring this alternative path, rather than the federated one, for sensitive actions specifically during a suspected active campaign against that IdP.

Worked example

flowchart LR
    U[User] -->|Sign in with Google| App[Application login endpoint]
    App --> Validate[Validate claims: iss, aud, email_verified, expiry]
    Validate --> Risk[Risk score the federation event: IP, device, geo, behavior]
    Risk -->|low risk, sensitive action not requested| Allow[Allow]
    Risk -->|elevated risk or sensitive action| StepUp[Conditional MFA: app-owned factor]
    StepUp -->|passes| Allow
    StepUp -->|fails or unavailable| Alt[Alternative verification: app-owned email/phone]
    Alt -->|verified| Allow
    Alt -->|fails| Block[Block and flag account]

Trace a concrete suspected-campaign scenario: the application observes a spike in federated sign-in attempts against many distinct accounts, all via Google, all from a narrow band of data-center IP addresses, over a short window, matching the profile of credential-stuffing tooling that has pivoted from targeting the application directly to targeting the external IdP instead (having found the application's own login endpoint well-defended). Attribute validation alone does not catch this, since the tokens themselves may be entirely valid, they represent genuinely compromised but real Google accounts. The risk-based scoring layer flags the anomalous IP and device pattern across these events; conditional MFA, requiring an application-owned factor the attacker does not have even if they control the victim's Google account, blocks the attempt from reaching any sensitive action; and throttling specifically on the account-linking and repeated-federated-attempt pattern slows the campaign's ability to iterate across many stolen social accounts looking for ones that map to valuable application accounts. If the pattern continues, the application can temporarily route new federated sign-ins from the flagged IP range through the alternative, non-federated verification path entirely, decoupling its own security posture from the compromised IdP accounts during the active campaign.

Trade-offs and pitfalls

• Treating a valid federated assertion as equivalent to a directly-verified login is the root mistake this whole defense exists to correct; the application's own authentication strength is only as strong as the weakest identity provider it accepts, unless it explicitly compensates at its own boundary.
• Skipping email_verified, issuer, and audience checks is a quiet, common implementation shortcut, since the login flow works identically from the user's perspective whether or not these are checked, which is exactly why it survives in production until actively exploited.
• Conditional MFA has to use a factor genuinely independent of the federated identity's own security; requiring "verify via your Google account again" as the step-up defeats the entire purpose if the Google account itself is what is compromised.
• Over-throttling federation specifically can create real user friction for a channel that is, for most users, the lowest-friction sign-in path available; throttling thresholds for federation events should be tuned against the same false-positive discipline as any other risk-based control, not simply set aggressively because the channel is currently under suspicion.
• The alternative verification flow only works if it was built and exercised before it is needed under pressure; a fallback path added reactively during an active incident, untested against real user flows, is itself a new source of errors and support burden at the worst possible time.

Direct answer

Pick a project that genuinely needed more than one function, and be specific about two things: what YOU owned (not what 'the team' did), and the one concrete mechanism that determined whether the collaboration worked, such as a shared definition of done, a clear handoff point, or clarity on who decided what when opinions differed. Vague answers ('we communicated well') sound rehearsed; specific answers sound lived-in.

What the story needs to show

Your specific contribution. Interviewers are listening for what you personally decided or built, distinct from what your collaborators did. If every sentence is 'we', the interviewer cannot tell what you'd do differently on the next team.

A mechanism-level explanation. Organize the story around one of three lenses:

• Shared goal: did every function agree on what 'done' looked like and how success would be measured, or was each function quietly optimizing for its own definition?
• Interface or handoff: was there a clear point where work crossed from one function to another, and was that point actually defined, or did people guess?
• Decision rights: when functions disagreed, was it clear whose call it was, or did disagreement just stall until someone got tired of arguing?

Honesty if it's a struggle story. The question explicitly allows 'succeed or struggle'. A good struggle story ends on what you changed about the collaboration, not on who was at fault.

Worked example

Situation: [your team] needed to deliver [a feature or initiative] that required real work from [Team A, for example a design or research function] and [Team B, for example a data or infra function], against a fixed external date.
Task: your role was the one connecting the three groups, for example owning the shape of the interface between design and engineering, or owning how data requirements got translated into a schema.
Action: early on, each function had a different idea of what 'done' meant for their piece, which caused rework when the pieces met. You wrote a short one-page agreement naming the shared definition of done and who would sign off on each handoff, and used it to resolve the next two disagreements without a meeting.
Result: the project shipped on the revised date, and the agreement itself became something the group reused on the next cross-functional piece of work, which is the real marker of a story about redesigning the collaboration rather than just pushing through it.

To make that skeleton concrete rather than a fill-in-the-blank: picture a checkout redesign that needed real work from the design function and the payments engineering function, against a fixed external date tied to a promotional campaign launch. The specific disagreement was about what 'done' meant for the new payment-method selector: design considered the screen done once every state (loading, error, empty) matched the approved mockups pixel-for-pixel, while payments engineering considered it done once the integration correctly handled every payment-provider response code, even ones with no mockup drawn yet. That mismatch caused two rounds of rework when a payment-provider error state shipped without a design pass. The one-page agreement that resolved it included this line: 'A screen is done when it matches an approved mockup for every state the payments API can return, and any new state discovered after mockups are drawn triggers a joint 15-minute review before either side builds it.' That single sentence is what let the two functions stop re-litigating 'done' every time a new edge case appeared, and both sides signed off on it before the next round of work began.

Trade-offs and pitfalls

• A generic 'we all communicated well' answer with no mechanism is the single most common weak version of this story, avoid it.
• Over-crediting the team at the expense of your own specific contribution leaves the interviewer unable to evaluate you.
• If you pick a struggle story, resist framing it as the other function's fault. The senior version of this answer explains what you changed about how the groups worked together, not who dropped the ball.
• The strongest answers show you redesigning a structure (a handoff, a shared definition, a decision rule), not just working harder inside a broken one.

Direct answer

In the last year I taught myself how to read query execution plans and reason about indexing, not because anyone assigned it, but because a recurring internal report kept getting slower and nobody had the bandwidth to look into why. I spent a handful of evenings learning to read plan output and understand how the database chooses an access path, then applied it directly to that report's query rather than treating it as a side hobby, and the fix noticeably shortened a report that had become one of the slowest in the weekly batch.

Structured elaboration

• Justify the "why this and not something else": pick something tied to a real, recurring cost you already feel, a slow report, a repeated manual step, a bug class that keeps recurring, rather than a trending technology with no attachment to your actual work.
• Keep the learning self-structured: with no assigned curriculum, the plan is whatever sequence of official docs and small experiments gets to "I can predict what this will do" fastest.
• Validate the new understanding against people who already know the area, even when nobody assigned this; a quick review confirms the understanding is actually right, not just plausible.
• Land it back in the work rather than a personal notebook; the skill only counts, for real impact and for describing it later, once it is applied to something that mattered.
• Check whether it stuck: months later, are you still reaching for it, or did it fade once the original problem was solved?

Worked example

A weekly finance reconciliation report kept taking noticeably longer to run as data grew, and it kept getting flagged as "just slow" without anyone owning a fix. Outside assigned work, I spent a handful of evenings over two weeks working through documentation on how a query planner chooses between an index and a full scan, reproducing small example queries locally rather than only reading passively. I then applied the plan-inspection tooling directly to the report's slowest query and found it was doing a full table scan on a column with no index, caused by an implicit type mismatch in a join condition. I added the right index and fixed the mismatch, and had a senior engineer sanity-check the change before it shipped, since this was genuinely new territory for me. The report went from being flagged in every week's slow-query review to not appearing at all. I kept using the same read-the-plan-first habit on later slow queries, so the skill stuck well past the original problem.

Trade-offs and pitfalls

• Self-taught understanding validated only against your own intuition, with no outside check, risks confidently shipping a fix that happens to work on the case you tested but does not generalize.
• Picking a skill purely because it is trendy, with no real problem behind it, produces knowledge that is hard to defend as impact and often does not stick.
• There is a real risk of scope creep: fixing one query can turn into re-architecting a system nobody asked you to touch; the discipline is applying the new skill to the specific problem, not treating it as license for a bigger, unrequested project.

Direct answer

A strong "owned it end to end" story has five ingredients in order: a measurable goal you set before writing any code or spec, a plan you decomposed and sequenced yourself, at least one real trade-off you made without full information, a concrete obstacle you personally cleared, and a number you can point to after launch. If any one of those is missing, it reads as "I was involved," not "I owned it."

Structured elaboration

Walk it in the order the interviewer actually cares about, not necessarily chronological order:

• Goals and success criteria first. Before scoping the work, write down what "worked" means in a way someone else could check without asking you. A vague goal like "improve the report" cannot be checked later; a goal like "cut turnaround from days to same day, and get most stakeholders self-serving" can.
• Scope and decompose the plan. Break the ask into a small number of milestones with a clear exit condition each (not "work on the pipeline" but "schema signed off," "pipeline in staging," "dashboard in user review"). This turns a vague mandate into something you can actually track.
• Milestones, timeline, and stakeholders. Name who has to sign off at each milestone and who is a pure consumer of the result. Coordinating means knowing which stakeholders block a milestone and which just need to be informed.
• The trade-off under incomplete information. This is usually the most differentiating part of the story. It should be a real decision where the right answer wasn't obvious, and you accepted a known downside on purpose, not a decision that was actually easy in hindsight.
• Removing obstacles during execution. Distinguish blockers you cleared yourself from ones you escalated, and be specific about which was which.
• Tools, timeline, and measured impact. Name the actual stack briefly and give a real, rounded number for the outcome, tied back to the goal you set at the start.

Worked example

I owned turning a weekly sales report, built by hand in spreadsheets, into a self-serve dashboard.

• Goal: cut the weekly prep time and get most regional stakeholders self-serving instead of asking me for numbers.
• Plan: four milestones over eight weeks: source-data audit and schema design (2 weeks), pipeline build (3 weeks), dashboard build and stakeholder review (2 weeks), rollout and training (1 week).
• Stakeholders: seven regional sales leads as the eventual users, one data engineer who reviewed the pipeline design, and my manager who signed off on scope.
• Trade-off under incomplete information: two possible source systems held the regional bookings data, and I didn't have time to fully audit both. I picked the one with cleaner existing documentation and knowingly accepted a small, known duplicate-record edge case rather than delay the whole plan by three weeks for a full audit of the alternative.
• Obstacle removed: the source database's nightly export was lagging by a full day, which would have made the dashboard's numbers stale on launch. I escalated to the database owner directly, since this was a genuine cross-team dependency I couldn't fix myself, and got a temporary priority export window.
• Tools and stack: a SQL warehouse for the pipeline, a scheduler for the nightly jobs, and a dashboard tool for the front end.
• Measured impact: prep time dropped from roughly 6 hours a week to about 30 minutes of review, a reduction of around 90 percent, and 6 of the 7 regional leads were self-serving within the first month.

Trade-offs and pitfalls

The most common failure in this answer is narrating a lot of activity with no number at the end, or presenting the plan as if it were obvious from day one, which quietly erases the trade-off decision that's the actual point of the question. A second failure is taking credit for a team decision without naming the specific piece that was yours to decide. Watch also for confusing being busy with having impact: a long list of completed tasks is not the same as a measured outcome tied to the goal you originally set.

Two frameworks that pull in genuinely different directions, useful precisely because they suit different kinds of ill-defined problems.

Framework 1: the OODA loop. OODA stands for Observe, Orient, Decide, Act, a rapid decision cycle originally developed for fighter pilot combat decisions and since adapted broadly to any fast-moving, uncertain situation. When it's most appropriate: time-critical, fast-changing situations where the cost of waiting for complete information exceeds the cost of acting on an imperfect but quickly-updated picture, such as live incident response or a fast-moving competitive situation. One concrete step under limited data: in the Observe phase, explicitly timebox data gathering to whatever's already available in minutes, not days, and in the Orient phase, write down specifically what's still missing so the next loop iteration targets that exact gap instead of re-observing everything from scratch. Worked example: an SRE, a site reliability engineer, facing a degraded service with no clear root cause observes the 3 dashboards already available (latency, error rate, deploy log) in about 5 minutes, orients on noticing a deploy 10 minutes before the onset, decides the hypothesis is a bad deploy, and acts by rolling it back; if that doesn't resolve it, the next loop starts within 5 minutes, now with that cause ruled out.

Framework 2: DMAIC. DMAIC stands for Define, Measure, Analyze, Improve, Control, a structured five-phase process from Six Sigma, a quality-improvement methodology. When it's most appropriate: longer-horizon, less time-critical problems where a repeatable, documented process matters, particularly recurring quality or consistency issues that other people will need to follow later; it's a poor fit for a genuine emergency, since its ceremony costs real minutes an incident can't spare. One concrete step under limited data: in the Measure phase, explicitly define a proxy metric you can measure right now, flagged clearly as a stand-in for the metric you actually want but don't yet have data for, with a stated plan to validate that proxy once real measurement becomes available, rather than blocking the entire process on getting perfect measurement first. Worked example: a support team wants more consistent ticket resolution across agents but has no existing quality-scoring data. Define: reduce the reopened-ticket rate. Measure: use the reopened-ticket count as an available proxy for resolution quality, even though a full rubric-based quality score would ideally be preferred, baseline 9%. Analyze: bucket reopens by agent tenure and ticket category to find where the problem concentrates. Improve: pilot a checklist for the worst-offending category. Control: track the reopen rate weekly after the pilot to confirm the gain holds.

The trap. Naming a framework without the 'when appropriate' half is the common shortfall: running DMAIC's full five-phase process during a live production incident burns minutes that matter far more than process rigor does in that moment, while running OODA's instinct-driven rapid loop on a multi-month systemic quality problem tends to produce thrashing, a string of quick fixes that don't add up to an actual, durable improvement.

Direct answer

Name two to three concrete goals that span a delivery outcome, a relationship or context goal, and a craft improvement, then state one specific milestone you'd check yourself against at the interim mark, not a general feeling of being "on track." The exact goals should shift with the horizon asked, first six months, first year, or two to three years, and with the seniority of the role.

Structured elaboration

• Match scope to horizon. A first-six-months goal set is mostly about ramp-up and one visible first contribution; a first-year set adds one meaningful, largely independent delivery plus established trust with key stakeholders; a two-to-three-year set shifts toward growth in scope, ownership, or a chosen specialization rather than a single deliverable.
• Cover three goal types, not just the technical one: a concrete problem solved or thing shipped, a context and relationship goal (understanding the systems and people whose buy-in you'll need for anything ambitious later), and a craft or process improvement you personally own end to end.
• Attach a leading indicator to each goal, something observable well before the deadline, not just the final outcome. This is what makes a mid-point check-in credible instead of a guess.
• Calibrate ambition to seniority. A candidate for a more senior role should include a scope or influence goal, not only execution goals; someone earlier in their career should show they understand ramp-up comes first.
• The single strongest closing move: state the concrete milestone you'd check yourself against at the interim mark, a specific thing shipped, a decision made, feedback actually received, rather than restating the goals as if listing them again proves progress.

Worked example

When I started a previous role, I set three goals for the year: ship one meaningful improvement to a system that mattered to the team, build real working relationships with the two or three people whose sign-off I'd need for anything ambitious later, and establish one process habit I could point to as mine. At the six-month mark, my checkpoint wasn't "do I feel settled," it was two specific things: had I shipped the first version of that improvement, and could I name the people who'd actually back me if I proposed the next, bigger version of it. Both were true, so instead of starting a new goal from zero, I used the credibility from the first six months to scope a larger version of the same problem for the rest of the year.

Trade-offs & pitfalls

• Vague goals ("learn a lot," "add value") signal you haven't actually thought this through; goals that depend entirely on something outside your control (a launch owned by another team) are the opposite failure.
• Loading up only on technical goals while skipping relationship or context goals tends to stall growth later, once the technical work is good you still need sponsors.
• Skipping the interim checkpoint definition means "on track" becomes something you decide retroactively rather than something you can actually check.
• Answering with only execution goals at a senior level under-signals; answering with only scope-and-influence goals very early on over-signals.

Direct answer

The mobile team's complaint ("responses are heavy and hard to work with") is really two separate problems: the payload carries fields nobody on that screen needs, and the client has to reshape what it gets before it can render. The fix is to stop shipping one fixed shape to every consumer and let the server compute exactly the fields each client asks for, while keeping the underlying feed data model the same. Given that mobile and web genuinely want different shapes from the same feed and mobile is bandwidth-constrained, GraphQL's field-selection model is the better protocol fit here, as long as it is constrained (persisted, allow-listed queries; depth and cost limits) so no client can accidentally request an expensive, unbounded query.

Structured elaboration

Requirements to design against: less client-side reshaping work, smaller mobile payloads, predictable caching behavior, and one schema that serves both clients without diverging codepaths.

Protocol comparison for this consumer mix:

Response-shaping principles regardless of protocol:

• Cursor-based pagination (opaque next_cursor token) instead of offsets, so the feed stays stable while new posts are inserted.
• Embed hot-path fields the card renders unconditionally (author name, avatar URL, like count); reference cold-path data the card doesn't render by default (full bio, high-resolution media, comment thread) via a separate call or a nested field the client only selects when it needs it.
• Serve media as pre-generated size variants (thumbnail/medium/full URLs) rather than one large image URL the client has to resize client-side; this is a bigger bandwidth win for mobile than almost any protocol choice.

Making GraphQL safe for a bandwidth-constrained mobile client:

• Ship the mobile app with a fixed set of persisted queries (each identified by a hash the client sends instead of the query text). The server only executes registered query hashes and rejects anything else with a 400 response; this closes off arbitrary expensive queries and lets a CDN cache responses by persisted-query hash the same way it would cache a REST URL.
• Enforce query depth and complexity limits server-side so a client cannot nest author.posts.author.posts... into an expensive fan-out.
• Keep the REST fallback in mind: a much lower-effort alternative that gets most of the same benefit is REST with a sparse-fieldset query parameter (?fields=id,text,author.name,author.avatar_url); it is worth naming as the pragmatic choice for a smaller team that isn't ready to run a GraphQL server.

Worked example

Same feed item, shaped two different ways from one underlying schema.

REST, default embedding (what the mobile team is complaining about):

{
  "id": "post_9182",
  "text": "Shipped the new onboarding flow today",
  "created_at": "2026-07-18T14:02:00Z",
  "author": {
    "id": "u_4471",
    "name": "Priya Shah",
    "avatar_url": "https://cdn.example.com/avatars/u_4471_full.jpg",
    "bio": "Product engineer, ex-Stripe, likes climbing",
    "follower_count": 3821,
    "following_count": 512
  },
  "media": [
    { "url": "https://cdn.example.com/media/m_1.jpg", "width": 4032, "height": 3024 }
  ],
  "like_count": 214,
  "comment_count": 18,
  "geo": { "lat": 37.7749, "lng": -122.4194 }
}

Everything the card actually renders on mobile is five fields; the rest (bio, follower/following counts, full-resolution image, precise geo) is dead weight on that screen.

GraphQL query the mobile client sends for a feed row (persisted, hash-identified in production; shown here as text for clarity):

query MobileFeed($cursor: String) {
  feed(cursor: $cursor, limit: 20) {
    edges {
      node {
        id
        text
        createdAt
        likeCount
        author { id name avatarThumbUrl }
        media { thumbnailUrl }
      }
    }
    pageInfo { endCursor hasNextPage }
  }
}

Response for one edge:

{
  "id": "post_9182",
  "text": "Shipped the new onboarding flow today",
  "createdAt": "2026-07-18T14:02:00Z",
  "likeCount": 214,
  "author": { "id": "u_4471", "name": "Priya Shah", "avatarThumbUrl": "https://cdn.example.com/avatars/u_4471_thumb.jpg" },
  "media": [{ "thumbnailUrl": "https://cdn.example.com/media/m_1_thumb.jpg" }]
}

The web client, on the same schema, asks a different query for the same node and legitimately gets bio, counts, and full-resolution media because its screen renders them; no server-side branching by client type, no separate mobile endpoint to maintain.

Trade-offs and pitfalls

• GraphQL's caching story is genuinely worse than REST's out of the box (an arbitrary query has no stable URL); persisted queries recover most of it by giving each allowed shape a stable, cacheable identifier, but that is an extra piece of infrastructure to build and operate, not a free win.
• The classic GraphQL trap is the N+1 resolver problem: naively resolving author per feed item issues one database call per post instead of one batched call for all authors in the page. This needs a batching layer (a per-request data loader that collects author IDs across the whole response and issues one query) or the fix does not show up until load testing.
• Over-embedding (putting the full author profile in every feed item) reproduces the original complaint under a new protocol; under-embedding forces one extra round trip per screen, which is worse than a slightly larger response on a high-latency mobile network. The embed-vs-reference line should be drawn by "does this screen render it unconditionally," not by what's convenient to fetch.
• A REST sparse-fieldset compromise is a legitimate answer for a team not ready to operate a GraphQL server; naming it as the deliberately-rejected alternative (and why the full field-selection model wins here specifically because mobile and web diverge so much) is what separates a considered answer from a technology-preference answer.

Clarify goal
Keep library components free of memory leaks by removing DOM refs and event listeners when components are removed — support both explicit teardown and automatic detection.

Patterns

• Explicit teardown API
  • Expose mount/unmount or destroy method that removes listeners, cancels timers, nulls refs.
  • Example:

// simple component factory with explicit destroy
function Card(root) {
  const onClick = () => console.log('clicked');
  root.addEventListener('click', onClick);
  return {
    destroy() {
      root.removeEventListener('click', onClick);
      // clear other refs or intervals
    }
  };
}

• Centralized listener registry

  • Track attached handlers in a Map/WeakMap and remove them in destroy.

• Event delegation

  • Attach high-level listeners (document or container) to reduce per-component handlers; remove only when last component unmounted.

• Automatic detection

  • Use MutationObserver to detect node removal and call cleanup for known nodes (store cleanup function in WeakMap keyed by node).
  • Use WeakRef + FinalizationRegistry (where supported) to run cleanup when object is GC'd — note non-deterministic timing and limited browser support.

const cleanupMap = new WeakMap();
const mo = new MutationObserver(records => { /* detect removed nodes and call cleanupMap.get(node) */ });

• AbortController pattern

  • Pass an AbortSignal to async tasks and listeners so they can cancel on teardown.

• Web Components integration

  • Implement connectedCallback/disconnectedCallback to auto-clean.

Trade-offs

• Explicit API: deterministic and simple; requires discipline from consumers.
• MutationObserver/FinalizationRegistry: automatic but adds complexity, possible perf cost, and is non-deterministic.
• Event delegation: fewer handlers but more logic for event routing.

Framework integration

• React/Vue: expose mount/unmount hooks; provide small adapter that calls component.destroy() in useEffect cleanups or beforeUnmount.
• Offer thin wrappers: e.g., React hook useLibraryComponent(nodeRef) that mounts and ensures cleanup.

Recommendation
Provide explicit destroy + WeakMap registry + optional MutationObserver fallback. Document integration adapters for popular frameworks and prefer AbortController for async work.