DEV Community: Akshay Nikhare

IMOS IX : hardware Häfele Espagnolette Lock

Akshay Nikhare — Fri, 24 Jul 2026 08:04:14 +0000

Adding branded hardware to a furniture model is where parametric design gets real. In this walkthrough we take a Häfele Espagnolette lock (nickel, article P-01503387) and set it up in IMOS IX as a rotating-door lock connector — configuring the constructive connector characteristics, understanding the part numbering, and generating the export file that drives the CNC.

The result: drop the lock into any cabinet or wardrobe door and IMOS IX automatically places the cylinder, the rod guides, and every strike position the workshop needs.

Download the ready-made connector

Import Lock_ESP_v1.zip straight into IMOS IX and start configuring — no setup required.

Download Lock_ESP_v1.zip

What is an Espagnolette lock?

An Espagnolette lock is a multi-point locking mechanism. A single cylinder drives a vertical rod (the espagnolette) up and down, engaging the carcase at the top and bottom of a tall door. Unlike a simple cam lock, it secures the door along its full height, which is why it is common on wardrobes, filing towers, and workshop cabinets.

The physical fitting: Häfele Espagnolette lock, nickel (P-01503387), with removable-core cylinder and keys.

The Häfele unit we are modelling is the nickel-finish variant, article P-01503387, driven by a removable-core Symo cylinder. From a manufacturing point of view the lock is not one part but a small assembly:

The lock case with the cylinder, mortised into the door.
The espagnolette rod running the height of the door.
Rod guides holding the rod in line.
Lock plates / strike receivers on the top and bottom shelves.

Every one of those elements implies holes and pockets that have to be cut accurately — the perfect job for IMOS IX.

The same lock modelled in IMOS IX: the connector places the cylinder, the full-height rod, and the hooks and guides automatically.

Importing the connector into IMOS IX

If you just want to use the lock, grab the Lock_ESP_v1.zip download above — it contains the pre-built connector, ready to import through the iX Organizer. You do not need to model anything from scratch.

Download Lock_ESP_v1.zip to a temporary folder.
Open the iX Organizer and go to Integration Center › Import.
Click Open Import Medium and select the unzipped import file.
In the tree, expand Import medium › Hardware and Machining › Connector. You will see the Espagnolette lock elements:

HAF_LOCK_ESP_Case_22464618 — the lock case
HAF_LOCK_ESP_Guide — rod guide
HAF_LOCK_ESP_Hook_Top / HAF_LOCK_ESP_Hook_Bot — top and bottom hooks
HAF_LOCK_ESP_LockingBolt — the locking bolt
HAF_LOCK_ESP_Rod — the espagnolette rod

Tick the connectors you want (or the whole Connector folder) and click Import.

iX Organizer › Integration Center › Import — the HAF_LOCK_ESP connector elements from Lock_ESP_v1.zip, ready to import.

Items shown in green are new to your library; an item in orange (like the locking bolt above) already exists and will be updated. After importing, open the connector once and check the editable characteristics (backset, bolt depth, rod offsets) against your own hardware.

Once imported, the Espagnolette lock appears in your connector list under Element Manager › Connections › Connector, ready to attach to a rotating-door article. The rest of this article explains how the connector is built — useful if you want to tweak it, rebuild it for another fitting, or understand what the import gives you.

Constructive connector characteristics

In IMOS IX a lock is a connector, and its behaviour is driven by the constructive connector characteristics. You reach them here:

Ribbon: Main data › Main data › Element Manager › Connections › Connector

The constructive connector characteristics describe features of the connector — for example, where it sits in the article and how its machining is derived. For rotating doors, IMOS IX distinguishes between Lock, Hinges, Mounting plates, and Buffers and Openers. For the Espagnolette lock we are concerned with the Lock characteristics below.

Element characteristics (LS_TYP)

The connector type is defined in the LS_TYP (Locking system type) characteristic. These sub-elements build up the lock:

LFRONT — Lock cylinder, key plug, turning handle (the front machining)
LPLATE — Lock plate, stop bracket
LRODHOLDER — Rod guide
LPIN — Positioning pin
LOCK — Lock case
LACT / LACT_L / LACT_R — Door latch (both / left / right)
ROD — Espagnolette rod

Order quantity of rod guides controls how many guides/mountings are ordered for the espagnolette rods, written to the IDBPURCH table. Use Order quantity only to set it manually, or Real quantity times order quantity to derive it from the linear division. Note: the Division rod characteristic does not write the real amount into IDBPURCH — use Order quantity of rod guides instead.

Editable dimensional characteristics

These are the numbers you tune to match the Häfele fitting drawing for P-01503387:

LS_X — Locking latch reveal: how far the lock latch is revealed in the carcass.
LS_LOCK_ROD_SUB — Espagnolette reduction middle: how the rod is shortened at the centre (lock section); omit for locks without rods.
LS_LACT_ROD_SUB — Espagnolette reduction door latch: shortening of the rod at the lock latch.
LS_BOLD_DEP — Bolt depth: the bolt depth.
LS_BOLD_SIZE — Backset: distance between the insertion point of the lock (usually its middle) and the edge.
LS_BOLD_DIST — Distance bolt/door back: door back-panel distance to the bolt.
LS_ROD_DIST — Offset espagnolette back: how far the espagnolette is shifted into the carcass (always set this; omit only for locks without rods).
LS_PLATE_DEP — Depth lock plate: maximum depth the bolt travels into the lock plate (optional).
LS_PLATE_SIZE — Overlap lock plate: how far the lock plate protrudes from the carcass.
LS_PIN_DIST — Distance door/pin: door back-panel distance to the positioning-pin centre.
LS_ROD_CENTER_DIST — Offset to hinge side: moves the espagnolette (and its hooks) toward the hinge side.

