# Layr: a full-stack TypeScript framework read from its roadmap

> Layr is a TypeScript full-stack framework whose pitch is to dramatically simplify full-stack development, and the most informative document in the repository is its roadmap: a checklist of what works today, from cross-layer inheritance and remote method invocation to MongoDB storage and React integration, and what does not yet exist. The last push was on 2026-04-30 and the version is 2.0.1.

**layrjs/layr** — Dramatically simplify full‑stack development

- Repository: https://github.com/layrjs/layr
- Website: https://layrjs.com
- Stars: 1,217 · Forks: 34
- Language: TypeScript
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/layrjs-layr

## A roadmap is the most honest description of the framework

Layr's one-line description is that it dramatically simplifies full-stack development, and the repository's most informative file is its roadmap, which is organised as a set of checkboxes across five areas: components, storage, routing, authorizations and integrations.

That structure is unusual and it tells you a lot. Most framework repositories present a feature list of what exists. Layr presents two lists, what is done and what is not, and the second list is long enough that the roadmap is the document to read before you evaluate anything.

The components section shows what the framework considers its core ideas, and six of them are ticked: basic components, controlled attributes, component provision, cross-layer inheritance, remote method invocation and optimized serialization. Three are not: a Weak Identity Map, component subscriptions for realtime updates, and HTTP Caching.

Cross-layer inheritance and remote method invocation are the two names that describe what the framework is trying to be. The repository topics list them among the labels, along with apiless, backend, frontend, full-stack, javascript, orm, database and typescript. An apiless framework with an ORM and remote method invocation is a specific architectural bet: the model layer is shared between client and server, and instead of generating an API surface you call methods across the layer boundary.

The three unticked component items are worth understanding individually, because each names something a user would feel. A Weak Identity Map is about object identity within a session, so that two references to the same row are the same object. Component subscriptions are realtime updates pushed from the server. HTTP Caching is caching responses. None of them is exotic, and their absence tells you the framework is not yet finished in the way a mature one would be.

## Storage is MongoDB only, and the migration story is half built

The storage section of the roadmap is where the limits of the project are clearest, and it is the first place to look if you are evaluating it for real work.

Basic storage with MongoDB is done, along with indexes, and the index support is itemised in useful detail: identifier attributes, regular attributes, compound attributes, referenced components and embedded components. That last pair is the interesting one, because it means the framework's component model maps onto MongoDB's two ways of linking data, a reference to another document or an embedded document inside the parent, and that the ORM understands which one you meant.

Everything else in the storage list is unticked. Automatic migrations have the index part done but default values, renamed components and renamed attributes are not, and custom migrations do not exist at all. Polymorphism is not done. Transactions are not done. There is no sugar to query reverse relationships, and no query subscriptions for realtime updates. And support for more databases, with PostgreSQL, MySQL and DynamoDB named as the intended targets, is not started.

The absence of automatic migrations deserves emphasis. A framework that writes to MongoDB without a migration system means schema changes are manual, and the framework's own component model is the schema. That is workable for a project in its first year and a growing liability after that, and it is a design decision rather than a bug.

The transactions item is the other one with a direct operational consequence. Without transaction support, a write that touches more than one document is not atomic, and code that assumes it is will eventually be wrong in a way that is hard to reproduce.

## Routing and authorizations are the finished parts of the framework

Two sections of the roadmap are short and entirely ticked, and they are the parts of the framework you can rely on being settled.

Routing has basic routing and nested routing, both done. Nested routing is the one that matters, because it is what a real application needs: a route tree rather than a flat list of paths, so that a section of the site can be mounted under a prefix without every handler in it knowing about the prefix.

Authorizations have basic authorizations and role-based authorizations, both done. Role-based access control on the server side, with roles defined in the same component model as the data, is the kind of feature that either exists coherently or does not exist, and having it ticked in the same style as the other items suggests it is a real implementation rather than a stub.

Both of these are the parts that make a framework usable as the backbone of an application, and the fact that they are complete while the storage layer is not suggests a project that got the application shell right and the persistence story only partly right. That is a plausible order of work, and it is also the order that determines who can use it today.

The integrations section is smaller still: React integration and basic AWS integration, both ticked. The React integration is the one a frontend developer would look for first, and AWS covers deployment. Basic is the word to note, since the roadmap does not claim more than a basic integration for either.

## A monorepo of packages, built with lerna and nx

The repository layout is that of a monorepo, and the build tooling in the root manifest tells you how it is put together.

