DEV Community: Tony Nguyen

Building a Multi-Channel Content Syndication Pipeline with EmDash Plugins

Tony Nguyen — Mon, 25 May 2026 11:29:12 +0000

I recently built a content syndication plugin for EmDash that automatically distributes blog posts to Dev.to, LinkedIn, Medium, Hacker News, and email newsletters from a single publish action. Here's how the architecture works and what I learned about multi-platform API orchestration.

The Problem: Format Fragmentation and Timing Drift

Manual cross-posting breaks down in practice because each platform expects different formats and has different constraints:

Format fragmentation — HTML on your site, Markdown on Dev.to, rich text on LinkedIn, plain text for HN, HTML for email
Timing drift — manual workflows slip by days or weeks, defeating the purpose of coordinated launches
Metadata mismatch — canonical URLs, tags, and excerpts need to be correct per platform for SEO
No centralized tracking — you can't measure which channel drives the most traffic without a unified analytics layer

Architecture Overview

The pipeline runs entirely on Cloudflare Workers via EmDash's plugin system with four components:

Component	Purpose	Technology
Publish Hook	Trigger on post status change	EmDash plugin middleware
Format Renderer	Convert to platform-specific formats	Template engine + markdown-it
Channel Adapter	Platform-specific API client	Fetch API + OAuth tokens
Queue Manager	Retry failed syndications	D1 queue table
Analytics Tracker	Log syndication events	D1 events table

No external cron jobs or queue infrastructure needed — Workers' Queues (or KV with TTL) handles the orchestration.

Step 1: The Publish Hook

The plugin registers a middleware that fires on afterPostSave when status flips to 'published':

// emdash-plugin-syndication/hooks.js
export default {
  async afterPostSave(post, context) {
    if (post.status === 'published' && post.wasDraft) {
      await context.env.SYNDICATION_QUEUE.put(
        `syndicate:${post.slug}`,
        JSON.stringify({
          slug: post.slug,
          title: post.title,
          body: post.body,
          excerpt: post.excerpt,
          tags: post.tags,
          publishedAt: post.published_at,
          channels: ['devto', 'linkedin', 'medium', 'hn']
        }),
        { expirationTtl: 86400 }
      );
    }
    return post;
  }
};

Key design decision: using post.wasDraft prevents re-syndication on edits to already-published posts. Without this guard, every content update would re-trigger the pipeline and duplicate content across platforms.

Step 2: Format Adapter Pattern

Each platform gets its own adapter that converts the internal HTML body to the target format:

const adapters = {
  devto: (post) => ({
    body_markdown: htmlToMarkdown(post.body),
    tags: post.tags.slice(0, 4),  // Dev.to max 4 tags
    canonical_url: `https://ai-kit.net/blog/${post.slug}`,
    published: true
  }),
  linkedin: (post) => ({
    commentator: 'urn:li:person:ai-kit',
    content: {
      article: {
        title: post.title,
        description: post.excerpt,
        source: 'https://ai-kit.net',
        thumbnailUrl: `https://ai-kit.net/og/${post.slug}.png`,
        canonicalUrl: `https://ai-kit.net/blog/${post.slug}`
      }
    },
    distribution: {
      feedDistribution: 'MAIN_FEED',
      targetEntities: []
    }
  }),
  medium: (post) => ({
    title: post.title,
    contentFormat: 'markdown',
    content: htmlToMarkdown(post.body),
    tags: post.tags.slice(0, 3),  // Medium max 3 tags
    publishStatus: 'public',
    canonicalUrl: `https://ai-kit.net/blog/${post.slug}`
  })
};

Platform-specific quirks I ran into:

LinkedIn strips code blocks — their rich text API doesn't support <pre><code>. I convert code blocks to inline code spans, which is imperfect but preserves readability
Medium expects Gist embeds for code — plain code fences in Medium import create formatting issues. The adapter optionally wraps code blocks as Gist URLs
Dev.to loves code fences — standard triple-backtick fences work perfectly with syntax highlighting
Hacker News is plain text only — 2000 character limit, no markup, no images. Append the original story URL for context
LinkedIn API has rate limits — 100 posts per 24 hours, ~1 post per 14 minutes sustained