Rod positioning and geometry

Division rod (LS_LINDIV) — a Linear Division descriptor that positions the espagnolette along the door.
Espagnolette side (LS_ROD_SIDES) — where the rod runs relative to the lock pocket: 0 both sides, 1 just top, 2 just bottom, 3 only left, 4 only right, 5 through the lock pocket.
Locksystem DWG (SECTION_DWG) — a DWG holding the rod's cross-section geometry. It may contain only one polyline, and the file must live in the <Library>\ConnDWG directory (the .dwg extension is optional in the field).

Part numbers for rotating doors

The part numbers of the Espagnolette lock are relevant to the constructive connector characteristics — they tell IMOS IX (and you) which panel each piece of machining belongs to. The numbering mirrors depending on whether the door is hinged left or right.

Diagram omitted in this syndicated copy — see the original article for the illustration.

Left door

Diagram omitted in this syndicated copy — see the original article for the illustration.

Right door

Left door

0 — Front machining
2 — Top shelf
3 — Bottom shelf
6 — Front machining top
7 — Front machining bottom

Right door

0 — Front machining
2 — Bottom shelf
3 — Top shelf
6 — Front machining bottom
7 — Front machining top

Notice the mirror: on the left door part 2 is the top shelf, while on the right door part 2 is the bottom shelf. Getting the handing right is what keeps the strike machining on the correct panel.

Generating the export file

Once a variant is configured, IMOS IX evaluates the article and produces the production data. The export file typically contains three things:

Machine data — DXF or MPR/MPR2 files carrying every bore and pocket for the CNC router, including the cylinder, rod guides, and strikes.
Part list / BOM — the panel parts plus the Häfele Espagnolette lock (P-01503387) as a purchased fitting, with rod-guide quantities from IDBPURCH.
Label and assembly data — so cut parts arrive pre-marked for the fitter.

A typical export run looks like this:

Configured door + lock → IMOS IX article → CNC files (DXF/MPR) + BOM → Production

Open the generated MPR in your machine's viewer and you should see the cylinder bore on the front, the rod guides down the door, and the strike positions on the top and bottom shelves — exactly where the connector characteristics placed them.

Verifying the output

Before sending anything to the machine, sanity-check the export:

Backset (LS_BOLD_SIZE) and bolt depth (LS_BOLD_DEP) match the Häfele drawing for P-01503387.
Rod guides (LRODHOLDER) line up along the espagnolette and the quantity in the BOM is correct.
Strike machining lands on the right panel for the door's handing (check the part numbers above).
The BOM lists the correct article number and nickel finish.

Catching a wrong backset in the viewer costs seconds; catching it after a batch of doors is cut costs a day.

Talk to us

We build IMOS IX hardware libraries and connector setups for furniture manufacturers across Europe. If you need help configuring Häfele fittings or automating your CNC export, get in touch.

Originally published at cadnative.com.

FireVision TV: Native IPTV Streaming for Fire TV

Akshay Nikhare — Fri, 24 Jul 2026 07:49:07 +0000

FireVision TV is an IPTV streaming solution designed for Fire TV devices and Android-based set-top boxes. It delivers live channels, on-demand content, and catch-up TV through a clean, native interface — without the sluggishness that plagues most generic IPTV players.

Live portal · Client app · Server · Releases / APK

What is FireVision TV?

FireVision TV is a purpose-built IPTV client developed by Cadnative. Unlike web-based or cross-compiled players, it's written natively for Fire OS — which means smoother playback, faster channel switching, and proper integration with Alexa voice control.

Key capabilities:

Live TV — thousands of channels across sports, news, entertainment, and regional content
VOD library — movies and series available on-demand with resumable playback
Catch-up TV — watch programmes you missed, up to 7 days back
EPG (Electronic Programme Guide) — full 7-day grid with programme details
Multi-screen — stream on up to 4 devices simultaneously on a single subscription

Why native matters for Fire TV

Most IPTV apps ship a single React Native or Flutter bundle and call it done. The result is frame drops during fast channel zaps, input lag on the d-pad, and memory pressure that causes the Fire TV to throttle after 20 minutes.

FireVision TV is built in Kotlin against the Fire TV SDK directly:

ExoPlayer handles HLS/DASH/RTMP with hardware-accelerated decoding
Leanback library powers the d-pad-first UI navigation
Alexa integration lets users say "tune to Sky Sports" or "play Succession" without touching the remote

The result: channel changes in under 1 second, and stable 4K HDR playback on Fire TV Stick 4K Max.

Setting up FireVision TV

Getting started takes under two minutes:

Install — download the latest APK from the FireVision TV releases page and sideload it via ADB, or search "FireVision TV" on the Amazon Appstore.
Activate — open the app, note your device code, and enter it at tv.cadnative.com with your subscription credentials.
Load your playlist — paste your M3U URL or Xtream Codes API details in Settings → Playlist.
Done — channels populate automatically. The EPG syncs in the background.

# Sideload via ADB (developer mode must be enabled on the Fire TV)
adb connect <fire-tv-ip>:5555
adb install firevision-tv.apk

EPG and channel management

The built-in EPG pulls data from XMLTV sources. You can configure your own source or use the default one bundled with your subscription:

Settings → EPG Source → paste your XMLTV URL
EPG refreshes every 12 hours automatically
Map channels to EPG entries manually if the auto-match doesn't align

The channel list supports grouping by category (Sports, Movies, News), and you can create a Favourites row that appears at the top of the home screen for one-click access.

Parental controls

FireVision TV supports PIN-based content locking:

Lock individual channels or entire categories
Set a PIN in Settings → Parental Controls
The PIN is required before any locked content plays

