Ga naar inhoud
SteveTechArcSteveTechArc Courses

Browser or Server

Deze inhoud is nog niet vertaald.

Module 4 of 6 in the chapter Understanding the System Landscape, chapter 5 of the Integration Architect course. Each module stands on its own. Previous: What the Arrow Means on a Landscape · Next: Point to Point, or Hub and Spoke

The question this module answers: Where does an integration actually run: in the user’s browser, or on a server? And why does that change the design?

When people picture an integration, they picture two servers talking: Salesforce calling an ERP, a partner calling Salesforce. Most integrations are like that. But not all of them. Some of them happen in the browser, on the user’s own device, and nobody draws them.

There are layers where we integrate. It comes down to browser and server. And then the server side splits again: the business logic, and the data, all the way down to database transactions.

The Lateral Call

Section titled “The Lateral Call”

Browser or server really comes down to one question: which one is the client? In chapter 2, the client was whoever starts the call. On the server side, Salesforce is the client: it calls the other system. In a browser-level integration, the browser is the client: it calls the other system itself, and Salesforce isn’t in that conversation at all.

Here’s what that looks like. A website sends a page to the browser. And then the browser makes a call to another site, a lateral call, without going back to the original server that served the page.

The classic example is a mashup, a page made from more than one site. You’ll also hear it called an iframe, a frame with another site inside it. They all mean the same thing: we send a web page, and then inside that web page, the browser calls another site.

At Steve Trucking, a dispatcher opens today’s route, and the page shows a map with every stop on it. There are two ways to build that.

On the server. Salesforce asks the map service, such as Google Maps, for the map itself, and sends the dispatcher one page with the map already in it. Salesforce is the map’s client. The key to the map service never leaves Salesforce.

The lateral call Two frames. On the left, the user's device: a dispatcher's browser. On the right, the servers: Salesforce, Steve Trucking's org with today's stops, higher up, and further right, level with the browser, a map service on another site, such as Google Maps, which needs a key. Frame 1, on the server: the browser asks Salesforce for the page; Salesforce asks the map service for the map itself; and Salesforce sends back one page with the map included. Under the browser: no key in the browser; Salesforce is the map's client. Frame 2, the mashup: the browser asks for the page; Salesforce sends the page and today's stops as JSON; the browser sends the stops and the key straight to the map service, a lateral call that doesn't go back through Salesforce; and the map service sends back the map, with a pin for each stop. Under the browser, in amber: the key is in the page; the browser is the map's client, and anyone can view it. Underneath: which one is the client? On the server, Salesforce calls the map, and the key never leaves it; in the mashup, the browser calls the map, and the browser needs the address, the key and the protocol, and so does anyone who opens the page. THE USER'S DEVICE THE SERVERS A dispatcher's browser shows today's route Salesforce Steve Trucking's org: today's stops A map service another site, such as Google Maps; needs a key No key in the browser Salesforce is the map's client 1. asks for the page 2. Salesforce asks for the map 3. one page, map included Which one is the client? On the server, Salesforce calls the map, and the key never leaves it. In the mashup, the browser calls the map, and the browser needs the address, the key and the protocol: so does anyone who opens the page. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Frame 1 of 2: on the server, Salesforce is the map’s client, and the key stays in Salesforce.

In the browser, as a mashup. Salesforce sends the page, and with it today’s stops as JSON: a list of locations. The page hands that JSON to the map service, straight from the browser. The map comes back with a push pin for each stop. Now the browser is the map’s client, and it needs everything a client needs to make the call.

The lateral call Two frames. On the left, the user's device: a dispatcher's browser. On the right, the servers: Salesforce, Steve Trucking's org with today's stops, higher up, and further right, level with the browser, a map service on another site, such as Google Maps, which needs a key. Frame 1, on the server: the browser asks Salesforce for the page; Salesforce asks the map service for the map itself; and Salesforce sends back one page with the map included. Under the browser: no key in the browser; Salesforce is the map's client. Frame 2, the mashup: the browser asks for the page; Salesforce sends the page and today's stops as JSON; the browser sends the stops and the key straight to the map service, a lateral call that doesn't go back through Salesforce; and the map service sends back the map, with a pin for each stop. Under the browser, in amber: the key is in the page; the browser is the map's client, and anyone can view it. Underneath: which one is the client? On the server, Salesforce calls the map, and the key never leaves it; in the mashup, the browser calls the map, and the browser needs the address, the key and the protocol, and so does anyone who opens the page. THE USER'S DEVICE THE SERVERS A dispatcher's browser shows today's route Salesforce Steve Trucking's org: today's stops A map service another site, such as Google Maps; needs a key The key is in the page the browser is the map's client: anyone can view it 1. asks for the page 2. the page, and the stops as JSON 3. the stops, and the key 4. the map, a pin for each stop Which one is the client? On the server, Salesforce calls the map, and the key never leaves it. In the mashup, the browser calls the map, and the browser needs the address, the key and the protocol: so does anyone who opens the page. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Frame 2 of 2: the mashup. The browser is the map’s client, and the key comes to the page.