Step 3: Token Refresh Pattern

OAuth tokens expire and each platform handles expiry differently. Here's the refresh wrapper I built:

async function getValidToken(channel, context) {
  const token = await context.env.SECRETS.get(`${channel}_token`);
  const expiresAt = await context.env.SECRETS.get(`${channel}_expires_at`);

  if (token && expiresAt && Date.now() < parseInt(expiresAt)) {
    return token;
  }

  // Refresh token
  const refreshToken = await context.env.SECRETS.get(`${channel}_refresh_token`);
  const response = await refreshAccessToken(channel, refreshToken);

  await context.env.SECRETS.put(`${channel}_token`, response.access_token);
  await context.env.SECRETS.put(
    `${channel}_expires_at`,
    String(Date.now() + response.expires_in * 1000)
  );

  return response.access_token;
}

One gotcha: LinkedIn's access tokens expire every 60 days with no refresh token for the Community Management API. You need the Marketing Developer Platform OAuth 2.0 flow which provides refresh tokens. Dev.to and Medium tokens are long-lived (not expiring), so their expires_at is set far in the future as a simple sentinel.

Step 4: Error Tracking with D1

Each syndication attempt is logged to a D1 events table for debugging and observability:

CREATE TABLE syndication_events (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  post_slug TEXT NOT NULL,
  channel TEXT NOT NULL,
  status TEXT NOT NULL,  -- 'success', 'failed', 'retrying'
  url TEXT,
  error TEXT,
  attempted_at INTEGER NOT NULL,
  retry_count INTEGER DEFAULT 0
);
CREATE INDEX idx_syndication_post ON syndication_events(post_slug);

The pipeline retries failed channels up to 3 times with exponential backoff (30s, 2min, 10min). After exhausting retries, the event is marked as permanently failed and a notification is dispatched via Telegram or email.

Design Decisions Worth Calling Out

Staggered syndication timing

I intentionally sequence channels to optimize indexing and avoid spamming overlapping audiences:

Dev.to and Medium first — they index quickly and cache syndicated copies
LinkedIn next — slower to appear in feeds, so publishing earlier doesn't help
Email digests last — avoids sending notifications to subscribers who may have already seen the post on another platform

Rate limiting per channel

Each platform has different API rate limits. Dev.to allows 5 API calls per minute, LinkedIn has daily post limits. The plugin maintains a per-channel rate limiter using D1 counters:

async function checkRateLimit(channel, context) {
  const key = `ratelimit:${channel}:${Math.floor(Date.now() / 60000)}`;
  const count = await context.env.SYNDICATION_QUEUE.get(key) || 0;
  const limit = RATE_LIMITS[channel];  // { max: 5, window: 60000 }
  if (count >= limit.max) throw new RateLimitError(channel);
  await context.env.SYNDICATION_QUEUE.put(key, count + 1, { expirationTtl: 120 });
}

Canonical URL enforcement

Every syndicated copy includes a canonical_url pointing back to the original. This is critical for SEO — without it, syndicated copies can outrank the original for search queries. Dev.to and Medium support canonical URLs natively. LinkedIn's article API requires setting canonicalUrl in the payload.

Dry-run mode

Before hitting live APIs, the plugin includes a dry-run mode that returns the formatted payload without posting. You can preview exactly what each platform will receive in EmDash's admin UI:

if (options.dryRun) {
  return { channel, payload: adapter(post) };
}

What I'd Do Differently Next Time

Use a message queue from day one — I started with simple Promise.all across all channels. First LinkedIn API timeout blocked Dev.to and Medium. Sequential processing with a proper queue (Workers Queues) fixed this.
Platform-specific test fixtures — each platform has subtle JSON schema differences that surface as 400s at runtime. Mocking the actual API responses in tests would have caught these earlier.
Graceful degradation per channel — one platform being down shouldn't stop syndication to others. Each channel should be fully isolated in its own Worker invocation.

