DEV Community: SixSet

Tabs as a layer, not a rewrite: pointers instead of copies, one live form, and persistence split between the browser and the server.

SixSet — Mon, 03 Aug 2026 19:40:01 +0000

The last few weeks in devset CE were about tidying up foundations: a refreshed landing page with a walkthrough, ESLint 10, security bumps. This commit is different — 2,133 new lines that bring editor-style request tabs to Message Dispatch — the kind every serious API client has.

It's the biggest UX change in that module since it was created, so instead of a dry changelog, here are the architectural patterns behind it — and where I deliberately compromised.

The problem

Message Dispatch was a single form — roughly 40 pieces of state: broker (Kafka/RabbitMQ), topic/exchange, headers, proto schema, payload studio, wire format. Switching to a different request meant losing unsaved edits.

Debugging a flow that needs several messages — order-created, a quick payment-failed test, back to the first one — meant juggling one shared state and a lot of patience. The solution has been known for years: tabs. Each scenario in its own tab, state surviving even a browser close.

Pattern #1: Thin tab — a pointer, not a copy

The fundamental design decision: a tab does not copy request parameters. It points at a saved SingleRequest — the single source of truth — and holds a local form snapshot:

export type DispatchTab = {
  id: string
  savedRequestRef: SavedRequestRef | null   // null = scratch tab
  formSnapshot: PerTabFields | null         // local, NEVER sent to the server
  activeHistoryRef: string | null
  title: string
  order: number
}

The alternative — a tab as a full copy of the request — would force syncing N copies on every collection edit: "verify & refetch" loops, race conditions, permanent staleness. Clients that went the copy route pay for it in exactly this way — "the tab says one thing, the saved request says another" is a well-known class of bug.

In the pointer model the only possible staleness is a dangling ref — someone deleted the request a tab points to — and we catch that lazily, at hydration time. Zero active synchronization.

The boundary between "belongs to the tab" and "shared" is drawn by the PerTabFields type — a Pick over 29 state fields. The snapshot extractor lists those fields explicitly, so any drift between the type and the extractor is stopped by the compiler, not by code review.

Pattern #2: Stash + hydrate — one live form

The key optimization: only the active tab is live. The reducer doesn't keep N copies of a forty-field state — on tab switch it stashes the current form into the outgoing tab's snapshot and pours in the incoming one:

case 'tabSwitched': {
  const target = state.tabs.find((tab) => tab.id === action.id)
  if (!target) return state
  return {
    ...applyPerTabFields(state, target.formSnapshot ?? defaultPerTabFields()),
    tabs: stashActiveTab(state),
    activeTabId: action.id,
  }
}

The biggest win here is invisible in the diff: the existing form logic doesn't know tabs exist. Effects, selectors and components work exactly as before — on "that one" state. Tabs are a layer on top of the reducer, not a rewrite of it. The whole mechanism lives in a new MessageDispatch.tabs.ts — 170 lines of pure functions, tested without rendering anything.

Edge cases are closed too: closing the active tab activates a neighbour, closing the last one leaves a fresh scratch tab, and opening a saved request from the list always creates a new tab at the front of the bar — no dedup, because every click is a separate mirror. Want to compare two variants of the same request side by side? Click twice.

Pattern #3: Persistence behind a repository seam

All persistence hides behind a single interface — load() and save(workspace). The reducer and the components see that contract and never learn where the data physically lives.

The localStorage implementation gets Storage injected, so it's tested with an in-memory map, no DOM required; a throwing or full storage degrades to "no persistence" instead of blowing up the app. Writes are debounced (400 ms) so we don't hammer the disk on every keystroke.

Pattern #4: Hybrid — composing two repositories

The most interesting piece. There are two persistence layers, with different roles:

localStorage holds the full content of all tabs — scratch tabs and edited mirrors of saved requests. This is what rescues unsaved edits across a browser reload.
backend (GET/PUT /dispatch-workspace) receives only pointers to saved tabs: id, collection, request name, title, order. The server knows what is open — never what's inside it.

A third implementation of the same interface glues them together — a classic Composite over a shared port:

async save(workspace) {
  await Promise.all([
    local.save(workspace),                      // full content — rescues edits
    api.save({ activeTabId, tabs: savedOnly }), // pointers — cross-device
  ])
}

