Using GraphQL to Power Multi-Framework Apps in Salesforce with React
For most of Salesforce's history, front-end developers faced a hard choice: build with Lightning Web Components (LWC) and get full platform integration, or reach for React and lose native access to Salesforce's data, security, and governance model. That trade-off has now changed. With Salesforce Multi-Framework — announced at TrailblazerDX 2026 and currently in open beta — React apps can run natively on the Salesforce platform, sitting alongside your existing LWC components rather than replacing them. And the piece tying it all together on the data side is GraphQL.
This post looks at how GraphQL fits into a React-on-Salesforce architecture, why it matters, where this pattern is headed, and a concrete use case you can build today.
A Quick Recap: What Is Salesforce Multi-Framework?
Salesforce Multi-Framework is a framework-agnostic runtime on the Agentforce 360 Platform that lets developers build native Salesforce apps using React (with more frameworks planned for the future). Instead of compiling a React app into a static resource and hacking it into a Visualforce page or lightning:container — the old workaround — Multi-Framework deploys your React app as a first-class metadata type called a UI Bundle. It runs on Salesforce's core application servers, side by side with LWC, and can be surfaced through the App Launcher.
Crucially, this isn't a replacement for LWC. Your existing Lightning Web Components keep working exactly as before. Multi-Framework is additive — a second front-end option for teams that want the broader React ecosystem (component libraries, routing, state management, tooling) without giving up Salesforce's authentication, security, and governance.
Where GraphQL Fits In
The real question with any new front-end framework on Salesforce is: how does it talk to data? This is where GraphQL becomes the backbone of the architecture.
React apps built with Multi-Framework use a package called @salesforce/sdk-data — often referred to as the Data SDK — to interact with Salesforce data. Instead of the reactive @wire adapters LWC developers are used to, React components use standard patterns like useEffect and useState, but under the hood, the SDK runs GraphQL queries and mutations against the UI API.
A few things make this pairing particularly effective:
- One unified data interface. The same Data SDK works whether your app is an internal tool opened through the App Launcher or a customer-facing portal on an Experience Cloud site. The SDK is runtime-aware, so you write the same GraphQL-based data-access code regardless of where the app is deployed.
- Exact field selection, in one request. Just like GraphQL's core value proposition on any platform, a React component can request precisely the fields and nested relationships it needs — an account, its contacts, and their open cases, for example — in a single round trip, instead of stitching together multiple REST or Apex calls.
- Governance built in, not bolted on. Because the React runtime is embedded inside the platform layer, every GraphQL query and mutation is still subject to Salesforce's sharing rules, field-level security, and permissions — the same protections your LWC components already rely on.
- Chained operations in a single request. Recent platform updates allow GraphQL mutations to reference fields returned by an earlier operation in the same call (not just a record ID), so you can create linked records — a parent and its children, for instance — in one round trip instead of several.
In short: React gives you the frontend flexibility, and GraphQL gives you a single, permission-aware, precisely-shaped data layer underneath it — without needing a custom middleware or a separate backend-for-frontend service.
Advantages of This Approach
1. No more framework-vs-platform trade-off. Teams that want React's ecosystem — its component libraries, its hiring pool, its tooling — no longer have to give up native Salesforce data access, authentication, or governance to get it.
2. Fewer round trips, faster apps. Because GraphQL lets a component ask for exactly the data it needs across multiple related objects in one call, React apps built this way avoid the classic over-fetching and under-fetching problems of REST, translating into snappier UIs, especially on data-heavy dashboards.
3. Consistent security model. Since GraphQL queries run against the UI API, the same field-level security and sharing rules that protect your Lightning pages automatically protect your React app's data — there's no separate authorization layer to build or maintain.
4. Reusable skills and code across runtimes. Because the Data SDK is runtime-aware, the same GraphQL-based data access code can power an internal employee tool and a branded customer portal on Experience Cloud, cutting down on duplicated data-fetching logic.
5. Bring your own tooling. Standard React tooling — Vite, Vitest, npm packages, React DevTools, hot module reload — all work as expected, so teams don't have to relearn a Salesforce-specific build process just to get productive.
The Futuristic Demand: Why This Matters Going Forward
A few trends suggest this pattern is only going to become more central to Salesforce development:
- The framework-choice pressure is real. For years, teams building complex, highly customized front ends had to either compromise on LWC's constraints or host a separate React app off-platform (often on Heroku or similar), wiring up their own OAuth flows and losing native platform benefits. Multi-Framework directly removes that trade-off, and as it matures toward general availability, expect more teams to standardize on it for net-new, complex UI work.
- More frameworks are coming. React is supported today, with Angular and Vue expected in future releases. As the runtime becomes framework-agnostic in practice (not just in name), GraphQL — not any one framework's data-fetching convention — becomes the common language every framework uses to talk to Salesforce data.
- AI-assisted app generation is layering on top. Tools like Agentforce Vibes can already generate React code, GraphQL queries, and the associated Salesforce metadata from a natural-language description of the component you want. As this tooling matures, GraphQL's declarative, schema-driven nature makes it a natural target for AI code generation — you describe the data you want, and the tool writes the precise query.
- Micro-frontend embedding is on the roadmap. Beyond standalone React apps, Salesforce has also signaled plans for embedding React components directly into Lightning pages as micro-frontends, which would let GraphQL-powered React widgets live inside existing Lightning Experience pages alongside LWC components.
Put together, this points toward an ecosystem where GraphQL becomes the default, framework-agnostic way to move data in and out of Salesforce — regardless of which UI framework a particular team or component happens to use.
A Practical Use Case: A Customer-Facing Order Tracking Portal
Consider a company that sells industrial equipment and wants a branded, self-service portal where customers can track their orders, view shipment status, and see related service cases — all without contacting support.
Why this fits the pattern well:
- The portal needs a highly customized, brand-specific UI — exactly the kind of experience React's ecosystem (design systems, animation libraries, custom layouts) is suited for, beyond what out-of-the-box LWC base components easily support.
- The data itself is relational: an Account, its Orders, each order's shipment status, and any related Cases — precisely the kind of nested, multi-object data a single GraphQL query can retrieve in one request instead of several sequential calls.
- It needs to be customer-facing, deployed through Experience Cloud, while still respecting the same sharing rules and field-level security that protect internal data — which GraphQL against the UI API handles automatically.
- As the business grows, the same Data SDK and GraphQL queries that power the customer portal could be reused, with different permissions, for an internal support-agent view of the same data — avoiding duplicate data-access code between the two experiences.
A rough shape of the GraphQL query powering the order-tracking screen might look like this:
query GetCustomerOrders($accountId: ID!) {
uiapi {
query {
Account(where: { Id: { eq: $accountId } }) {
edges {
node {
Name { value }
Orders__r {
edges {
node {
OrderNumber__c { value }
Status__c { value }
ShipDate__c { value }
Cases__r {
edges {
node {
CaseNumber { value }
Status { value }
}
}
}
}
}
}
}
}
}
}
}
}
One request returns the account, every order tied to it, and any related cases per order — everything the portal's UI needs to render a complete order-tracking view, wired into a React component through the Data SDK.
Wrapping Up
Salesforce Multi-Framework closes a long-standing gap for developers who wanted React's flexibility without sacrificing native Salesforce integration. GraphQL is what makes that pairing work in practice — giving React components a single, precise, permission-aware way to read and write Salesforce data, whether the app lives behind the App Launcher or out on a public-facing Experience Cloud site. As more frameworks join Multi-Framework and AI-assisted tools generate GraphQL queries automatically, this combination looks set to become a standard part of the Salesforce development toolkit rather than a niche pattern — well worth exploring now while it's still in beta.