This is stored locally on the device — no account-level parental data is sent to our servers.

Troubleshooting common issues

Issue	Fix
Buffering on live TV	Switch stream quality to Auto or reduce to 720p in Settings → Playback
EPG not loading	Check your XMLTV URL is accessible; try a manual refresh in Settings → EPG
Black screen on channel switch	Force-stop the app and clear cache (Fire TV Settings → Manage Installed Apps)
App not installing	Enable Apps from Unknown Sources in Fire TV Developer Options for sideloads

Subscription and pricing

FireVision TV uses a subscription model:

Monthly — flexible, cancel anytime
6-month — 15% saving vs monthly
Annual — best value, 30% saving

All plans include full VOD access, EPG, and multi-screen support. A 24-hour free trial is available — no credit card required.

What's coming next

The roadmap includes:

Chromecast support — cast from your phone to any TV
Download for offline — save VOD content for playback without internet
Sports notifications — get alerts before a match kicks off
Fire TV Cube — hands-free voice control optimisations

Open source & resources

FireVision TV is open source. Explore the code, report issues, or contribute:

FireVisionIPTV — the Fire TV / Android client app
FireVisionIPTVServer — the backend server powering activation, EPG, and subscriptions
Releases & APK downloads — grab the latest build
Live portal — device activation and account management

If you're building a custom IPTV solution or need a white-label Fire TV app for your streaming service, get in touch with us at Cadnative — FireVision TV is available as a white-label platform with full branding customisation.

Originally published at cadnative.com.

Introducing GateKeeper Zero: Society Management, Reimagined

Akshay Nikhare — Fri, 24 Jul 2026 07:48:53 +0000

GateKeeper Zero is a full-stack society management platform built for gated communities, residential complexes, and housing societies. It connects residents, security staff, and society administrators through a unified system — replacing paper registers, WhatsApp groups, and fragmented tooling with a single source of truth.

→ Visit gatekeeperzero.com

The problem it solves

Managing a gated community involves more actors than it appears: residents, visitors, delivery agents, domestic staff, security guards, and committee members — all interacting daily, mostly without a reliable audit trail.

Common pain points:

Security guards manually logging visitor entries in paper registers
No way for residents to pre-approve guests or track delivery status
Committee members sharing decisions via WhatsApp with no accountability
No digital record of maintenance complaints or their resolution

GateKeeper Zero addresses all of these through role-specific mobile apps and a backend API designed around these workflows.

Architecture overview

The platform has three main layers:

ZeroApi — a Node.js REST API (Express + PostgreSQL) that drives all business logic, role-based access control, and push notifications
zeroMobileResident — a React Native app for residents (iOS + Android)
zeroMobileSociety — a React Native app for security guards and society admins

Each app speaks exclusively to ZeroApi. There is no direct database access from mobile clients.

Resident App  ──┐
                ├──▶  ZeroApi (REST)  ──▶  PostgreSQL
Society App   ──┘

Key features

Visitor management

Residents can pre-register expected visitors — family, friends, service providers — generating a one-time approval code. When the visitor arrives, the guard scans or enters the code and the resident receives an instant push notification. Entry is logged with a timestamp and a photo if the guard's device has a camera.

Unregistered visitors trigger a gate-hold: the guard pings the resident in-app to approve or deny. No calls needed, no delays beyond resident response time.

Resident directory and flat management

Each flat is linked to one or more residents. Owners can register family members, domestic staff, and vehicles under their flat. The society admin controls the directory and can freeze or transfer flat ownership during handovers.

Complaints and maintenance

Residents raise maintenance tickets through the app. The committee receives them in the Society app, assigns them, and can update status (Open → In Progress → Resolved). Residents get notified at each stage. The full history is retained per flat.

Announcements

Society admins send announcements to all residents or specific wings/blocks. Push notifications ensure delivery without relying on everyone being in a WhatsApp group.

Security and access control

ZeroApi uses JWT-based authentication with role scopes:

Role	Scope
Resident	Own flat data, visitor approvals, complaints
Guard	Visitor entry/exit, resident lookup
Admin	Full society data, flat management, reports

Guards cannot see resident PII beyond what is needed to verify a visitor. Admins are scoped to their own society — the platform is multi-tenant at the society level.

Why React Native?

Both mobile apps share a significant portion of logic — API clients, push notification handling, form components, navigation patterns. React Native allowed the team to maintain one codebase per app while shipping native performance on both iOS and Android.

Expo was used during early prototyping for rapid iteration. The production builds are bare React Native for full control over native modules, especially around camera access and background push handling.

What's next

Vehicle tracking — ANPR camera integration for automatic vehicle entry/exit logging
Payments — maintenance dues collection with UPI/card support, directly in the resident app
Visitor history export — PDF/CSV reports for committee audits
Web portal — a browser-based admin dashboard for society committees who prefer desktop

GateKeeper Zero is a product built by Cadnative. If you're managing a housing society and want to modernise your operations, get in touch.

Originally published at cadnative.com.

Parametric Furniture Design with IMOS IX

Akshay Nikhare — Fri, 24 Jul 2026 07:48:42 +0000

IMOS IX is the leading CAD/CAM software for the furniture manufacturing industry. It integrates directly with woodworking CNC machines and enables fully parametric product design — meaning a single model can produce thousands of variants without manual rework.

What is parametric design?

Traditional CAD modelling is "static" — you draw a specific cabinet at specific dimensions. Parametric design is different: you define relationships and rules, and the software derives geometry automatically.

In IMOS IX this means you can describe a wardrobe once and then configure it for any width, height, number of doors, or internal fitment — all without touching the underlying model.

Key IMOS IX concepts

Article variants

