Technology Stack

Farkitect is built with a modern, open-source stack chosen for a balance of developer productivity, real-time collaboration, and long-term flexibility. We are immensely grateful that these technologies exist — Farkitect simply would not be possible without the work of the teams and communities behind them. This page describes the key technologies and the thinking behind each choice.

The Short Version

Farkitect is a TypeScript application built with React, backed by Convex for real-time data sync, hosted on Vercel, and packaged as both a web app and an Electron desktop app. The UI is composed of dockable panels (like VS Code), a tree-based model explorer, and a canvas-based diagram editor. Everything is organized as a monorepo with shared packages.

Application Platform

TypeScript

The entire codebase — frontend, backend, build scripts, and tests — is written in TypeScript. Type safety catches a huge class of bugs at compile time, and it means the same language and mental model is used everywhere. No context-switching between languages.

React

React is the UI framework. Its component model maps naturally to the kind of application Farkitect is — panels, trees, forms, and diagram nodes are all components that compose together. The ecosystem of high-quality libraries (React Flow, React Arborist, Dockview) made it the obvious choice.

Vite

Vite is the build tool for the modeling application. It’s fast — hot module replacement during development is near-instant — and it works well with both the web app and the Electron desktop app. It replaced heavier alternatives like Webpack without any compromises.

Next.js (Website)

The farkitect.com website — the marketing pages, the Farketplace, sign-in, and the account dashboard — is a separate Next.js application. Next.js provides server-side rendering, which matters for public pages that need to load fast and be indexable by search engines. The modeling application itself doesn’t need any of that, so it stays on the lighter Vite setup; the two share the same design system and backend.

Electron (Desktop App)

The desktop version of Farkitect is an Electron app, which gives access to native capabilities: file system access, native menus, window management, and offline support. The renderer code never imports Electron directly — platform-specific features are abstracted so the same UI code runs in both the desktop app and the web browser.

The desktop app is coming soon. In the meantime, the web app provides the full experience.

Backend and Data

Convex

Convex is Farkitect’s backend — it provides the database, server functions, and real-time synchronization in a single system. When one team member creates an element, everyone else sees it instantly. There’s no REST API to design, no WebSocket plumbing to manage, and no cache invalidation to get wrong.

This was the most consequential technology choice in the project, for two reasons: what a modeling tool is, and how Farkitect is built.

Why it matters for a modeling tool

A model is a densely connected graph, and almost any change fans out. Rename one element and every open diagram, catalog, board, and properties panel showing it must update — for every member of the project, at the same time. In a traditional backend, that fan-out is your problem: caches to invalidate, sockets to push through, background jobs to keep consistent, and race conditions waiting wherever two of those disagree. In Convex, every panel is a reactive query over the same tables. When the data changes, every query that read it re-runs and every subscribed view updates. Farkitect’s panels contain no synchronization code at all — real-time collaboration is a property of the platform, not a feature we built.

Convex is also fully type-safe end-to-end. The database schema, server functions, and client queries all share TypeScript types, so if the schema changes, the compiler catches every place that needs to update — from the schema definition all the way to the React component rendering the value.

Why it matters for AI-assisted development

Farkitect is developed in close collaboration with AI, and Convex turns out to be unusually well suited to that way of working. The Convex team makes the general argument in their video “AI agents love Convex. Here’s why.”, identifying three design properties that compensate for what AI is genuinely weak at. Here is how each of those general properties shows up concretely in Farkitect.

Everything is typed code, so the AI gets real feedback. The video’s first point is that AI-generated code converges on correctness only when there’s a fast, trustworthy feedback loop — and that Convex provides one by making the entire backend typed code rather than dashboards and configuration languages. In Farkitect, the whole MOF domain model is expressed this way: the elements table is a discriminated union over Package, Class, Property, DataType, Enumeration, and Relationship, defined in one schema file, and every server function, data-access hook, and panel component consumes types generated from it. Scheduled jobs, HTTP routes, and even the email integration are ordinary TypeScript files in the same repository. The practical effect: when the schema gained project scoping, the compiler enumerated every query, mutation, and component that had to change — the AI worked through the list rather than hunting for call sites. The development loop is write, typecheck, then run the test suite (500+ tests, many of which execute the real Convex functions against an in-memory backend), and because Convex behaves identically in development and production, feedback earned in that loop still holds after deployment.

Reactivity enables local reasoning. The video’s second point is that AI’s weakest muscle is whole-codebase context, and that Convex’s managed data flow lets a function be written correctly by looking only at that function. Farkitect leans on this everywhere. The same setValues mutation is called from the Properties panel, from a catalog cell, and when a card is dragged between Board columns — and it contains no knowledge of any of them; it just writes the property value, and every reactive query showing that element re-runs. Renaming an element updates every open diagram, catalog, and board for every project member, yet the rename mutation contains no fan-out code at all. The clearest proof is the Board view itself: it arrived many development phases after the mutations it observes, and adding it required changing none of them. For AI-assisted development this means a new feature really is local — when the AI writes a mutation it doesn’t survey the panels, and when it writes a panel it doesn’t audit the mutations.

A whole class of bugs doesn’t exist. The video’s third point is that traditional backends carry an unwritten rulebook — race conditions, cache invalidation, consistency between systems — that lives in reasoning about the code rather than in the code, which is exactly where AI is least reliable. Because Convex mutations are transactional and its caching is automatic, that rulebook never had to be written into Farkitect. Cloning a package deep-copies the entire tree — elements, diagrams, nodes, edges, property values — inside a single transactional mutation, so a collaborator can never observe a half-cloned package, and there is no locking code to get wrong. Two members editing the same element at once resolve through the transaction system, not through conflict-handling code we wrote. Searching the codebase for a lock, a manual cache invalidation, or a “what if these two writes interleave?” workaround finds nothing — the category of defect that is hardest to test for, and hardest for AI to avoid, was designed out before development started.