On load, a merge happens with one iron rule: local content wins per id, while tabs known only to the server — opened on another device — are appended and hydrated fresh from their saved requests. In-flight local edits and the active tab stay untouched. When the API is down, everything degrades to plain localStorage and the user notices nothing.

That rule is the result of a painful lesson. The first iteration split things as "scratch tabs to localStorage, saved tabs to the server" — sounded logical, and lost mirror edits on reload, because an edited mirror is no longer what sits on the server. Hence the current rule: local holds everything, the server holds only the open set.

Pattern #5: Backend — workspace blob, last-write-wins

The new io.devset.ce.be.dispatchworkspace module is a full hexagon in the style of the neighbouring singlerequest: a logic-free controller, a facade, a pure domain on records, MapStruct at layer boundaries.

The endpoint treats the workspace as a singleton per instance with last-write-wins semantics — devset CE is single-user and local, so per-tab diffs or CRDTs would be engineering for show. And if it's ever needed: migrating up from a blob is easy; the other direction is much harder.

The tab list lands in SQLite as a single JSON column via a null-safe JPA converter — deliberately without a separate table and relations. Tabs are always read and written as a whole, so normalization would only buy us JOINs and migrations, with no upside.

UX details

A few decisions that define how the feature feels:

Update saves to the request's source collection — the tab remembers where it came from — and asks explicitly in a dedicated modal before overwriting.
Saving without a collection lands in an auto-created "Uncategorized", because forcing a collection name during a quick "I'll save this for later" was pure friction.
Tab colors went through several iterations, because the first version was "too neon" — the active tab ended up white and lifted by a shadow, with the broker marked by a neutral chip with a dot.

Test grid: pure tab functions and the reducer, both repositories plus the hybrid, components, and on the backend side the domain, the converter and a controller integration test. Plus 250 lines of E2E — including surviving a browser reload.

Known trade-offs — because honesty only gets cheaper after the fact

No architecture is free, so let's write down what we're paying:

The stash invariant is not enforced by the compiler: every future action that changes the active tab has to remember stashActiveTab(). Plan: a guard test enumerating actions that touch activeTabId.
A new form field has to be added to PerTabFields by hand — the compiler won't hint that it should be per-tab. Forget it → the field leaks between tabs.
The append-only merge doesn't propagate closes: a tab closed on device B can come back from device A's localStorage. For a single user — acceptable, but it's a conscious anomaly, not an oversight.
A dirty guard on tab close — deferred, because there's no reliable "dirty" signal yet. Today it's the only path to real edit loss, so it's high on the list, not "someday".

The result

For the user: no lost work, parallel scenarios without juggling, continuity across devices. Architecturally: tabs landed without rewriting the existing form — and that's the best proof that stash + hydrate was the right call.

As always — devset CE is source available, feedback welcome.

Playwright + Docker: How I Set Up E2E Gating for Devset CE (and What Bit Me)

SixSet — Mon, 27 Jul 2026 09:56:37 +0000

Before every merge to main I had this moment: "well, probably nothing broke." Unit tests green, integration tests green, I click around the UI manually — works. And still, that little voice in the back of my head: "did you check message dispatch after the last change in collectionContext? schema save from the Ace editor? SPA routing after the frontend gets bundled into the jar?"

Eventually I got tired of it. I opened a branch called ci-add-playwright-e2e-gating-main-with-bundled-FE+BE (yes, my branch names are a whole separate topic) and wrote proper E2E tests. Playwright, Docker, a gate on PRs. Here's how it looks — and where I faceplanted.

Quick context: what is Devset CE?

Devset CE is my source-available side project: a tool for working with Kafka and RabbitMQ — schema repository (JSON / protobuf), message workflows, dispatching, connection management. Architecturally it's a Spring Boot backend that serves its SPA frontend from inside a single jar, also shipped as a Docker image (ghcr.io/devset-io/devset-ce). That one-jar detail matters for this whole story: the E2E suite has to test that exact artifact, not a dev server.

What went in