An article in IMOS IX is a product definition with parameters exposed as inputs (width, height, depth, material, etc.). The article script calculates part dimensions, materials, and CNC programmes from those inputs.

Form editors

IMOS IX ships with a visual form editor that lets non-technical staff configure articles through a UI. You define which parameters are visible, their labels, validation rules, and dependencies between fields.

CNC post-processing

Once a variant is configured, IMOS IX generates machine data (DXF, MPR, or proprietary formats) for the CNC router. This removes manual measurement steps and dramatically reduces cutting errors.

A typical workflow

Customer order → Configurator UI → IMOS IX article → Part list + CNC files → Production

Customer selects dimensions and finish in a web configurator.
IMOS IX evaluates the article script and produces a complete bill of materials.
CNC files are sent directly to the machine — no manual intervention.
Cut parts arrive pre-labelled for assembly.

Integrating IMOS IX with an online shop

One of our most common projects is connecting IMOS IX to a Shopware store:

Customer configures a piece of furniture in the Shopware storefront.
On order confirmation, Shopware calls a middleware API.
The middleware passes parameters to IMOS IX and retrieves the generated files.
Files are attached to the production order in the ERP system.

This end-to-end automation typically reduces order-to-production time from days to hours.

When does IMOS IX make sense?

IMOS IX is worth the investment when:

You offer configured-to-order (CTO) products.
You have more than ~50 CNC-cut orders per month.
Variant management is creating errors or bottlenecks.

For smaller operations, a simpler cut-list tool may be sufficient.

Talk to us

We have built IMOS IX integrations for clients across Europe. If you're evaluating parametric design software or need help with an existing implementation, get in touch.

Originally published at cadnative.com.

Getting Started with Shopware 6 Development

Akshay Nikhare — Fri, 24 Jul 2026 07:48:22 +0000

Shopware 6 is a modern, API-first e-commerce platform built on Symfony and Vue.js. If you're coming from Shopware 5 or another platform, the architecture shift can feel steep — but once it clicks, it's powerful and highly extensible.

Understanding the architecture

Shopware 6 is split into two main areas:

Core — the Symfony-based PHP backend that handles business logic, APIs, and the administration panel.
Storefront — a Twig-based frontend layer with optional headless API access.

Most customisation happens through plugins. A plugin can override templates, add new API endpoints, register event listeners, or inject custom services.

Setting up a local environment

The fastest way to get started is with the official Docker setup:

git clone https://github.com/shopware/shopware.git
cd shopware
docker compose up -d

Once running, access the admin at http://localhost/admin and the storefront at http://localhost.

Creating your first plugin

Shopware provides a CLI tool to scaffold plugins:

php bin/console plugin:create MyPlugin
php bin/console plugin:install --activate MyPlugin

This generates a src/MyPlugin.php entry point and a composer.json. From here you can:

Register services in Resources/config/services.xml
Override templates in Resources/views/storefront/
Add migration files in src/Migration/

Theme customisation

Themes in Shopware 6 are also plugins. They use SCSS for styling and can expose configuration variables that shop owners can control via the admin UI:

<!-- Resources/theme.json -->
{
  "name": "MyTheme",
  "author": "Cadnative",
  "views": ["@Storefront", "@Plugins", "@MyTheme"],
  "style": ["app/storefront/src/scss/overrides.scss"],
  "config": {
    "fields": {
      "brand-color": { "label": "Brand colour", "type": "color", "value": "#1B5A6B" }
    }
  }
}

Performance tips

Enable HTTP cache in production — Shopware has a built-in reverse proxy layer.
Use Elasticsearch for product search at scale.
Profile slow queries with the Symfony profiler (/_profiler).
Leverage Sales Channel API for headless storefronts instead of rendering Twig server-side.

Next steps

Read the official developer docs
Explore the Shopware GitHub repos
Reach out to us at cadnative.com if you need expert help

Originally published at cadnative.com.

FireViston TV: Android App & Streaming Server for the Living Room

Akshay Nikhare — Fri, 24 Jul 2026 06:23:17 +0000

Live Project: tv.cadnative.com

What Is FireViston TV?

FireViston TV is a full-stack streaming solution designed for the modern living room. It consists of two parts that work in tight coordination:

FireViston TV Android App — a native Android/Android TV application that delivers a polished, remote-friendly viewing experience. https://github.com/akshaynikhare/FireVisionIPTV/releases
FireViston TV Server — the backend streaming infrastructure that powers content delivery, user management, and playback control hosted at tv.cadnative.com

Together, they form a complete, self-contained streaming platform.

The Android App

Built for the 10-Foot Experience

The FireViston Android app is designed for television screens — large fonts, d-pad navigation, and a layout that works from across the room. No pinching, no scrolling hunts, no mobile-style UI crammed onto a 55-inch display.

Smooth Playback

Video streaming requires more than just playing a file. FireViston handles adaptive bitrate streaming, buffer management, and codec compatibility to ensure smooth playback across the broadest range of Android TV devices — from budget sticks to high-end smart TVs.

Content Discovery

A clean, browsable content grid lets users find what they want quickly. Categories, search, and a "continue watching" row reduce friction from intent to playback.

The Server Backend

Reliable Infrastructure

The FireViston server at tv.cadnative.com manages content ingestion, transcoding pipelines, and delivery. It's built to handle concurrent streams without degrading quality for any individual viewer.

API-Driven Architecture

The Android app communicates with the server through a REST API, making the backend flexible enough to support additional clients — web players, other mobile platforms — without rewriting core logic.

User & Session Management

Account creation, authentication, playback progress sync, and device management all happen server-side. Users can pick up on any device exactly where they left off.

Why a Custom Streaming Stack?

Off-the-shelf streaming platforms come with constraints: content policies, revenue sharing, limited branding control, and dependence on third-party availability.

