DEV Community: odeds

How I Built FeedLog: Three Repos, One Product

odeds — Wed, 06 May 2026 05:27:55 +0000

FeedLog turns GitHub issues into publish-ready changelog entries without leaving your repo. You drop @feedlog publish in an issue comment, an AI draft appears for review, you approve it, and it shows up in your public changelog. Simple concept — but shipping it involved a handful of deliberate architecture decisions I want to write down while they're fresh.

Three repos, one product

The codebase lives across three repos:

feedlog-api (private) — the Node backend: webhooks, AI processing, the public API your customers call.
feedlog-app (private) — the web dashboard: OAuth, settings, changelog management.
feedlog-toolkit (public, MIT) — the embeddable SDK that customers drop into their own site to render the changelog widget.

Splitting into three was a deliberate choice. The toolkit is the only piece customers integrate directly, so it makes sense for it to be public, independently versioned (we use Changesets), and separately releasable without touching internal code. The API and app ship independently too — a frontend deploy doesn't force an API restart, and vice versa.

The toolkit is a Stencil-based monorepo that outputs true web components plus auto-generated React and Vue wrappers. One component source, three framework targets.

The API stack

The API is Node with Fastify as the HTTP framework. Fastify's plugin system and built-in schema validation are a good fit for a small team: we use fastify-type-provider-zod so every route is typed end-to-end from the Zod schema to the handler — no separate OpenAPI spec to keep in sync.

For the database: Drizzle ORM on top of Neon Postgres. Neon gives us a serverless Postgres database with branching, which is useful for previewing migrations. Drizzle keeps the schema as TypeScript and generates SQL migrations via Drizzle Kit. We run migrations as a separate tsx scripts/migrate.ts step, not at startup.

Beyond the request/response path:

BullMQ + Redis handles async work — GitHub webhook events get queued immediately and processed by a separate worker, so the webhook endpoint always returns fast. The AI draft generation also runs through the queue.
Croner runs scheduled tasks in-process: a webhook recovery job that redelivers failed GitHub hook payloads every 15 minutes, plus Sentry cron monitor heartbeats for all three processes (API, events worker, external worker).
opossum wraps the Postgres pool as a circuit breaker so a DB hiccup degrades gracefully instead of cascading into timeouts across all requests.
Per-API-key rate limiting is stored in Redis via @fastify/rate-limit, so limits survive restarts and work across multiple instances.

The app stack

The dashboard is TanStack Start (React SSR) with TanStack Router and TanStack Query for data fetching. UI is Tailwind CSS v4 with Radix UI primitives following the shadcn pattern. It deploys to Cloudflare Workers via Wrangler — edge-deployed SSR with no cold start tax.

DB design decisions

This is the part I spent the most time thinking through, and all three decisions have held up well.

UUIDv7 as the primary key

Every table uses UUIDv7 as its primary key, generated by a Postgres extension (uuidv7() as the column default). UUIDv7 is time-ordered and monotonically increasing, which means:

New rows always insert at the end of the B-tree index — no page splits, no fragmentation.
The UUID itself encodes the creation timestamp, so we don't need a separate created_at column on every table.

The one real downside: the Neon console and Drizzle Studio just show the UUID as a UUID. They don't decode it into a human-readable timestamp. It's a small operational annoyance — when you're scanning rows manually you can't immediately see when a record was created. We handle this by having a extractCreatedAtFromUuid7 SQL helper we call when we need the timestamp in a query.

Prefixed public IDs

Internal primary keys are UUIDs and never leave the system. Every table that gets exposed through the API also has a public_id column: a short, URL-safe string with a meaningful prefix.

usr_a3b7kx9m2p1z   ← user
ins_q8tnrfw4j6yd   ← installation
rep_c2mh5vp0xk3a   ← repository
iss_e9rz1db7yt4n   ← issue
pk_lw6gc8nu0fqj    ← API key

The IDs are prefix_ + 12 characters of base36 nanoid (customAlphabet('0123456789abcdefghijklmnopqrstuvwxyz', 12)). The prefix serves as an immediate type hint when you see an ID in a log, a support ticket, or a URL — you know instantly what kind of entity you're dealing with. Stripe popularized this pattern for good reason.

Soft deletes on every table

All tables have a deleted_at timestamp column, and every delete — no matter how trivial — goes through a soft delete. Even rows that could safely be nuked immediately get deleted_at set instead of being removed.

The pros:

Accidental recovery. When something goes wrong in production and a record gets deleted it shouldn't have, you can restore it with an UPDATE. No backup restore, no data archaeology.
Audit trail. You can always see what existed and when it was removed.
Undo flows are free. Upvotes are a good example: when a user un-upvotes something, we set deleted_at. When they re-upvote, we set deleted_at = null. The code for "toggle" is trivial — no insert/delete cycle, just a field flip.
Safer debugging. In production you can query soft-deleted rows alongside live ones to understand what happened, without the risk of it being too late.

