DEV Community: Cao Wen

What I learned building a live-streaming widget with Go + SRS (and one iframe)

Cao Wen — Sun, 15 Nov 2026 11:59:52 +0000

I run a small live-selling widget for Shopify and WooCommerce stores. Not a startup — one person, one Go binary, SRS for media. A few decisions turned out to matter more than the feature list, so I'm writing them down.

1. Iframe instead of a script tag

The first version was <script src=".../shell.js" data-key="...">. It injected a floating player into the merchant's page.

It broke constantly. Theme CSS leaked in, my CSS leaked out, and every third-party script on the page fought with mine. Worse: the API key sat in the DOM of a public storefront page.

What I ship now:

<iframe src="https://example.com/embed?shop_id=6" width="375" height="667" style="position:fixed;right:20px;bottom:20px;border:0"></iframe>

Same iframe, one public shop id, zero secrets in the markup. The merchant pastes four lines. If they break their theme, they don't break the player.

Trade-off: iframe can't inherit the store's fonts. For a player that's fine — isolation is worth more than pixel-matching.

2. SRT for the ingest path, not just RTMP

RTMP is everywhere and everyone supports it. It's also TCP with fixed latency and handles packet loss badly — which is the normal condition for a merchant streaming from a phone on store wifi.

SRT gives you loss recovery and configurable latency for maybe 200ms more delay. For live selling, 200ms of extra delay costs nothing; a frozen frame costs the sale.

I still expose RTMP for compatibility, but the default config in my docs is SRT, and the bitrate defaults are deliberately conservative (1500–2000 kbps, 2s keyframe). Cross-border upload can't sustain 6 Mbps and the failure mode is a black player.

3. Enforce limits on the server, never in the widget

Viewer caps, stream keys, tier upgrades — all of it lives in the Go backend. The widget only renders.

Early on I had a cap check in the frontend so it would "respond faster". It took one person with devtools to watch a 200-viewer room on a 20-viewer plan. Anything that costs money has to be a server-side decision, even if the client shows a cached number.

4. The bug that taught me the most was caching

I deploy static assets by scp'ing them into place and restarting nginx. Everything under /static was served with Cache-Control: max-age=604800, immutable.

The day I added a feature that needed new i18n keys, every returning user got the new HTML with the old dictionary — and saw raw keys like lc_title on screen instead.

Now every asset reference carries a build version. immutable is only safe if the URL changes when the content does. Obvious in hindsight; not obvious at 2am.

What's still hard

Payments. If you're a solo developer outside the US/EU, merchant onboarding is the real boss fight — not the media pipeline. I've been through two providers' review processes and neither outcome was about code.

Feedback welcome

The whole thing is at https://durianlive.com — happy to hear what I got wrong, especially from anyone who has run live video at small scale.

How do small stores handle live selling without commission?

Cao Wen — Sat, 14 Nov 2026 10:44:37 +0000

Live selling shouldn't cost you 10% of every order

Cao Wen — Fri, 13 Nov 2026 12:54:17 +0000

I'm the founder of DurianLive. This is the business problem we ran into,
and what we changed — not a technical deep dive.

The pattern

Almost every live shopping tool asks the merchant to do the same thing:
move the sale to the tool's platform. You get a spike in orders, then a
bill for the commission, and the customer — their email, their purchase
history, their attention — stays with the platform.

The second problem is the catalog. You have to rebuild your products
inside the tool: same photos, same descriptions, uploaded a second time.

The third is the redirect. The shopper was on a product page, ready to
buy. Now they're in another tab, and your checkout is three clicks away.

What we changed

The show runs on the merchant's own website. A small player sits in the
corner of the store. A shopper browsing a product page can open it, watch,
ask a question, and click a product card — which takes them to the product
page they already have, with the checkout they already use. They never leave.

What that means in practice:

You keep the sale. Payments run through the existing checkout — Shopify, WooCommerce, whatever the store has. We never touch the money and never take a percentage.
You keep the customer. Orders, emails, and browsing behaviour stay in the merchant's dashboard and email tool, not ours.
You keep your catalog. Product cards link to the pages the merchant already maintains. Nothing to re-upload.
Setup is one line. Paste it into the theme, save, open the store. No plugin, no app install, no developer.
The price is flat. Merchants pay for how many people can watch at once, not for how much they sell. Free up to 100 concurrent viewers; paid plans start at $2 per day or $49 per month.

What a show looks like

Boring on purpose: open the player ten minutes early, show three to five
products instead of the whole catalog, keep the product card pinned while
talking about it, run 20–30 minutes, and finish with a discount code for
people who stayed.

Who this is not for

If most of a store's reach comes from TikTok or Instagram, they want that
algorithm and that audience; a widget on their own site won't manufacture
demand. This is for stores that already have traffic — from search, ads,
email, or a physical shop — and want to turn it into sales with a human on
camera.

The trade-off is honest: you give up the platform's built-in audience, and
in exchange you keep the customer, the margin, and the data.

If you want the step-by-step setup, it's here — Shopify and WooCommerce,
about 15 minutes end to end: https://durianlive.com/blog/shopify-live-selling