Metrics to Track

Syndication velocity — time from initial publish to full syndication across all channels (target: under 10 minutes)
Channel performance — which syndication channel drives the most referrer traffic back
Failure rate — percentage of attempts requiring retries. High failure rates indicate token issues or API changes
SEO impact — monitor whether syndicated copies outrank your canonical page. If they do, strengthen canonical tags or delay syndication by 24 hours

Building a content syndication plugin this way turns a single-platform CMS into a multi-channel distribution engine. Each published post automatically reaches Dev.to's developer audience, LinkedIn's professional network, Medium's general readership, Hacker News's tech community, and email subscribers — with zero manual effort after the initial publish click.

How We Built a Plugin Marketplace That Sells Itself: Embed Sales Architecture in EmDash

Tony Nguyen — Sat, 23 May 2026 05:03:55 +0000

Every integration is a storefront. When a third-party platform embeds an EmDash plugin, their entire user base gains a one-click path to discover us — turning each integration partner into an always-on sales channel with zero marginal cost. Here's how we built the architecture that makes this work, and the tradeoffs we made along the way.

The Architecture at a Glance

The embed sales channel rests on three systems: the Plugin API (what plugin authors build against), the Embed Registry (how we map plugins to third-party surfaces), and the Discovery Layer (the user-facing badge that drives conversion). Each is independently versioned, and we treat backward compatibility as a first-class concern.

Plugin API: The Contract

Every plugin starts as a manifest file that declares its identity and capabilities. We chose a declarative manifest over a purely programmatic API because it lets the Embed Registry reason about compatibility at install time rather than runtime.

// plugin-manifest.json
{
  "apiVersion": "v2",
  "id": "emDash-ai-form-automation",
  "name": "AI Form Automation",
  "version": "2.1.0",
  "targetPlatform": "gravity-forms",
  "minHostVersion": "2.5.0",
  "capabilities": [
    "embed:toolbar-button",
    "embed:admin-panel",
    "webhook:form-submit",
    "webhook:ai-response"
  ],
  "permissions": [
    "read:form-schemas",
    "write:form-entries",
    "read:user-context"
  ],
  "runtime": {
    "sandbox": "shadow-dom",
    "maxPayloadBytes": 524288
  }
}

Why Declarative?

We started with a purely imperative API — registerPlugin({...}) — and quickly hit versioning nightmares. Plugin authors would call APIs that didn't exist yet in older hosts, or rely on side effects we'd removed. By moving to a manifest-first model, the Embed Registry can:

Reject incompatible plugins pre-install: If minHostVersion exceeds the host's current version, the user gets a clear message instead of a runtime crash.
Selectively enable capabilities: If a host only supports embed:toolbar-button but the plugin requests embed:admin-panel, the registry grants the subset that works.
Audit security boundaries: permissions are declared upfront and checked against the host's security policy.

Tradeoff: The manifest adds friction for simple plugins. A plugin that just needs a single toolbar button still has to declare capabilities, permissions, and runtime. We experimented with sensible defaults (if you omit capabilities, we assume embed:toolbar-button) but found that explicit declarations caught too many misconfigurations to drop them.

Embed Registry: The Mapping Layer

When a user installs a plugin targeting Gravity Forms, the Embed Registry generates an embed manifest — a JSON document that tells the host exactly how to surface the plugin.

{
  "embedManifest": {
    "plugin": "emDash-ai-form-automation",
    "target": "gravity-forms",
    "entryPoint": "https://em.dash/embed/gf-automation.js",
    "integrity": "sha384-abc123",
    "mountStrategy": "shadow-dom",
    "styles": {
      "injection": "scoped",
      "theme": "inherit"
    },
    "lifecycle": {
      "onMount": "load",
      "onUnmount": "destroy",
      "idleTimeoutMs": 300000
    },
    "discoveryBadge": {
      "position": "toolbar",
      "variant": "minimal",
      "label": "Automated by EmDash"
    }
  }
}

