It works. But "just wrap your web app" hides a few things. Here's the reality.

The shape

• A single Vue.js frontend: the whole UI, the Reddit API calls, the OAuth.
• Tauri for desktop — the webview is the OS's native one, the backend is Rust.
• Capacitor for Android — desktop got Tauri, Android got Capacitor. Use the wrapper that's mature for each target instead of forcing one tool everywhere.
• Plain web for anyone who just wants a URL.

Gotcha 1: you can't cross-compile

You cannot build a Windows .msi on your Mac. Tauri leans on each platform's native toolchain:

• .msi / .exe → built on Windows
• .dmg / .app → built on macOS
• .deb / .AppImage → built on Linux

"Ship for all platforms" really means a CI matrix with one runner per OS. Plan for it early — it shapes your whole release pipeline.

Gotcha 2: WebView2 on older Windows

Tauri doesn't ship a browser engine; it uses the system webview. Windows 11 has WebView2; Windows 7–10 might not — and a missing webview means users open the app to a blank white window. Bundle the WebView2 bootstrapper in your installer so it self-installs. Tiny detail, terrible first impression if you miss it.

Gotcha 3: OAuth redirect is the fiddly part

In a browser, OAuth is easy: Reddit redirects to your callback URL, you read the code, done. In a packaged app there's no web server at that URL. So you register a custom scheme / deep link, let the OS hand the redirect back to the app, and pull the code out of the incoming URL — on desktop and Android, each with its own quirks. Easily the most time-consuming part, and the bit tutorials skip.

Gotcha 4: a default Rust release binary is chunky

A handful of Cargo.toml flags make a real dent:

[profile.release]
panic = "abort"      # drop the unwinding machinery
codegen-units = 1    # compile as one unit so the optimizer can do more
lto = true           # link-time optimization
opt-level = "s"      # optimize for size
strip = true         # strip symbols from the binary

Free size win, no code changes.

Was it worth it?

Yes. One Vue codebase, native apps on desktop and Android, plus a web version — without three projects to keep in sync. If you're a web dev eyeing desktop/mobile, Vue + Tauri + Capacitor is a very reasonable way in — just budget time for the packaging and OAuth reality, not the happy-path demo.

I do this kind of cross-platform / custom-tooling work as a freelance dev at dibodev.fr. Happy to get into the OAuth deep-linking or the CI matrix in the comments.

Originally published on DEV.

I also write in bursts. Some evenings I'll draft two or three articles at once, and I don't want them all going live the same day. So I bolted a small publishing engine onto my existing stack: drafts, a scheduled queue (a "drip"), and automatic rebuilds. Here's how the pieces fit.

The stack

• Nuxt 4, prerendered (SSG) for every public page
• Storyblok as the headless CMS — the source of truth for content
• A Nitro server (the same Nuxt app) on a small VPS under PM2 — the always-on part
• GitHub Actions for the deploy/rebuild

The whole thing rests on one realization: on an SSG site, "publish" is two actions, not one — (1) put the content in the CMS, and (2) rebuild the static site so it actually shows up. Scheduling is just doing both later, automatically.

1. Drafts: write now, decide later

The dashboard has a markdown editor. Drafts are saved server-side (Nitro's storage layer), each with a status (draft / scheduled / published) and a publish date. Nothing touches the live site yet — a draft is just a row waiting for its moment.

2. The queue and the "drip"

The fun part. A Nitro scheduled task runs every hour and asks one question: is anything due?

// nuxt.config.ts
export default defineNuxtConfig({
  nitro: {
    experimental: { tasks: true },
    scheduledTasks: {
      '5 * * * *': ['articles:process-queue'], // every hour, at :05
    },
  },
})

// server/tasks/articles/process-queue.ts
export default defineTask({
  meta: { name: 'articles:process-queue' },
  async run() {
    const due = await getDueScheduledArticles() // publishDate <= now
    if (!due.length) return { result: 'nothing due' }

    for (const article of due) {
      await publishToStoryblok(article) // markdown -> richtext -> CMS
    }
    await triggerSiteRebuild() // ONE rebuild for the whole batch
    return { result: `published ${due.length}` }
  },
})

That's the entire scheduler. No queue service, no cron box, no extra infra — just a task the Nitro server already knows how to run.

3. Markdown → CMS → rebuild

When a post is due, it's converted from markdown to Storyblok's richtext format, pushed to the CMS, and then — the non-negotiable step on a static site — the site is rebuilt. No rebuild, no article. I trigger it with a workflow_dispatch call to my deploy workflow:

async function triggerSiteRebuild() {
  await $fetch(
    'https://api.github.com/repos/<owner>/<repo>/actions/workflows/deploy.yml/dispatches',
    {
      method: 'POST',
      headers: {
        Authorization: `Bearer ${process.env.REPO_ACCESS_TOKEN}`, // needs `actions: write`
        Accept: 'application/vnd.github+json',
      },
      body: { ref: 'main' },
    },
  )
}

Three gotchas I hit

• There's still a server. The scheduled task only fires if something is actually running. It's easy to forget an SSG site has no always-on backend by default — the Nitro server under PM2 exists purely so the scheduler (and the admin) stay alive.
• One rebuild per batch, not per article. If three posts are due in the same run, publish all three then rebuild once. Otherwise you kick off three deploys back to back for nothing.
• Timezones. "9am" means nothing until you pin the timezone. Ask me how I know.

The payoff

Now I can draft on a Sunday, spread posts across the next two weeks, and close the laptop. They go live on their own, the site rebuilds itself, and I stop babysitting a "publish" button.

It powers the blog on my freelance site, dibodev.fr — building this kind of custom tooling (and business apps / SaaS) for small companies is basically my day job.

Originally published on DEV.