FireViston TV gives full control — over the content, the experience, and the infrastructure. For operators who need that ownership, it's the right choice.

Get FireViston TV

Android App: Available for Android and Android TV devices
Streaming Server: tv.cadnative.com

How a Single beforeEach Killed Our CI for 36 Hours

Akshay Nikhare — Fri, 24 Jul 2026 06:23:10 +0000

Six failed CI runs. Thirty-six hours of GitHub Actions time. Every run timing out at exactly the 6-hour limit.

The culprit was one line in tests/setup.js.

The Setup

We were building a multi-tenant platform with a PostgreSQL backend — around 76 database models handling everything from user accounts and billing to visitor logs and real-time notifications. The test suite had grown to roughly 1,140 test cases across 36 files.

Standard stuff. CI ran on every PR. Tests passed locally. And then one day, CI just... never finished.

The Anti-Pattern

Here's what the test setup looked like:

// tests/setup.js
beforeEach(async () => {
  const tableNames = await getTableNames(); // 76 tables
  await sequelize.query(
    `TRUNCATE TABLE ${tableNames.join(', ')} CASCADE;`
  );
});

The intent was clean isolation — every test starts with a blank slate. Reasonable in theory. Catastrophic in practice.

The Math

Do the multiplication:

76 tables × 1,140 tests = 86,640 TRUNCATE operations

Each TRUNCATE TABLE ... CASCADE is not a cheap operation. PostgreSQL has to:

Acquire exclusive locks on all referenced tables
Walk the foreign key graph to find dependent tables
Truncate each in dependency order
Release locks

With a moderately complex schema where most tables reference others (users → societies → members → invoices → payments → ...), a single TRUNCATE ... CASCADE on a central table can fan out into dozens of implicit truncations.

Multiply that by 86,640 and you have a test suite that will never complete within any reasonable timeout.

Why It Wasn't Caught Sooner

Two reasons:

1. It used to be fast. When the suite had 50 tests and 20 tables, this pattern worked fine. 50 × 20 = 1,000 truncations — uncomfortable but survivable. Nobody noticed when the suite crossed a tipping point.

2. Local runs used a different database state. Locally, developers often ran a subset of tests with --grep or file-specific runs. The full suite was only ever run on CI, and CI was slow enough that most assumed it was just a "CI is slow" problem rather than a runaway complexity issue.

The Fix

Three changes, applied together:

1. Move sync to `beforeAll`, not `beforeEach`

// tests/setup.js — AFTER
beforeAll(async () => {
  await sequelize.sync({ force: true }); // once per suite, not per test
});

Tables are created once at the start of the suite. No teardown between tests.

2. Use unique identifiers in test data

Without per-test cleanup, tests can no longer share fixed data. The fix is to make every piece of test data unique:

// BEFORE — breaks without cleanup
const user = await createTestUser({ email: 'test@example.com' });

// AFTER — safe without cleanup
const user = await createTestUser({
  email: `user_${Date.now()}_${Math.random().toString(36).slice(2)}@test.com`
});

Timestamps and short random suffixes make collisions statistically impossible across a test run. UUIDs work too — use whatever your helpers already produce.

3. Add CI timeout safety nets

The default GitHub Actions job timeout is 6 hours. That's a very long time to wait before learning something is wrong. Set explicit timeouts on test steps:

- name: Run tests
  run: npm test
  timeout-minutes: 15

Now a runaway suite fails in 15 minutes instead of 6 hours. You get the signal fast and spend less Actions budget on it.

Results

	Before	After
TRUNCATE operations	86,640	0
Test suite duration	6+ hours (timeout)	~3 minutes
CI failure signal	After 6 hours	After 15 minutes max

When Transaction Rollback Is Better

If your tests don't create their own transactions internally, wrapping each test in a transaction and rolling back is faster than TRUNCATE and safer than the unique-ID approach:

let transaction;

beforeEach(async () => {
  transaction = await sequelize.transaction();
});

afterEach(async () => {
  await transaction.rollback();
});

This works well for simpler schemas. We couldn't use it because several of our tested code paths opened their own transactions internally, which can't be nested without explicit savepoint support. The unique-ID approach was the safer choice for our case.

The Underlying Lesson

Test isolation strategies don't scale linearly — they scale with tests × tables. A pattern that works at 50 tests and 20 tables can fail spectacularly at 1,000 tests and 76 tables.

If your test suite is growing and CI is getting slower, check your setup/teardown strategy before assuming you need faster hardware.

The x-tenant-id Pattern: Multi-Tenant API Without Multi-Tenant Complexity

Akshay Nikhare — Fri, 24 Jul 2026 06:23:02 +0000

When you're building a multi-tenant SaaS, the first architectural question is usually: how do you keep tenant data isolated? The options range from separate databases per tenant (maximum isolation, maximum cost) to a shared database with row-level filtering (minimum cost, more careful coding required).

But there's an equally important question that gets less attention: how does your API know which tenant context a request belongs to?

This post covers a pattern we've used in production: a custom request header for tenant scoping, combined with JWT authentication. Simple to implement, easy to audit, and flexible enough to support multi-tenant access from a single user account.

The Three Common Approaches

1. Subdomain-based (`tenant.yourdomain.com`)

The tenant is encoded in the hostname. Each subdomain routes to the same backend, which extracts the tenant from the Host header.

Good: Intuitive, visible in the URL.
Bad: Requires wildcard TLS certs, more complex DNS setup, awkward in development, doesn't work for mobile API clients the same way.

2. URL path-based (`/api/tenants/{tenantId}/...`)

The tenant identifier is part of every route path.

Good: RESTful, self-documenting.
Bad: Bloats all route definitions, requires every endpoint to include the tenant segment, makes API versioning messier.