WorkOS (Authentication)

Farkitect uses WorkOS for authentication. WorkOS is built for business-to-business applications and supports enterprise SSO, SAML, and directory sync out of the box. This means organizations can connect their existing identity providers (Okta, Azure AD, Google Workspace) without any custom integration work.

Resend (Email)

Invitation emails and notifications are sent through Resend, integrated via Convex’s component system. It’s simple, reliable, and purpose-built for transactional email.

Hosting and Deployment

Vercel

All of Farkitect’s web surfaces are hosted on Vercel: the web application itself, the marketing website (built with Next.js), and this documentation site (built with Astro Starlight). Vercel serves everything from a global CDN, and its preview deployments mean every change can be reviewed on a live URL before it reaches production.

Deployments run through the CI pipeline — each change is built and tested, deployed to a preview environment, and only promoted to production after checks pass. The Convex backend deploys separately to Convex’s own cloud, on the same promotion path.

User Interface

Dockview (Panel Layout)

Farkitect’s interface follows the VS Code pattern of dockable, draggable panels. Dockview provides this layout system — panels can be tabbed together, split, resized, maximized, and popped out into separate windows. It’s a React-native library with zero external dependencies.

React Arborist (Model Explorer)

The Explorer panel — the tree view on the left where you browse packages, elements, and diagrams — is built with React Arborist. It handles virtualization (rendering only the visible rows, even with thousands of nodes), drag-and-drop reordering, inline renaming, and keyboard navigation. It’s headless, so Farkitect controls all the rendering.

React Flow (Diagram Canvas)

The diagram canvas — where you draw and arrange elements — is built with React Flow. Each node on a diagram is a React component, which means Farkitect can render notation-specific shapes, icons, colors, compartments, and stereotypes as regular React elements. React Flow handles the interaction layer: dragging, zooming, panning, selection, and connection handles.

TanStack Table (Catalogs)

Catalogs — the tabular views of model elements — are built with TanStack Table. It’s a headless table library that provides sorting, filtering, column reordering, and column visibility without dictating how things look. This makes it straightforward to render metamodel-driven columns with the right editors for each property type.

dnd-kit (Board View)

The Board view — the Kanban-style view where elements become cards in columns driven by an enumeration property — uses dnd-kit for its drag-and-drop. Dragging a card between columns updates the underlying property value on the model element. dnd-kit was chosen for its accessibility (keyboard-driven drag is built in), small footprint, and fine-grained control over drop behavior.

Tiptap (Rich Text Notes)

Element notes and project descriptions are edited with Tiptap, a headless rich text editor built on ProseMirror. It provides formatting, links, and images while leaving the rendering entirely to Farkitect’s components, so notes look at home in both light and dark themes.

html-to-image and jsPDF (Diagram Export)

Exporting a diagram as an image or PDF uses html-to-image to capture the canvas exactly as rendered — including notation shapes, colors, and compartments — and jsPDF to produce the PDF output.

shadcn/ui and Tailwind CSS

The component library is shadcn/ui — a collection of accessible, well-designed components built on Radix UI primitives. Unlike most component libraries, shadcn/ui components live in the codebase as source files rather than hidden inside a package. This makes them fully customizable.

Styling is done with Tailwind CSS, a utility-first approach where styles are co-located with components. It keeps the styling consistent and makes it easy to support both light and dark themes.

State Management

Zustand (UI State)

Local UI state — things like the current selection, active tool, undo stack, and panel preferences — is managed with Zustand. It’s a lightweight state library that avoids the boilerplate of larger solutions like Redux while providing the same capabilities.

Forms and validation

The Properties panel and other forms are plain controlled inputs with no form library. Validation is written against the metamodel directly: the rules for each field (required, type, format) are read from its M2 property definition, so they come from the metamodel automatically.

Architecture

Monorepo

Farkitect is organized as a monorepo using TurboRepo and pnpm workspaces. Shared code lives in packages that both the desktop and web apps import:

Package	What it contains
backend	Convex schema, server functions, data access hooks
frontend	Panels, components, stores, contexts — the shared UI
ui	Design system components (shadcn/ui)

This means a bug fix or feature in the shared frontend package is immediately available in both the desktop and web apps, without publishing or versioning.

Platform Abstraction

The shared UI code never touches platform-specific APIs directly. Instead, capabilities like file dialogs, native menus, and window management are abstracted behind a thin interface. The desktop app provides Electron implementations; the web app provides browser implementations. This keeps the vast majority of the code platform-agnostic.

AI-Assisted Development

Farkitect is developed in close collaboration with AI (specifically Claude Code). Many of the technology choices were influenced by how well they work in this workflow:

• TypeScript generates more accurate AI-written code than untyped JavaScript
• shadcn/ui components live in the codebase, so the AI can read and modify them directly
• Tailwind CSS co-locates styles with markup, giving the AI full context in a single file
• Convex provides end-to-end type safety, reducing the surface area for AI-introduced bugs — see the Convex section above for the full story
• Consistent conventions across the codebase mean the AI can replicate established patterns reliably

This isn’t about replacing developers — it’s about having an extremely productive collaboration between human judgment and AI execution.