The root `package.json` is named `layr`, is marked private, and carries version 2.0.1. It is a workspace root rather than a published package, and its scripts section contains a single entry, `build:docs`, which runs the docs build in the `docs` directory. The development dependencies are `lerna` at ^6.4.0, `prettier` at ^2.8.2, and a shared configuration package, `@mvila/prettierrc` at ^1.1.2, which is also what the manifest's `prettier` key points at. So the code style of the whole repository comes from one shared config rather than from a per-project one.

Alongside the manifest there is a `lerna.json` and an `nx.json`, which is the combination that indicates a lerna-managed workspace with nx handling task orchestration. That setup is what lets a repository with many packages run builds and tests in dependency order rather than one package at a time.

The directory layout follows the same logic. There is a `packages/` directory for the published packages, a `docs/` directory whose own build is a separate npm project, a `website/` directory, an `examples/` directory with a `v1/` and a `v2/` subdirectory, and an `assets/` directory holding the logo.

The examples split by version is the detail that catches the eye, and it is a useful one. Two example sets, one for the first version of the framework and one for the second, means the examples were rewritten to match the new API rather than patched, and it gives you a way to see what changed between the two major versions of the public surface.

There is also an `.npm-dev-registry.json` file at the root, which is a configuration for a local npm registry. That is a development convenience for publishing test versions of the packages to a local registry rather than to npm, and its presence tells you the packages are consumed by name from a registry rather than vendored.

## What the framework does not do yet, and what that means for a project

The failure modes here are not bugs, they are absences, and an absence in a framework is harder to work around than a bug because you have to build the replacement yourself.

The first is database portability. With MongoDB implemented and PostgreSQL, MySQL and DynamoDB not started, the storage layer is not an abstraction over databases in any meaningful sense, it is a MongoDB layer. A team that has already standardised on PostgreSQL cannot use the storage layer at all, and porting a project later means rewriting the persistence code, which is the part of a codebase that is most expensive to rewrite because the bugs are subtle and the tests are the least likely to cover them.

The second is migrations, covered above, and the third is realtime. Component subscriptions and query subscriptions are both unticked, so a collaborative application, a live dashboard or a chat interface would need something outside the framework. The apiless design, where the client calls server methods directly, is convenient but it does not by itself push changes, and a framework that intends to be the whole stack usually needs to answer that.

The fourth is a subtlety rather than a gap. A Weak Identity Map is not ticked, and identity semantics matter more than they look in an ORM. Without one, two references to the same record are two objects, and code that mutates one and expects the other to see it will behave differently from the same code against a framework that has one. That is a class of bug that does not show up in a unit test of a single method and shows up in a long-lived session.

A final note on the practical state of the project. The repository is not archived and the last push was on 2026-04-30, roughly six months before this reading, so work is happening. There are no GitHub releases, so there is no tag to pin and no changelog entry to read for a version, and the version number in the root manifest, 2.0.1, is the workspace's own number rather than necessarily the version of any published package. The documentation site at layrjs.com/docs is where the API description lives, and it is the version to check against.

## Conclusion

Layr fits a team that wants one TypeScript codebase for the browser and the server with the model shared between them, and it fits an experimenter who wants to try an apiless, ORM-backed approach with an unusually small surface. It does not fit a project that needs PostgreSQL, transactions, automatic migrations or realtime subscriptions today, because the roadmap marks all of those as unfinished. Before you commit, read the roadmap's unchecked boxes rather than its checked ones, and confirm on layrjs.com/docs that the version you pull is the one the documentation describes, since the repository has no GitHub releases to anchor a version to.

## FAQ

### What is Layr?

Layr is a TypeScript full-stack framework whose goal is to dramatically simplify full-stack development, with an apiless design built around shared components, cross-layer inheritance, remote method invocation and an ORM. The documentation is at layrjs.com/docs.

### Which databases does Layr support?

MongoDB is the implemented storage backend, with basic storage and indexes done, including identifier, regular, compound, referenced and embedded attributes. Support for PostgreSQL, MySQL and DynamoDB is listed on the roadmap as not started.

### Does Layr support realtime updates and transactions?

Not yet. The roadmap lists component subscriptions for realtime updates, query subscriptions, transactions and a Weak Identity Map as unfinished items, along with automatic migrations beyond indexes and custom migrations.

### How is the Layr repository structured?

It is a monorepo with a `packages/` directory for the published packages, a `docs/` directory with its own build, a `website/` directory, and an `examples/` directory split into `v1/` and `v2/` sets. The root uses lerna and nx, with a shared prettier configuration from `@mvila/prettierrc`.

## Sources

- [Issues](https://github.com/layrjs/layr/issues)
- [layrjs/layr on GitHub](https://github.com/layrjs/layr)
- [License: MIT](https://github.com/layrjs/layr/blob/master/LICENSE)
- [Project website](https://layrjs.com)
- [README](https://github.com/layrjs/layr/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/layrjs-layr