3. Header-based (`x-tenant-id: <id>`)

A custom header carries the tenant context. Routes stay clean. The tenant scope is resolved in middleware before the handler runs.

Good: Routes stay simple, middleware handles scoping uniformly, works well with JWT auth, easy to test.
Bad: Less visible (the tenant isn't in the URL), requires clients to always include the header.

We use the header approach.

The Implementation

The API accepts two forms of auth:

A JWT token in the Authorization header — identifies who is making the request
A tenant ID in the x-tenant-id header — identifies on behalf of which tenant

POST /api/v1/members
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
x-tenant-id: tenant_01GZ8K3X7Y
Content-Type: application/json

Middleware

Auth middleware runs first and validates the JWT. Tenant middleware runs second and validates the x-tenant-id against the authenticated user's permitted tenants:

// middleware/requireAuth.js
export async function requireAuth(req, res, next) {
  const token = extractBearerToken(req.headers.authorization);
  if (!token) return res.status(401).json({ error: 'Unauthorized' });

  try {
    const payload = verifyJwt(token);
    req.user = payload;
    next();
  } catch {
    res.status(401).json({ error: 'Invalid token' });
  }
}

// middleware/requireTenantContext.js
export async function requireTenantContext(req, res, next) {
  const tenantId = req.headers['x-tenant-id'];
  if (!tenantId) return res.status(400).json({ error: 'x-tenant-id header required' });

  // Verify the authenticated user has access to this tenant
  const membership = await db.membership.findFirst({
    where: {
      userId: req.user.id,
      tenantId,
      status: 'active',
    },
  });

  if (!membership) return res.status(403).json({ error: 'Access denied' });

  req.tenantId = tenantId;
  req.role = membership.role;
  next();
}

Route handlers then have req.tenantId and req.role available. All database queries in those handlers include where: { tenantId: req.tenantId }.

Route Registration

Tenant-scoped routes apply both middlewares. Public routes (auth endpoints, health checks) apply neither:

// Public
router.post('/auth/login', loginHandler);
router.get('/health', healthHandler);

// Tenant-scoped
router.use('/members', requireAuth, requireTenantContext, membersRouter);
router.use('/invoices', requireAuth, requireTenantContext, invoicesRouter);
router.use('/settings', requireAuth, requireTenantContext, settingsRouter);

Middleware is applied at the router level, not per-handler. New routes under a tenant-scoped prefix automatically inherit the context without any extra work.

Multi-Tenant Access From One Account

The header pattern makes something else easy: a single user account accessing multiple tenants.

A super-admin or management tool needs to query across tenants or switch context without re-authenticating. With the header pattern this is trivial — issue one JWT for the user, then pass different x-tenant-id values per request:

// Management dashboard switching tenant context
async function fetchMembersForTenant(tenantId) {
  return api.get('/members', {
    headers: {
      'Authorization': `Bearer ${userToken}`,
      'x-tenant-id': tenantId,
    }
  });
}

With subdomain or path-based approaches, the same scenario requires different base URLs or duplicated route structures.

Adding Defense-in-Depth: Row-Level Security

The header + middleware pattern handles application-layer tenant isolation. For an additional layer at the database level, PostgreSQL's Row-Level Security can enforce isolation even if a bug in application code omits a tenantId filter:

-- Policy: users can only see rows belonging to their current tenant
ALTER TABLE members ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON members
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);

At the start of each request, set the current tenant on the DB connection:

await db.$executeRaw`SELECT set_config('app.current_tenant_id', ${req.tenantId}, true)`;

Now even a query that forgets WHERE tenant_id = ? returns empty results instead of leaking data. The middleware is the first line of defense; RLS is the backstop.

Tradeoffs to Know Before Adopting

Clients must always send the header. This is a discipline requirement. Forgetting the header returns a 400, which is fast to debug, but it's a paper cut during initial integration. Document it clearly and consider a helpful error message: "x-tenant-id header is required for this endpoint. See docs for details."

The header is visible in logs. Tenant IDs aren't secrets — they're identifiers — but make sure your log sanitization rules treat them consistently with other metadata.

Switching tenants mid-session is application-layer logic. The API doesn't know or care about "the current tenant" in session state. The client always tells the API which tenant context to use. This is explicit, which is good, but requires the client to manage that state.

Summary

The x-tenant-id header pattern is not glamorous, but it's effective. Routes stay clean. Middleware handles scoping uniformly. A single JWT works across multiple tenant contexts. And the pattern composes naturally with database-level isolation when you need it.

For most multi-tenant APIs where tenants are organizations (not individual users), this pattern is worth considering before reaching for the subdomain or path-based alternatives.

onPreviewKeyEvent vs onKeyEvent on Android TV: A Subtle D-Pad Bug

Akshay Nikhare — Fri, 24 Jul 2026 06:22:55 +0000

The bug report was simple: long-pressing the d-pad center button on a channel card should toggle the favorite — it wasn't working reliably. On some devices it fired once and stopped. On others it didn't fire at all on long-press.

The fix was changing onKeyEvent to onPreviewKeyEvent in one Composable. The reason why is worth understanding.

Background: Two Event Handlers in Compose

Jetpack Compose exposes two modifier-level hooks for key input:

Modifier.onKeyEvent { keyEvent -> ... }
Modifier.onPreviewKeyEvent { keyEvent -> ... }

They sound equivalent. They're not. The difference is where they sit in the event propagation chain.

How Android TV Routes D-Pad Events

When a user presses a key on a TV remote, Android routes the event through a dispatch tree:

Activity
  └─ ViewGroup (root)
       └─ FocusedComposable
            └─ Child Composables

The event travels down first (capture phase), then up (bubble phase):

