Fieldwork: Building a Working App With Zyra, Ryft, and ZeeDB

Fieldwork puts three of my developer tools under pressure from an actual application. Zyra renders a creative-studio site and project desk. Ryft checks typed backend data. ZeeDB persists the records. A small Node adapter connects those parts where their current interfaces do not meet directly.

The application has two deliberately different surfaces. Its landing page uses films, editorial typography, image reels, parallax, and scene transitions. The Studio Desk handles projects, tasks, favorites, archives, and work that should survive a disconnected browser.

The Fieldwork project page provides captures and architecture notes. Its related tool pages cover Zyra, Ryft, from the Forge folder, and ZeeDB. The supplied application is a local personal workspace, not a configured public multi-user service.

One App, Two Kinds of Attention

The landing page is an invitation to explore. Its seven sections move through an opening film, manifesto, selected work, capabilities, process, journal, and contact. Remote photography and video provide the visual material, while scroll position coordinates the transitions.

The desk serves a different intention: find a project, change a task, inspect progress, and return to work. It retains the editorial language of the website, but its controls must expose state clearly. A cinematic transition is not a substitute for knowing whether an edit has been saved.

Contact connects the surfaces in a concrete way. A submitted brief is stored as a project in review. It does not send an email. The showcased concepts and journal text are demonstration material, not evidence of real client commissions.

Zyra Makes Interaction Precise

Zyra is an independent TypeScript/TSX framework with its own reactive graph, compiler, DOM renderer, lifecycle scopes, and motion primitives. Components set up once per mount; signal changes update the bindings that depend on them.

The small counter from its documentation illustrates the contract. Updating a signal changes the associated text without treating every change as another full component setup. Fieldwork uses that model for task state, progress, and other frequently changing interface values.

Motion has lifecycle requirements too. Scoped animations and observers must stop when their scene is removed. Offscreen films pause, reduced-motion preferences disable the animated scrolling and video experience, and an explicit toggle lets the visitor pause motion.

The payoff is understandable ownership. A scene owns the work needed for its animation, and a signal owns the state that a binding reads. The framework's supported release-candidate profile remains bounded; using it here does not establish universal production readiness.

Offline Work Starts With a Local Commit

The project desk uses Zyra's reactive IndexedDB collections and an atomic local mutation journal. A disconnected edit therefore has a durable local representation rather than living only in a component variable until the next network request succeeds.

There are two separate promises to explain: an edit can be retained locally, and an edit can be accepted by the backend. Treating both as the same success state would hide queued work and conflicts.

MDN's IndexedDB overview describes the browser storage API behind that local layer. Fieldwork adds its own project model, mutation identities, and synchronization behavior above it.

The built application also includes a precached service worker for its offline profile. Vite development mode intentionally does not register that worker. A test of offline behavior needs the built local service, not an assumption that every development tab has the same cache behavior. Remote films and photography remain outside the offline cache.

The Adapter Is an Explicit Part of the Architecture

The data path is browser collection, local journal, Node HTTP adapter, and then the relevant native service. The adapter calls Ryft to validate project/task data and uses ZeeDB's authenticated HTTP interface to persist project records.

This boundary is important. Ryft 0.3 has declared SQLite/MongoDB capabilities, but no outbound HTTP or native ZeeDB capability. Fieldwork does not pretend that a direct Ryft-to-ZeeDB driver exists. The Node adapter supplies the integration without changing either runtime.

Ryft's strict codecs and domain validation remain active in that flow. The adapter does not replace them with a parallel set of JavaScript business rules. All Fieldwork project records are in ZeeDB rather than quietly being stored in Ryft's SQLite path.

That is a useful test of a custom stack: the missing capability becomes an explicit architectural component instead of an undocumented shortcut.

Retrying Without Duplicating the Work

A request can reach the server and commit successfully while its acknowledgement fails to reach the browser. Retrying blindly risks applying the same change twice. Fieldwork gives mutations stable IDs and commits each project update with its mutation receipt in one ZeeDB batch.

The adapter serializes mutations in one process and checks per-project versions. A repeated identity can be reconciled with its existing receipt. A stale version produces a conflict rather than silently overwriting a newer project record, and the interface preserves local edits while offering explicit choices.

This is an application-specific synchronization adapter, not Zyra's standard sync protocol. One adapter process owns the workspace. Multiple independent writers against the same collections are outside that supported arrangement.

The point of the receipt is not to claim that networks become perfectly reliable. It is to make an uncertain acknowledgement recoverable without asking the person to guess whether the work happened.

Local Boundaries Shape the Product

The supplied launcher runs the desk adapter and native services on loopback. Exact origin checks and private backend tokens define a local boundary. There is no public login, tenant isolation, or complete hosted deployment configuration.

That scope is appropriate to the current experiment. A public rollout would need its own authentication model, concurrent-writer design, and deployment qualification. The website's polished appearance should not obscure those runtime assumptions.

What the Application Helps Me Evaluate

Fieldwork tests whether the framework, language, and database can cooperate on ordinary operations: create a project, move a task, preserve a local edit, reject invalid data, and recover a retried mutation. Its repository documents isolated checks for duplicate IDs, stale versions, cross-site writes, and restart persistence. This article does not add a new benchmark claim to those records.

For a hands-on session, use a local copy to edit a project, briefly disconnect the browser, and inspect how queued work is represented. Return online and observe acceptance or conflict. Then disable motion and navigate the same landing sections. Both exercises test whether the interface remains useful when the ideal path changes.

Continue with ZeeDB and its native Studio for the storage and administration story, or explore the Fieldwork captures and guide. The application gives each custom tool a specific responsibility and makes the integration between them visible.