The integrity hash is non-negotiable — every embed script is subresource-integrity-checked. We learned this the hard way after an early prototype didn't hash its embeds and a compromised CDN could have injected malicious badges. Shadow DOM isolation (mountStrategy: shadow-dom) ensures plugin styles can't leak into or out of the host page, which is critical when you're embedding into production admin panels.

Version Negotiation

This is where it gets tricky. The host (say, Gravity Forms v3.0) might support a different set of embed features than the plugin expects. We handle this with a version negotiation handshake:

// Simplified negotiation flow
async function negotiateEmbed(plugin: Plugin, host: HostContext): Promise<EmbedManifest> {
  const hostCapabilities = await host.getCapabilities();
  // Intersect plugin capabilities with host capabilities
  const supported = plugin.capabilities.filter(c => hostCapabilities.includes(c));

  if (supported.length === 0) {
    // Graceful degradation — show a fallback link
    return createFallbackManifest(plugin, host);
  }

  // Pick the richest supported capability
  const bestCapability = prioritizeByRichness(supported);
  return generateManifest(plugin, bestCapability);
}

If no capabilities are supported, we fall back to a simple link embed — the plugin still shows up, just as a text link instead of a rich interactive panel. This graceful degradation over hard failure policy has been our most important reliability decision.

Security Model

Third-party embeds are a security minefield. Here's our threat model and how we address each vector:

Threat	Mitigation
XSS via plugin script	Subresource integrity + Content Security Policy nonce
Style leakage	Shadow DOM isolation (scoped styles)
Data exfiltration	Permission system enforced at registry level, not just plugin side
Clickjacking	frame-ancestors CSP directive + X-Frame-Options: SAMEORIGIN on all non-embed endpoints
Supply chain (compromised plugin update)	Signed manifests + version pinning in host config

Tradeoff: The permission system is coarse. A plugin that requests read:form-schemas gets access to all form schemas, not just the ones it needs. We considered a more granular model (per-field scoping, regex-based selectors) but it added enormous complexity to both the registry and the plugin API. For v1, coarse permissions with manual review for sensitive plugins was the right call.

The Embed SDK

Partners integrate our embeds via a tiny SDK (~3KB gzipped). The SDK handles authentication, lifecycle, and analytics so plugin authors don't have to.

// Partner integration — one import
import('https://em.dash/sdk/embed.js').then(({ createEmbed }) => {
  createEmbed({
    target: 'my-platform',
    plugins: ['emDash-automation', 'emDash-content-gen'],
    auth: {
      flow: 'oauth-device',
      // No tokens stored in localStorage — we use session cookies via iframe
    },
    placement: 'admin-toolbar'
  });
});

Key decision: no iframes for the primary embed. We prototyped with iframes (easy isolation, trivial to implement) but they break keyboard navigation, create focus-trapping issues, and make responsive layouts painful. Shadow DOM with scoped styles gives us the same isolation without the UX debt.

Lessons Learned

1. Version everything, and version it explicitly. We shipped apiVersion: v1 without a minHostVersion field. Within two releases, plugin authors were calling methods that didn't exist on older hosts, and users got cryptic errors. Adding explicit version constraints felt bureaucratic but eliminated an entire class of support tickets.

2. Graceful degradation is a feature, not a fallback. Early on, if a host didn't support a plugin's required capability, we'd refuse to install. This meant users on slightly older versions of a platform couldn't use any EmDash plugins at all. The fallback-to-link behavior — while less rich — means zero users get a hard not compatible message.

3. Shadow DOM is not free. Each shadow root adds memory overhead, and deeply nested shadow trees (plugin inside host panel inside admin dashboard) can impact paint performance. We cap nesting at one level and recommend hosts mount embeds at the document root rather than inside existing shadow trees.