Both pages look the same to the dispatcher. The difference is which one is the client, and that’s what decides where the key lives.

On the landscape, the browser-level call needs its own arrow: a second arrow from the browser to that second system. If you only draw the arrow to Salesforce, nobody will see that the browser is talking to someone else.

What the Browser Has to Know

Section titled “What the Browser Has to Know”

To call another system, you need three things: the location, the authentication, and the protocol. Where is it, how do I prove who I am, and how do we talk?

On the server, Salesforce holds all three. The browser never sees them. In a browser-level integration, the browser needs them. And whatever the browser has, anyone using the browser can see. Right-click, view source, and there it is.

I once saw a post where someone did exactly that on a website. In view source, in clear text: the client ID, the client secret, the username and the password. Everything you’d need to call the second system. Cut and paste, and you’re in.

Not every key in a page is a mistake. Some keys are meant to be there: a map key, for example, is made to be used from a browser, and the map provider lets you restrict it to your own site, so a key copied from your page doesn’t work anywhere else. Google’s own guidance for its map keys starts with “Restrict your API keys” (Google Maps Platform security guidance (opens in a new tab), Google for Developers, checked 2026-11-01). The real failure is a secret in the page: a client secret, a password, a key that unlocks data.

Salesforce says it plainly for Lightning web components: “Providing your keys in JavaScript isn’t secure.” If a call needs authentication headers, Salesforce’s advice is to send it from Apex, on the server (Call APIs from JavaScript (opens in a new tab), Lightning Web Components Developer Guide, checked 2026-11-01). That’s the choice from the diagram: if it needs a secret, the server makes the call.

So for every browser-level integration, ask: how am I sending the credentials, and how do I make sure view source, or someone looking through the page, can’t get them? If you can’t answer that, do it on the server.

Browser-Level Integration in Salesforce Today

Section titled “Browser-Level Integration in Salesforce Today”

Salesforce gives you ways to do it in both directions.

Another site’s data inside Salesforce. A Lightning web component can call another site from the browser with fetch(). By default it can’t: in Salesforce’s words, “By default, you can’t make WebSocket connections or calls to third-party APIs from JavaScript code. To do so, add a remote site as a trusted URL (previously CSP Trusted Site)” (the same page). That’s an admin decision in Setup, on the Trusted URLs page. And the other site has to agree too: a browser only lets a page read another site’s answer when that site allows it, a rule called CORS (Fetch Standard (opens in a new tab), WHATWG).

Another app inside Salesforce. A frame keeps the two sites apart: the browser won’t let one site’s page reach into another’s, so the app inside can’t read Salesforce’s page, and Salesforce can’t read the app’s. That’s protection. But sometimes you want them to work together: Salesforce shows your own accounting system, signs the user in to it automatically, and the accounting system tells Salesforce to change the page or push data back. That’s what Canvas is for. It’s current, and new Canvas apps are set up through an External Client App (Canvas Developer Guide (opens in a new tab), version 68.0, Winter ‘27, checked 2026-11-01).

Salesforce inside another app. Going the other way, Lightning Out 2.0 is, in Salesforce’s words, “Salesforce’s recommended way to run LWCs outside the Salesforce Platform.” It runs the components in iframes, to keep them apart from the host page, and carries messages between them with window.postMessage() (Lightning Out 2.0 Is Now Generally Available in Winter ‘26 (opens in a new tab), Salesforce Developers Blog, checked 2026-11-01).

Your own app, as part of a page. New in Winter ‘27, in beta: an app built with React or Angular on the Salesforce Platform can be embedded in a Lightning page as a microfrontend. Salesforce runs it in a sandboxed iframe with a two-way channel: the page passes data down, and the app sends events back up. It’s only for apps served from Salesforce’s own domain, so it doesn’t replace Canvas or Lightning Out for an app that lives somewhere else (The Salesforce Developer’s Guide to the Winter ‘27 Release (opens in a new tab), Salesforce Developers Blog, checked 2026-11-01).

When It Breaks in the Browser

Section titled “When It Breaks in the Browser”