Capture (top → focused node): onPreviewKeyEvent handlers fire here, outermost first.
Bubble (focused node → top): onKeyEvent handlers fire here, innermost first.

onPreviewKeyEvent is the capture phase. onKeyEvent is the bubble phase.

Why This Matters for Long-Press

Android TV handles long-press recognition at the framework level. When you hold the d-pad center button:

A KeyEvent.ACTION_DOWN fires immediately.
If the key is held, the framework generates repeated ACTION_DOWN events at the key repeat rate.
ACTION_UP fires when the button is released.

The long-press callback that Compose's focus system uses for "confirm" actions (select, activate) consumes ACTION_DOWN during the bubble phase — specifically to prevent the holding action from also triggering the tap action.

When the ChannelCard had a click handler wired for the primary action and onKeyEvent for the long-press toggle, the click handler's bubble-phase consumption of ACTION_DOWN was racing with the long-press handler. On some devices the click handler won, swallowing the event before the long-press code ran.

The Fix

Before:

Modifier.onKeyEvent { keyEvent ->
    if (keyEvent.key == Key.DirectionCenter &&
        keyEvent.type == KeyEventType.KeyDown &&
        keyEvent.isLongPress) {
        onToggleFavorite()
        true
    } else {
        false
    }
}

After:

Modifier.onPreviewKeyEvent { keyEvent ->
    if (keyEvent.key == Key.DirectionCenter &&
        keyEvent.type == KeyEventType.KeyDown &&
        keyEvent.isLongPress) {
        onToggleFavorite()
        true
    } else {
        false
    }
}

onPreviewKeyEvent intercepts the event during the capture phase — before any child or peer handler gets a chance to consume it. The long-press fires cleanly, and returning true stops the event from propagating further, so the normal click action doesn't also trigger.

When to Use Each

Situation	Use
Reacting to a key after children have had first chance	`onKeyEvent`
Intercepting a key before children or peer handlers see it	`onPreviewKeyEvent`
Global shortcuts that should always fire regardless of focus	`onPreviewKeyEvent` on a parent
Input that should only fire when no child claimed it	`onKeyEvent` on a parent
Long-press that conflicts with click on the same node	`onPreviewKeyEvent`

The rule of thumb: if a click handler and a key handler live on the same composable and the key handler is for a long-press or a secondary action, use onPreviewKeyEvent to get in before the click machinery.

A Note on `isLongPress`

The isLongPress property on KeyEvent in Compose isn't always reliable across all Android TV hardware. A more robust approach uses elapsed time:

var keyDownTime = 0L

Modifier.onPreviewKeyEvent { keyEvent ->
    when {
        keyEvent.key == Key.DirectionCenter &&
        keyEvent.type == KeyEventType.KeyDown -> {
            if (keyDownTime == 0L) keyDownTime = System.currentTimeMillis()
            val held = System.currentTimeMillis() - keyDownTime
            if (held >= 500L) {
                onToggleFavorite()
                keyDownTime = 0L
                true
            } else false
        }
        keyEvent.key == Key.DirectionCenter &&
        keyEvent.type == KeyEventType.KeyUp -> {
            keyDownTime = 0L
            false
        }
        else -> false
    }
}

This measures elapsed hold time manually, which is consistent across the wide range of Android TV hardware — from budget HDMI sticks to mid-range smart TVs — where key repeat rates and long-press thresholds vary.

Summary

onKeyEvent and onPreviewKeyEvent are not interchangeable. If you're building interactive cards on Android TV and a long-press isn't firing reliably, the cause is almost certainly event consumption order. Move to onPreviewKeyEvent and intercept before the bubble phase claims the event.

Mono-Repo + Multi-Repo: How We Structured 6 Apps Across 4 Repositories

Akshay Nikhare — Fri, 24 Jul 2026 06:22:45 +0000

Most teams treat "monorepo vs multi-repo" as a binary choice. Pick one, commit, move on. We ended up with a hybrid, and it turned out to be the right call — not out of indecision, but because our apps have genuinely different deployment and ownership characteristics.

Here's what we built, why, and what it costs.

The System

The platform consists of six applications:

App	Type	Primary Users
REST API backend	Node.js + TypeScript	— (consumed by all apps)
Society dashboard	React web app	Society managers, admins, accountants
Company admin panel	React web app	Internal operations
Marketing website	Next.js	Public
Resident mobile app	React Native (Expo)	Residents
Guard mobile app	React Native (Expo)	Security personnel

All six apps talk to the same API. But they have very different deployment cycles, team ownership, and testing requirements.

The Structure: 4 Repositories

repo: main-platform (monorepo)
├── api/           — Express + Prisma backend
├── web-society/   — Society dashboard
├── web-admin/     — Company admin panel
└── web-marketing/ — Marketing site

repo: mobile-resident  — Resident app (React Native)
repo: mobile-guard     — Guard app (React Native)
repo: mobile-staff     — Society staff mobile app (React Native)

The web apps and the API live together in one monorepo. The three mobile apps each have their own repository.

Why Split Mobile From Web?

The driving factor was deployment cadence and review process.

Web apps deploy on push — merge to main, CI builds, CDN updated within minutes. The feedback loop is fast, rollbacks are instant, and there's no approval gate between code and production.

Mobile apps go through app store review. A release cycle includes building a release APK, submitting to Google Play (and Apple App Store), waiting for review, and then a staged rollout. The cadence is measured in days, not minutes. Mistakes are expensive to reverse — a bad release means submitting a patch, waiting again, and potentially having a broken version live for days.

Given that difference, mobile releases warrant a separate release workflow, separate versioning (release-please per repo), separate EAS build config, and a dedicated changelog. Bundling mobile with web would mean mobile releases dragging along unrelated web changes and making the release notes hard to read.