4. Attribution is harder than it looks. The ref=embed parameter is straightforward, but cross-origin attribution (user sees badge on Platform A, clicks, then signs up via Platform B's embed later) requires either first-party cookies (privacy-hostile) or probabilistic matching (noisy). We settled on anonymous impression IDs stored in session storage, which means we lose attribution on browser restarts. It's a deliberate tradeoff for privacy.

What's Next

We're working on hot-reloadable plugins (replace a plugin's runtime without requiring re-installation) and a sandboxed WebAssembly runtime for plugins that need CPU-intensive operations without blocking the host thread. The manifest format will get a runtime.wasm field alongside the existing runtime.sandbox options.

If you're building a plugin marketplace, the architecture described above — declarative manifests, capability intersection, graceful degradation, and a permission-based security model — has held up well across 12 integration partners. Start with the top 10 platforms your users already use, build deep integrations with graceful fallbacks, and treat your Plugin API as the product it is.

Startup tools: very amazing complicated system but by prompting - Firebase Studio, Claude code

Tony Nguyen — Thu, 03 Jul 2025 13:40:32 +0000

This post is my submission for DEV Education Track: Build Apps with Google AI Studio.

Startup Ascent - AI-Powered Startup Guidance Platform

What I Built
I built Startup Ascent, a comprehensive AI-driven platform that guides early-stage startup founders through the critical phases of building a business, from idea validation to launch and growth. The platform combines gamification, AI-powered tools, and structured learning to create a complete ecosystem for entrepreneurs.

Key AI Prompts Used:

"Analyze this startup idea and provide a SWOT analysis, potential risks, and validation steps"
"Generate a comprehensive pitch deck outline for this startup concept"
"Create customer personas based on this target audience description"
"Process this knowledge resource and generate summary, mind map, and key insights"
"Moderate this content for safety and appropriateness in a professional startup community"

Core Features Utilized:

Multi-format AI processing (documents, websites, videos, audio)
AI knowledge base with intelligent search
Gamified progress tracking with XP, levels, and quests
Community-driven resource sharing with AI moderation
Template marketplace for startup idea generation

Demo
Live Platform: https://startupascent.net/
Test Credentials:

Email: test@startupascent.net
Password: Test123!@#

Key Screenshots:
🎮 Gamified Dashboard

🚀 Template Marketplace

🧠 AI-Powered Tools Suite

📚 Enhanced Knowledge Base

📱 Responsive Design

And continue building...

My Experience
Key Takeaways
AI Integration Complexity: Building a production-ready AI system taught me that the real challenge isn't calling AI APIs—it's creating robust, secure, and user-friendly experiences around them. I implemented comprehensive content moderation, input validation, and error handling that most AI demos skip.
Gamification Drives Engagement: The XP/quest system wasn't just a gimmick—it fundamentally changed how users interact with the platform. By breaking down the overwhelming startup journey into achievable quests, users stay motivated and make consistent progress.
Community + AI = Powerful Synergy: The combination of AI-generated insights and community-shared resources created a knowledge base far more valuable than either component alone. Users contribute real-world examples while AI provides structured analysis.
What Was Surprising
AI Content Moderation Is Essential: I initially underestimated the need for content safety. Implementing AI-powered moderation with confidence scoring and detailed feedback became crucial for maintaining platform quality and user trust.
Multi-Format Processing Complexity: Supporting documents, websites, videos, and audio required different extraction strategies, but the unified AI processing pipeline made diverse content equally searchable and useful.
Users Want Structure, Not Just Tools: Rather than building individual AI tools, the integrated approach with guided stages, progress tracking, and contextual assistance proved much more valuable for actual startup success.
Real-World Impact: Seeing users actually validate ideas, build MVPs, and launch products using the platform's guidance system validated that AI can genuinely accelerate entrepreneurship when properly structured.
Technical Learnings

Progressive Enhancement: Building core functionality that works without AI, then enhancing with intelligent features, created a more reliable user experience

The platform demonstrates that AI's true power in business applications comes not from replacing human judgment, but from augmenting human capabilities with intelligent automation, community insights, and structured guidance.