Browser-level integrations fail in ways server integrations don’t, because every user’s browser is different.

The common one is cookies. An app inside a frame often keeps the user signed in with a cookie from its own site, a third-party cookie from the page’s point of view. Safari has blocked third-party cookies by default since 2020 (Full Third-Party Cookie Blocking and More (opens in a new tab), WebKit, 2020). Chrome decided in 2025 to keep them on by default (Next steps for Privacy Sandbox (opens in a new tab), Google, April 2025). Both checked 2026-11-01. So the same embedded app can sign in fine for one user and fail for the next, and the only difference is the browser. When someone says “it works on my machine”, ask which browser.

The others: a site that isn’t a trusted URL yet, a site that doesn’t allow the call under CORS, or a site that refuses to be shown in a frame at all. Each one shows up in the browser’s own console, not in Salesforce’s logs. That’s worth knowing before you go looking.

Three Places an Integration Happens

Section titled “Three Places an Integration Happens”

Then there’s the server side, and it has two layers.

Process level is the business logic. The browser talks to the server, and the server, because of something it’s processing, calls another system: a flow calls out when a delivery runs late, a trigger fires, a batch job runs. The credentials stay on the server.

Data level is about keeping copies in step. An ERP pushes data into your account objects every night; the delivery statuses are copied out to the analytics store. It still goes through APIs, but the purpose is the data, not one user’s action.

Browser, process, data Three columns. In the browser, the UI, the page calls another site: it starts in the user's browser; the browser needs the address and the key; examples are a component calling another site, another app inside Salesforce with Canvas, and Salesforce inside another app with Lightning Out 2.0. In a process, the business logic on a server: it starts in a flow, a trigger or a job; the server holds the credentials; examples are a flow calling out when a delivery runs late, and Apex calling a partner's API. At the data, keeping copies in step: it starts on a schedule or a change; the integration layer holds the credentials; examples are an ERP pushing accounts in, and statuses copied to the analytics store. Underneath: most projects mix all three; Salesforce's integration patterns name process and data integration, and virtual integration; browser-level integration is this course's own addition. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.52.0", "built": "2026-10-29", "id": "DGM-INT-LS-08", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison/side-by-side 0.5.0", "theme": "stevetecharc 1.4.0"} In the browser the UI: the page calls another site Starts in the user's browser The browser needs the address and the key A component calling another site Another app inside Salesforce: Canvas Salesforce inside another app: Lightning Out 2.0 In a process the business logic, on a server Starts in a flow, a trigger or a job The server holds the credentials A flow calls out when a delivery runs late Apex calls a partner's API At the data keeping copies in step Starts on a schedule or a change The integration layer holds the credentials An ERP pushes accounts in Statuses copied to the analytics store Most projects mix all three. Salesforce's integration patterns name process and data integration (and virtual integration); browser-level integration is this course's own addition. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Browser, process, data: three places an integration happens.

A lot of the time, you’re going to mix and match: a Canvas app in the page, flows behind it, and a nightly data load underneath.

Salesforce’s own integration patterns sort integrations into three categories: data integration, process integration, and virtual integration, which reads data where it lives without copying it. And they say, fairly, “While Salesforce allows for user interface (UI) integration, mashups, for example, such integration is outside the scope of this document” (Integration Patterns (opens in a new tab), Salesforce Architects, checked 2026-11-01). This course puts the browser on the landscape too, because that’s where the secrets leak and the cookies break. Virtual integration comes back in chapter 18.

What an Architect Decides Here

Section titled “What an Architect Decides Here”
  • For every integration: does it run in the browser, in a process or at the data?
  • For every browser-level call: its own arrow on the landscape, from the browser.
  • What the browser has to know, and that no secret ever reaches the page. If it needs a secret, the server makes the call.
  • Which sites are trusted URLs, who approves them, and whether the other site allows the call.
  • For embedded apps: Canvas or Lightning Out 2.0, and how sign-in works in every browser your users have.

Beyond the exam: what AI changes. Many AI features arrive as a browser-level integration: a chat window on a page, a widget that calls an AI service directly from the user’s browser. Ask the same three questions: where is it, how does it sign in, and how do they talk? If the page holds the key to the AI service, anyone can copy it and run up your bill, or worse. And what the user types into that window goes straight from their browser to another company. Draw that arrow, and decide what’s allowed to travel along it.

Explore

Section titled “Explore”

Volg mij

© 2023–2026 Twinshark LLC. All rights reserved. · Gebruik van content

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.

Juridische mededelingen zijn in het Engels, en de Engelse versie is leidend.