Playwright in devset-ce-fe/e2e/ — two spec files for now: smoke.spec.ts (the SPA mounts, /api/workflows returns 200) and schema-repo.spec.ts (create a JSON schema, create a protobuf one, edit the body, reload, verify it persisted).
docker-compose.e2e.yml — Kafka, RabbitMQ, the backend with the frontend baked in, and a Playwright container. Healthchecks, pinned SHAs, depends_on with service_healthy. The whole package.
scripts/e2e-build.sh — builds the frontend, drops it into devset-ce-be/src/main/resources/static, runs ./gradlew bootJar. Out comes a single artifact, exactly like the one behind ghcr.io/devset-io/devset-ce:latest.
.github/workflows/e2e.yml — runs on PRs and on push to main. Cancel-in-progress for PRs (if someone pushes 10 commits in 5 minutes, I don't want 10 runs). Trace upload on failure.
Four npm scripts: e2e:build, e2e:up, e2e:down, e2e:full. Locally I run npm run e2e:full and get exactly what CI gets. No more "works on my machine."

While I was at it, I deleted the old docker-compose.yml from the repo root. It was a zombie from when the project had a different structure — it pointed at a folder that no longer existed, and the README described a workaround for the workaround. Better to have nothing than something that lies.

Why Docker instead of Playwright's `webServer`

My first thought was the simplest one: Playwright has webServer in its config — spin up the backend with Gradle, Kafka via Testcontainers, done. I talked myself out of it within about 15 minutes:

The backend doesn't start "instantly." Spring Boot has to boot and get on speaking terms with Kafka and RabbitMQ — only then is /api/* actually alive. sleep 10 in the config? No, thanks. In docker-compose I have healthchecks and condition: service_healthy, and it just… happens on its own.

backend:
  depends_on:
    kafka:
      condition: service_healthy
    rabbitmq:
      condition: service_healthy

I want local and CI to be identical. Not 95% identical, not "well, almost." One compose file, one script, two places to run it. When something breaks in CI, I run npm run e2e:full on my machine and reproduce the failure in a minute. That's a currency you pay once — and it pays you back daily.

The browser version ships with Playwright. The mcr.microsoft.com/playwright:v1.59.0-noble image comes with a Chromium already matched to @playwright/test@1.59.0. Nobody forgets npx playwright install, nobody debugs "why does it work on Janek's machine."

And I'm testing the real artifact. Not a dev Vite server with a proxy to the backend, but the jar that serves the frontend from static/. That catches regressions in CORS, in SPA routing, in resource mapping. A mock server would never see them, because it simply never exercises those paths.

The cost? The first run is slower, but with npm/Gradle caches in GitHub Actions the whole workflow fits in about 6–8 minutes. Acceptable.

What bit me (and what surprised me)

A few things ate a meaningful chunk of my time. Writing them down so I have them handy next time.

The Ace editor. JSON schemas are edited in Ace. Ace renders its own DOM, keeps a hidden textarea, page.fill() is a coin flip, keyboard.type() is slow and keymap-sensitive. I started with three "normal" approaches — none of them was stable. Only after opening devtools and poking around Ace's internals did I notice it keeps its Editor instance at containerElement.env.editor (Ace uses it itself, as a re-entry guard in ace.edit()). So I go in through page.evaluate() and call editor.setValue(value, -1):

await page.evaluate((value) => {
  const container = document.querySelector('.ace_editor');
  (container as any).env.editor.setValue(value, -1);
}, schemaBody);

Ugly? Ugly. But it works every single time. I left a // SAFETY: comment so that future me, staring at the as unknown as, doesn't rip it out with a "what even is this."

SQLite chased me off. Devset keeps its state in SQLite. Playwright runs tests within a single file in parallel by default. SQLite serializes all writes — so when three tests fire a DELETE at once, two of them get SQLITE_BUSY and everything goes red. I tried retries, more aggressive cleanup, combinations of both — and finally let go:

test.describe.configure({ mode: 'serial' });

on the schema spec file. Slower, but 100% green. Retry with backoff masks the problem; it doesn't solve it.

getByRole does substring matching. So getByRole('button', { name: 'Edit' }) blew up with a strict-mode violation: "found 2 elements." Because the sidebar had a node whose ID contained the word "edit" — my edit test had named its schema e2e_json_edit_… (brilliant, past me). Lesson: exact: true everywhere I know the full text. It should be the default; it isn't; oh well.

Cleanup after failures. E2E tests against a shared backend have this property: when something dies halfway through, garbage stays behind. So every test appends the IDs it created to a list, and in afterEach I fire a Promise.all of best-effort DELETEs (.catch(() => undefined)). The next run always starts clean.

What I got out of it

Merges to main are gated. Red E2E = it doesn't go in. No more "I trust nothing broke."
Playwright traces on failure. I download the zip from the workflow artifacts, open it, and I've got a screenshot + recording + network log. Debugging a remote failure is five clicks now, not an hour-long investigation.
I'm testing the same jar that ships to production. Frontend embedded in the backend, exactly like the GHCR image. If something works locally and breaks after a release, it's no longer the E2E suite's fault.
Locally it's one command: npm run e2e:full. A new contributor: git clone, npm run e2e:full, goes to make a coffee, comes back to a result. The barrier to entry just dropped.

What's next

Smoke + schema repo is just the start. On the list: workflows (create / edit / run), message dispatch with collectionContext (a fresh feature — the perfect moment to cement it), connection management for Kafka and RabbitMQ. Every new screen gets its own spec — that's now part of "feature done," not an optional add-on for later.

If any of these tests turns flaky, that'll be its own post. Because a flaky test nobody fixes is worse than no test at all — it teaches the team to ignore a red status, and that's a habit that's very hard to unlearn.

Devset CE is source-available — you can poke around the code, run it from a single jar or the Docker image (ghcr.io/devset-io/devset-ce), and tell me everything I did wrong. Start at devset.pl or the devset-io org on GitHub. Issues, feedback and PRs very welcome.

How I Improved Code Quality with AI and Static Analysis (SonarQube Cloud + MCP)

SixSet — Fri, 24 Jul 2026 07:45:09 +0000

The more code gets written with AI assistance, the easier it is to fall into a false sense of security. It compiles, tests pass, everything looks fine but underneath there can still be vulnerabilities, dead code, or metrics that don't actually mean anything because they're only computed halfway. So instead of stacking yet another "eyeball" AI review on top, I decided to add a hard, automated layer to my project: static code analysis that checks every PR against the same, measurable criteria.

I went with SonarQube Cloud, mainly because it has a free plan for open-source projects, and it also ships its own MCP server meaning the AI agent I work with can pull analysis results directly, without me copy-pasting reports back and forth. Below is a step-by-step account of how this rollout went in devset-ce, my local testing engine for event-driven systems on Kafka and RabbitMQ, based on three concrete commits and what real benefits it brought.

1. The analysis workflow in CI

Starting point: commit a6746d3, PR #44 adding .github/workflows/sonar.yml and sonar-project.properties.

The workflow builds the backend (Gradle, JDK 25), installs and tests the frontend (Node 22), and finally runs the official SonarSource/sonarqube-scan-action:

- name: Build backend
  working-directory: devset-ce-be
  run: ./gradlew build -x test

- name: Test frontend
  working-directory: devset-ce-fe
  run: npm run test

- name: SonarQube Scan
  uses: SonarSource/sonarqube-scan-action@713881670b6b3676cda39549040e2d88c70d582e # v8.2.0
  env:
    SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

Notice ./gradlew build -x test backend tests were skipped at this stage. That was a deliberate first step, but it also created an immediately visible gap: Sonar got coverage from the frontend (via sonar.javascript.lcov.reportPaths), but none at all from the backend.

sonar-project.properties sets sources separately for backend and frontend, excludes build/, dist/, node_modules/, and test files from the main-code analysis, and points to backend tests separately via sonar.tests.

2. Real coverage with JaCoCo

Step two was commit 91822a8, PR #50 "wire backend JaCoCo coverage into SonarQube analysis". This directly addresses the gap from step 1.

Changes to build.gradle: adding the jacoco plugin (pinned to version 0.8.14), hooking it into the test and integTest tasks via finalizedBy jacocoTestReport, and configuring the report to merge execution data from both unit and integration tests:

plugins {
    id 'java'
    id 'jacoco'
    ...
}

jacoco {
    toolVersion = "0.8.14"
}

jacocoTestReport {
    dependsOn test
    executionData fileTree(layout.buildDirectory.dir("jacoco")) { include "*.exec" }
    reports {
        xml.required = true
    }
}

In the workflow, the backend build step changes from skipping tests to running the full test + report cycle:

- name: Build backend with coverage
  working-directory: devset-ce-be
  run: ./gradlew build integTest jacocoTestReport

And sonar-project.properties gets one new line tying it all together:

sonar.coverage.jacoco.xmlReportPaths=devset-ce-be/build/reports/jacoco/test/jacocoTestReport.xml

The result: SonarQube now calculates real backend code coverage (unit + integration), not just frontend numbers. This is what finally makes the coverage metric in Sonar trustworthy before this, it was partial and could give a false sense of security.

3. UTF-8, where you least expect to need it

The third change is commit 4921e9c, PR #54 a single line in build.gradle:

tasks.withType(JavaCompile).configureEach {
    options.encoding = 'UTF-8'
    options.compilerArgs += "-parameters"
}

Without an explicit encoding setting, the Java compiler falls back to the platform's default encoding which can be inconsistent across different CI environments and can silently corrupt non-ASCII characters in sources or resources. A small fix, but exactly the kind that's easy to overlook until you start looking for it systematically instead of by accident.

What this actually gets you

After these three commits, I have a genuinely different starting point than before, when the only line of defense was a human code review:

A quality gate that blocks merges. New code that doesn't meet the thresholds (duplication, code smells, security hotspots) doesn't make it into main nobody has to police this manually in review.
Trustworthy coverage instead of a number for show. Before PR #50, the backend built with -x test, so the coverage metric in Sonar was essentially fiction. After wiring in JaCoCo (unit + integration), backend coverage reflects what's actually tested, so I can rely on that number when deciding where tests are missing.
Security hotspots and CVEs caught automatically. Static analysis plus the CVE resolution strategy in Gradle (PR #54) catch vulnerable dependencies and suspicious patterns before anyone sees them in review I'm no longer relying on a reviewer happening to remember a specific CVE.
A whole class of bugs that normally slip through review. The UTF-8 encoding fix is a good example it's not something a human typically notices while reading a diff, yet it can silently corrupt data on a different CI environment.
A shorter feedback loop thanks to MCP. The AI agent gets analysis results with full context (file, line, issue type) and proposes a fix itself I don't have to manually copy a report from a dashboard into my editor, so small fixes don't get pushed to "later."
Metrics as living documentation of the project's state. Coverage, duplication, and open issue counts in Sonar give a measurable snapshot of repo quality at any point in time useful when an outside contributor is deciding whether it's worth getting involved.

The takeaway

These three commits are a good illustration of what adding static analysis to an existing project actually looks like in practice: not a one-time "big bang," but a series of small iterations. First, a basic workflow even with tests skipped. Then, filling in real coverage, because without it the metrics are only half the picture. Finally, a small fix that the analysis (or the build itself) would sooner or later have forced anyway.

What really speeds up this loop is SonarQube's MCP server the AI agent gets direct access to analysis results and context (which file, which line, what type of issue), so going from a flagged issue to an actual code fix is faster than manually shuttling reports between a dashboard and an editor.

The developer, the AI agent, and static analysis each do a different job here: the developer decides what makes business sense, AI speeds up the actual work, and Sonar makes sure neither side introduces a regression. Wired together in CI/CD, this means the quality gate and real coverage metrics run on every PR, before anything reaches main.

This workflow is part of devset-ce a local, source-available testing engine for event-driven systems on Kafka and RabbitMQ, built by [DevSet]. If you're working with message brokers and tired of writing the same Kafka scripts over and over, it might save you some time feel free to check it out, star it, or open an issue.

A Better Way to Test Kafka and RabbitMQ Workflows

SixSet — Wed, 22 Jul 2026 15:29:03 +0000

This isn't a Kafka tutorial. It's about how I stopped writing disposable producer scripts every time I needed to test an event-driven workflow.

I keep running into the same situation. I'm testing a feature in a distributed system where the actions are loosely connected through events a user makes a payment or a purchase, and that has to start propagating: to accounting, to inventory, to whatever downstream service is waiting for it.

The problem is that on test environments, I rarely have the full chain available. Either the other services aren't deployed yet, or the functionality that would normally trigger the event just doesn't exist yet. So I need to fake that one event myself.

Most of the time this ended up being one of three things:

kafka-console-producer with a hand-typed payload
a small producer script in Python or Go, written once and never cleaned up
a throwaway Spring Boot app whose only job was to fire one event

All of these work. But after a few months, your repo (or your ~/scripts folder) turns into a graveyard of one-off producers, each slightly different, each half-remembered when you need it again six weeks later.

I got tired of that pattern enough to build Devset, a tool for testing event-driven systems without writing throwaway producers and consumers. This is a walkthrough of the three specific problems that pushed me to build it.

The examples below use Kafka, but the same workflow applies to RabbitMQ exchanges and routing keys.

Sending a single event

Sometimes I just need to fire one message a specific payload, on a specific topic, with a specific key and see what happens downstream. kafka-console-producer technically solves this problem, but in practice it still means constructing JSON by hand, remembering CLI flags, and repeating the whole process every time you want to replay the same event.

Instead of writing a producer every time, I paste the payload, pick the topic and key, and publish it. It gets saved, so the next time I need the same message I'm not reconstructing it from memory.

Replaying complete workflows

This is the part that actually mattered more than sending single messages.

Sometimes one event isn't enough I need to simulate a whole sequence. A user adds something to a cart, enters an amount, pays, and a separate service should confirm the order:

OrderCreated
     │
     ▼
InventoryReserved
     │
     ▼
PaymentAuthorized
     │
     ▼
InvoiceGenerated

That's a simplified example, but real workflows usually branch here. Inventory may fail, payment may time out, an order may need to be retried, or a compensating event may need to be emitted. Those are the scenarios that quickly turn a handful of producer scripts into something nobody wants to maintain.

Normally, testing that chain means either standing up four real services, or writing four scripts and running them in the right order with the right delays between them and hoping nothing about the payload shapes changed since the last time you touched them.

In Devset, this is one saved workflow. I lay the steps out on a canvas, each step can carry a condition, a delay, or reference state from an earlier step (so PaymentAuthorized can carry the order ID that OrderCreated generated), and the whole thing runs as a single unit that I can re-trigger any time I need it — instead of four services or four scripts, it's one saved workflow.

The same workflows also let me observe responses coming back, so I'm not only publishing events but exercising complete request/reaction chains.

Working with Protobuf

A chunk of my day-to-day work is on services that speak Protobuf, and firing Protobuf messages from a script is a different level of annoying than JSON. You need the schema on hand, you're dealing with compiled classes or manual encoding, and the moment the schema changes across environments you're debugging a wire-format mismatch instead of the thing you actually meant to test.

I keep the schemas I use versioned in one place now, and messages can be built against JSON Schema or Protobuf the same way — the encoding and validation happen automatically instead of being something I have to get right by hand every time.

Where this is going

Devset CE is source-available and self-hosted, and runs locally against your own brokers with a single Docker command. If you'd like to try it, the repository and documentation are linked below.

devset-io / devset-ce

Local-first workflow engine for testing Kafka and RabbitMQ event-driven systems. Define scenarios, send real messages, inspect results — all on your machine.

Local message lab for Kafka and RabbitMQ — no cloud, no scripts.

Devset

Testing event-driven systems is painful. You end up writing throwaway scripts to publish a few messages, integration tests are brittle and slow, multi-step scenarios need glue code nobody wants to maintain, and reproducing production payloads locally is a guessing game. Devset is a self-hosted scenario engine that compiles a declarative DSL into runs against real Kafka or RabbitMQ brokers, with a visual builder on top.

Think Postman or Cypress, but for Kafka and RabbitMQ instead of HTTP.

No cloud. Runs entirely on your machine.
No accounts. Open the UI and start.
No telemetry. Your scenarios stay local.

Source-available under FSL-1.1 — free for internal use; each release converts to Apache 2.0 on its second anniversary.

Quick start

1. Run Devset

docker run -p 8082:8082 -v devset-data:/data ghcr.io/devset-io/devset-ce:latest

Open http://localhost:8082.

Already seeded — nothing to set up…

View on GitHub

Documentation: https://docs.devset.io

A few things I'm currently working on:

deeper branching in the Flow Builder, so workflows can handle retries, timeouts, and compensating events instead of just linear chains
live topic inspection
offline workflow simulation (run the pipeline without touching a real broker)
a JSON DSL so the same workflows can run from CI, not just the UI

If you work with Kafka or RabbitMQ and have opinions, issues, or PRs, I'd genuinely like to hear them.

How are you testing event chains like this today real services, mocks, something else? Curious what other people have landed on.