The obvious tradeoff is that tables accumulate soft-deleted rows over time. The plan for that: a per-table cleanup cron that runs periodically and hard-deletes rows where deleted_at is older than a configurable threshold. We already have croner running in-process and the infrastructure for scheduled work, so this is a straightforward addition — each table can configure its own retention window before a permanent delete runs.

What I'd do differently

Honestly, not much yet. The main thing I'd reconsider is whether croner running in-process in the API server is the right home for cleanup jobs long-term, or whether they should live in a separate scheduled job process. In-process is simpler to start with, but it means every API instance races to run the same cron, which requires a distributed lock. For now the jobs are idempotent enough that duplicate runs are harmless, but it's something to revisit as the system grows.

Hello, FeedLog

odeds — Sun, 26 Apr 2026 07:45:50 +0000

This is our hello world post: a short answer to why FeedLog exists and who gets the most from it. If our homepage line resonates (“from issue chaos to changelogs users love”), this is the story behind it. For a full walkthrough from a messy GitHub issue to a changelog entry, open See the transformation in action on our homepage.

Why we built it

Most teams don’t fail at shipping. They fail at closing the loop: turning what actually merged into something customers and users can find, without another evening of manual release notes or copying tickets into a second system.

We kept seeing the same pattern: engineering lives in GitHub issues and PRs, while “public updates” live in a changelog tool, doc, or CMS someone has to babysit. That seam creates duplicate work, stale pages, and the same “what changed?” questions in email and support.

FeedLog is our attempt to keep intake, feedback, and publish where the work already happens in the repo, so user-facing comms isn’t the task that always slips. Rough work stays in issues; when you’re ready, you ship the words with @feedlog publish (Full command list). Nothing user-facing goes live until you approve it, so raw technical titles don’t have to hit end users by accident.

Who it’s best for

FeedLog is aimed at small product teams (about 2 to 15 people) who ship on GitHub and want feedback and a public changelog without maintaining a separate marketer-first CMS or retyping work into Notion or Confluence.

You’re a great fit if:

Developers own the loop: you’d rather publish from an issue than log into another dashboard to “compose” an update.
You want less context switching: plan and ship in GitHub, not in a second tool that goes out of sync with reality.
You care about trust and clarity: users get clear release notes in one place, with fewer confused pings and a steadier sense that the product is moving.

We’re GitHub-native today (OAuth, issues, workflow). If your team doesn’t live in GitHub, we’re probably not the right tool yet, and we’d rather say that upfront than waste your time.

Less context switching, more shipping

Our homepage puts it plainly: the same “what changed?” questions and copy-paste into a second tool drain time you wanted for shipping. FeedLog is built around less context switching, more shipping:

No extra CMS to manage for every release. Drafts tie back to the issue you already have open.
Stay in GitHub for the loop that matters: when the draft looks right, @feedlog publish (Full command list), not another tab to hunt down.
Setup in under five minutes is the bar we hold ourselves to, because a tool you don’t adopt doesn’t help anyone.

That’s the same wedge we care about in positioning: feedback and changelog in one product for small teams, with GitHub as the source of truth, so you’re not fighting adoption from engineers who hate “one more app.”

User updates and feedback, not two separate chores

User updates shouldn’t be a parallel track that only happens when someone remembers. When issues turn into draft posts you review, the changelog becomes a natural extension of how you already ship, not a weekend cleanup task.

Feedback that stays tied to issues keeps signal close to where you fix things. Users get a real changelog they can rely on; your team spends less energy re-explaining releases in scattered threads.

We’re biased toward human-in-the-loop: automation helps with drafting and tone, but you decide when something is ready for users. That’s how we square “move fast” with “don’t embarrass us with a cryptic issue title on the marketing site.”

If this sounds like your team, we’d love you to try FeedLog: free to start, same story you’ll see on the homepage. When you’re ready, we’re here for the harsh feedback that makes the product better, and you can see how we use FeedLog ourselves in Do what you preach on that page. For setup, pricing, and how drafts compare to public posts, open Frequently asked questions.

Enhancing Vue Development with the Render Paint Flashing Plugin

odeds — Thu, 22 Jun 2023 17:38:32 +0000

It’s important to note that the Render Paint Flashing Plugin is designed to work exclusively in Vue development mode.

As Vue developers, optimizing performance and minimizing unnecessary re-renders is crucial to building high-quality applications. In this article, we’ll explore the Render Paint Flashing Plugin, a powerful tool that enhances component development in Vue 3 applications. Inspired by the Chrome DevTools Rendering paint flashing panel, this plugin provides a visual indicator for re-rendered components, enabling developers to identify potential performance bottlenecks and optimize their Vue applications.

Visual Indicator: Identifying Areas for Optimization

The key feature of the Render Paint Flashing Plugin is its visual indicator that highlights re-rendered components on the screen. This feature provides developers with an intuitive way to identify areas that require optimization in their Vue applications.

By enabling the Render Paint Flashing Plugin, you can observe which components are being re-rendered during different interactions or state changes. The plugin applies a flashing effect to these components, making them easily distinguishable.

To get started with the Render Paint Flashing Plugin, visit the GitHub repository.