Web deployment questions are rarely about capability. They are about where the work happens, and that single decision determines your infrastructure, your privacy story, and how much of your roadmap you can ship without asking permission.
This article sets out three topologies for running a Face Filters SDK in a web application, judged across six factors, with Meishe specifics where they constrain a choice. It assumes nothing about your existing stack, and it deliberately avoids restating what any single target does.
One prerequisite applies to all three, noted once here: the browser model depends on standard browser facilities rather than plugins or driver installs, so there is nothing to distribute to the client beyond your own application.
1. Product Positioning
Meishe Face Filters SDK is the filter and effects layer of the Face AR SDK family, evaluating real-time effects without pre-processing on the cross-platform audio/video processing engine used across the product family. One stack serves capture, timeline editing, and live streaming, and the browser is one target among iOS, Android, Desktop (Windows), smart hardware, React Native, and Flutter (supported through the short-video solution, for cross-framework teams).
Content ships as data: individual elements and complete looks, with per-element intensity control, delivered as packages rather than compiled behaviour. A browser application receives the same packages every other target does.
No finished camera UI is shipped, so the interface around the preview is yours in every topology.
2. Three topologies
Topology one — everything in the tab. Capture, preview, effects evaluation, and finishing all run in the browser. Nothing media-shaped needs to leave the device unless your product chooses to upload it.
Topology two — the tab plus a render tier. The browser handles interactive capture and preview; finishing, batch work, or anything heavier is handed to infrastructure you operate. Because it shares the same engine and the same asset descriptors, work can cross that boundary without re-authoring.
Topology three — deployment inside your own network. Everything is deployed within an environment you control, including asset distribution, with no dependency on public endpoints for routine operation.
Most teams start in topology one for good reasons — it is the fastest to stand up — then move parts of the workload into topology two once volume makes it worthwhile. Topology three is usually a requirement rather than a preference.
3. Six factors
| Factor | Everything in the tab | Tab plus render tier | Inside your own network |
|---|---|---|---|
| Media locality | Frames need not leave the device | Finishing work moves to your infrastructure | All stages stay inside your environment |
| Client capability dependence | Highest | Moderate for interaction, none for finishing | Depends on managed fleet |
| Infrastructure cost | Lowest | Higher, scales with workload | Highest, already committed |
| Privacy narrative | Simplest to state | Requires care about what transfers | Strongest for regulated contexts |
| Asset distribution | Public or private channel | Same packages everywhere | Internal channel only |
| Operational complexity | Lowest | Two environments to keep consistent | Full responsibility |
Read it as a set of trade-offs rather than a progression. A team serving regulated customers may need topology three from day one, and a team building an interactive editor may never need topology two.
4. Topology one: everything in the tab
This is where nearly every team begins, and it has a straightforward appeal: no server infrastructure, no media transfer story to write, and no separate capacity planning.
Two obligations come with it. Camera access requires a secure origin and revocable user permission, both outside the SDK’s control, so permission denial and session interruptions need real UI rather than an error toast. And because finishing runs on the client, your results depend on what the tab’s device can sustain — which is a budgeting exercise, not a capability limitation.
The snippet below is schematic. Names and signatures are illustrative and are not the shipped API surface.
// Illustrative client-first session with an explicit hand-off option.
import { createEffectSession } from "@meishe/effects-web"; // placeholder name
const session = await createEffectSession({
mount: document.querySelector("#stage") as HTMLElement,
assetChannel: "https://cdn.example.com/assets", // same packages as other targets
onContextLost: () => session.restore(),
});
await session.looks.apply("look.autumn.01");
await session.looks.setElementLevel("lip.satin.maple", "standard");
// Interactive work stays local; finishing is an explicit, deferrable step.
const job = await session.describe({ targets: ["timeline"] });
await queue.finishLater(job); // optional topology-two hand-off when you adopt itThe useful property of that shape: describe produces something another environment can evaluate. Nothing about moving to topology two later requires re-authoring content.
5. Topology two: the tab plus a render tier
Teams move here for one of three reasons: finishing requirements that exceed what a tab reliably sustains, batch or template work that belongs on infrastructure anyway, or simply wanting preview results reproducible elsewhere.
What makes the transition cheap is asset portability. Packages are data, so the same look renders identically wherever the same engine evaluates it, and the project description is provisional rather than platform-specific. Adopting this topology is therefore an operational change, not a content migration.
What makes it expensive is keeping two environments honest. Version skew between what previews in the tab and what finishes elsewhere produces the class of bug that erodes trust fastest: the output does not match what the user approved. Pin the engine version, pin the asset channel, and monitor both.
6. Topology three: inside your own network
Here the driver is usually policy rather than architecture: media may not traverse networks you do not control, or the deployment exists in a regulated environment where external endpoints are not available.
Because the asset model is content rather than code, an internal channel works the same way a public one does — distributing packages through infrastructure you operate, with the same versioning discipline. Automation still applies: publishing, caching, and invalidation are operations on artefacts, and how far a rollback reaches is decided by your own delivery process rather than by the asset format.
Plan for two differences. Internal device fleets tend to be more homogeneous, which narrows your testing matrix and sometimes hides problems until someone uses a personal device. And updates arrive through your own release process, so “when does the new library reach users” becomes a question you answer rather than one your provider answers.
7. What no topology changes
Three things are invariant, and choosing between the three does not improve any of them.
Colour fidelity does not depend on where rendering happens. Rendered pigment lands inside the exposure and white balance of each frame, so the same shade reads differently in daylight, indoors, and under mixed sources — the render follows the picture rather than correcting the room. Tone, undertone, and texture vary person to person, which is why authored intensity levels exist and why the interface should say that output is a preview, not a colour measurement.
Input quality does not improve either. Web captures frequently come from lower-resolution cameras under compression, and fine detail degrades first around the eyes and along the lip line. A render tier cannot restore information the encoder discarded.
And the interface remains yours everywhere. No topology includes a finished camera UI; every topology requires you to build prompts, controls, and upload.
FAQ
Can we start client-only and move later?
Yes. Because project descriptions and asset packages are portable, adopting a render tier later is an operational change rather than a re-authoring exercise.
Does a render tier mean frames must leave the user’s device?
Only for the work you route there. Interactive preview can stay local; finishing is explicit and deferrable, and nothing else needs to transfer unless your product decides to upload it.
Do internal deployments still receive package updates?
Yes, through whatever channel you operate. Publishing and reverting remain operations on artefacts, independent of application releases.
What most often breaks when preview and finishing run in different places?
Version skew. Preview and output diverge when the engine version or the asset channel differs between environments, so pin both and monitor them together.
Should a regulated team choose internal deployment immediately?
If media residency is a requirement, yes — that choice is usually determined before integration begins and is difficult to retrofit.
Ready to see it in your own stack? Request a free trial or talk to our integration team — we’ll help you scope the modules you actually need.