Separate repos give each mobile app its own clean release history.

Why Keep the Backend and Web Apps Together?

Because they change together constantly.

Most features touch both the API and a web frontend. A new billing feature means a new API endpoint, a new React page, and updates to both. With the API and web apps in the same repo:

One PR covers the full change
The CI pipeline validates everything together
Reviewing a PR gives you the complete picture
No cross-repo issue tracking for basic feature work

If they were in separate repos, every feature PR would spawn linked PRs across two repositories — more coordination overhead for changes that are logically one unit.

The Cross-Repo Challenge

The seam between repos is where friction lives.

When a new API endpoint or a modified contract affects mobile apps, you get cross-repo work: one PR in the main platform repo, one or more PRs in the mobile repos. We handle this with explicit cross-linking:

The parent issue lives in the main repo
Each mobile repo gets a child issue referencing back
PRs on both sides link to the same parent issue

It works, but it requires discipline. The worst version of this is when someone merges an API change without checking whether the mobile apps need a corresponding update. To guard against that, breaking API changes go through a separate review step that explicitly asks: "which mobile app versions does this affect, and are those PRs in flight?"

Branch Protection Across All Repos

All four repos have identical branch protection on main:

No direct pushes
At least one approving review required
CI must pass before merge

This is non-negotiable. With a multi-repo setup, it's easy for protection rules to diverge between repos. Keeping them identical means the same habits apply regardless of which repo you're working in.

Shared Dependencies and Drift

The main risk with multi-repo mobile apps is dependency drift. Each mobile repo has its own package.json. If main-platform bumps a shared utility, the mobile repos don't automatically follow.

Our mitigation: the Expo SDK version and key shared dependencies (React Native, TypeScript, Babel config) are pinned to the same versions across all mobile repos. We check this in a periodic sync script rather than trying to enforce it automatically — automatic enforcement across repos adds tooling complexity we haven't needed yet.

What We'd Do Differently

Better automation for cross-repo issues. Manually linking parent and child issues works until someone forgets. A GitHub Action that opens draft child issues in mobile repos when a label is applied to a main-repo issue would remove that failure mode.

Shared TypeScript types package. API response types are currently duplicated between the backend, web apps, and mobile apps. A shared @platform/types internal package published to a private registry (or referenced via workspace) would make type drift detectable at compile time. We've planned this but haven't needed it badly enough to prioritize it yet.

Document the structure early. The hybrid structure is intuitive once you understand the reasoning, but onboarding a new contributor requires explaining why mobile lives in separate repos. A REPOS.md at the root of the main repo — linking out and explaining the structure — saves the first 10 minutes of every onboarding conversation.

The Summary

Characteristic	Monorepo (web + API)	Multi-repo (mobile)
Deployment cadence	Continuous (minutes)	Store review (days)
Typical change scope	Multi-file, multi-layer	Self-contained per app
Release notes	Combined	Per app
PR complexity	High — covers whole feature	Focused
Cross-team coordination	Implicit (same repo)	Explicit (issue links)

Monorepos reduce coordination overhead for tightly coupled code. Multi-repo reduces noise for code that releases independently. The answer isn't one or the other — it's matching your repo structure to your actual deployment and ownership boundaries.

DEV Community: Akshay Nikhare

IMOS IX : hardware Häfele Espagnolette Lock

What is an Espagnolette lock?

Importing the connector into IMOS IX

Constructive connector characteristics

Element characteristics (LS_TYP)

Editable dimensional characteristics

Rod positioning and geometry

Part numbers for rotating doors

Generating the export file

Verifying the output

Talk to us

FireVision TV: Native IPTV Streaming for Fire TV

What is FireVision TV?

Why native matters for Fire TV

Setting up FireVision TV

EPG and channel management

Parental controls

Troubleshooting common issues

Subscription and pricing

What's coming next

Open source & resources

Introducing GateKeeper Zero: Society Management, Reimagined

The problem it solves

Architecture overview

Key features

Visitor management

Resident directory and flat management

Complaints and maintenance

Announcements

Security and access control

Why React Native?

What's next

Parametric Furniture Design with IMOS IX

What is parametric design?

Key IMOS IX concepts

Article variants

Form editors

CNC post-processing

A typical workflow

Integrating IMOS IX with an online shop

When does IMOS IX make sense?

Talk to us

Getting Started with Shopware 6 Development

Understanding the architecture

Setting up a local environment

Creating your first plugin

Theme customisation

Performance tips

Next steps

FireViston TV: Android App & Streaming Server for the Living Room

What Is FireViston TV?

The Android App

Built for the 10-Foot Experience

Smooth Playback

Content Discovery

The Server Backend

Reliable Infrastructure

API-Driven Architecture

User & Session Management

Why a Custom Streaming Stack?

Get FireViston TV

How a Single beforeEach Killed Our CI for 36 Hours

The Setup

The Anti-Pattern

The Math

Why It Wasn't Caught Sooner

The Fix

1. Move sync to beforeAll, not beforeEach

2. Use unique identifiers in test data

3. Add CI timeout safety nets

Results

When Transaction Rollback Is Better

The Underlying Lesson

The x-tenant-id Pattern: Multi-Tenant API Without Multi-Tenant Complexity

The Three Common Approaches

1. Subdomain-based (tenant.yourdomain.com)

2. URL path-based (/api/tenants/{tenantId}/...)

3. Header-based (x-tenant-id: <id>)

The Implementation

1. Move sync to `beforeAll`, not `beforeEach`

1. Subdomain-based (`tenant.yourdomain.com`)

2. URL path-based (`/api/tenants/{tenantId}/...`)

3. Header-based (`x-tenant-id: <id>`)

A Note on `isLongPress`