reSolve is a full stack CQRS and event sourcing framework for Node

Events as the source of truth, read models derived from them

reSolve is described as a full stack functional JavaScript framework, and the four capabilities it lists are the whole architecture. Command and Query sides are independent, following the CQRS pattern. DDD Aggregate support is there so that invariants can live in the domain object rather than in the application layer. Event sourcing means using events as a source of truth and calculating read models from them.

That last one is the load-bearing decision. State is not read from a table and then updated; it is reconstructed by replaying what happened. The read models, the shapes a query actually returns, are derived from the event stream, which means the same event data can feed several different views.

The fourth bullet is the reason this is called a full stack framework. It integrates with React and Redux, so the client store is not a separate invention that has to be kept in step with the server. The server's read models and the browser's store are derived from the same events, which removes a category of drift bugs at the cost of a lot of machinery.

The project links its concept references to the usual sources, the CQRS and DDD Aggregate articles by Martin Fowler and the event sourcing pattern description, and the site is at reimagined.github.io/resolve.

npx create-resolve-app gives you a running app on port 3000

The getting started path is a generator, and the requirement is NodeJS 14.17 or higher. The easiest route uses npx:

npx create-resolve-app my-awesome-app
cd my-awesome-app
npm run dev

The application then runs at http://localhost:3000/. The generator is the create-resolve-app package inside the repository's core packages directory, so the scaffold matches the framework version you are about to use rather than a separately published template.

If you prefer a global install, the README notes that installing a package globally may require administrative privileges:

npm i -g create-resolve-app
create-resolve-app my-awesome-app
cd my-awesome-app
npm run dev

and yarn users have their own variant:

yarn create resolve-app my-awesome-app
cd my-awesome-app
yarn run dev

Three ways to start the same project is a small sign of how the project has been maintained, and it is worth noting that the framework version on npm is old enough that the generator and the packages it pulls in deserve the same scrutiny as any other dependency.

The -e flag copies a whole example into your project

The generator is also the way to read working code. The repository ships several code examples under the examples directory, in both JavaScript and TypeScript flavours, and the README tells you to add code from these examples into your projects.

To see what is available, the create-resolve-app -h command lists them. To create a new application that contains a specific example, you pass the example name with the -e flag. For the shopping-list example:

npx create-resolve-app resolve-example -e shopping-list

This is a better learning path than reading the docs top to bottom, because the example arrives as a project that already runs. A shopping list is a small domain, which is exactly what you want when you are trying to see how commands, events, aggregates and read models fit together, and the examples directory holds the JavaScript and TypeScript variants side by side, so you can compare the two styles.

The tutorial directory in the repository is the other entry point, and the README points new users at the step-by-step tutorial in the docs section.

A monorepo where packages, templates and tests share one yarn workspace

The repository is a monorepo, and the root package.json shows how the pieces relate. The root package is @resolve-js/resolve at version 0.34.3 and is marked private, so it never reaches npm; the publishable code lives in the packages directory, and the workspaces list pulls in the examples, the tutorial, the templates for JavaScript and TypeScript, the internal tooling, the benchmarks, the tests, the website and the functional tests.

The scripts show the shape of the development loop. Linting runs eslint over JavaScript, JSX, TypeScript and TSX with separate targets per language, and prettier formats the same set of files. The build step is called babel-compile, and packages are assembled by a build-packages script. Tests run through workspaces, so each package has its own test script, with dedicated targets for coverage, integration, and end to end runs scoped to the tutorial, the templates and the examples.

That last detail is the interesting one. There are functional-tests and a functional-tests/app workspace, and the end to end targets are filtered to the tutorial, the templates and the examples, which means the shipped applications are exercised as applications rather than only as unit-tested packages.

The other top-level directories, benchmarks, templates, website, docs and tutorial, confirm that this repository is a product with a documentation site, not a single library.

The workspace layout decides which code is published

The workspace configuration is the mechanism that keeps the monorepo honest, and it is worth reading as a build description:

  "name": "@resolve-js/resolve",
  "version": "0.34.3",
  "private": true,
  "repository": "https://github.com/reimagined/resolve.git",
  "license": "MIT",

Every entry under workspaces is a package that shares the root toolchain, from the packages directory through the examples, the tutorial, the templates, the internal tooling, the benchmarks, the tests, the website and the two functional test workspaces. Because the root is private and versioned as one number, the whole framework moves in one version step, which is the usual reason a project accepts a monorepo over separate repositories.

The cost of that choice is that the framework is distributed as a set of packages that are expected to be used together. The coupling between the server, the event store and the client store is the design, not an accident, and it is the reason the project calls itself full stack. Adopting one half of it is not a documented path.

The repository also keeps a HISTORY.md alongside a CHANGELOG.md, plus a .github_changelog_generator directory and a validate-lock-file.js script, which suggests release notes are generated from commit history and the lock file is checked in CI.

The published version is from 2022 while the repository keeps moving

This is the number to look at before adopting the framework. The release list ends at V0.34.3, tagged on 2022-07-29, preceded by V0.34.2 and V0.34.1 in April 2022. The package version in the root manifest matches that release. The last push to the repository, however, was on 2026-08-25, and the default branch is dev rather than master.

So the code is being worked on while the published npm version is several years old. For a framework, that gap has two consequences. The version you install from npm is not the version in the repository, and the repository's own tooling, including the create-resolve-app generator that lives in packages/core/create-resolve-app, is at a different point from what npm serves.

Whether that matters depends on your plans. If you intend to use the published packages, you are adopting a 2022 release. If you intend to work from the repository, you are adopting a dev branch whose packages have to be built and published by you, which is a different kind of project.

The licence is MIT, with LICENSE.md in the repository root. Support is community based, through a Stack Overflow tag, GitHub issues and social accounts, and the documentation site lives at reimagined.github.io/resolve.

Where reSolve is the wrong tool

Event sourcing with a derived read model is a commitment, not a default. Every state change becomes an event that has to be stored, and every read model has to be rebuilt when the shape of the queries changes. The framework does not remove that cost, it gives you a place to put it.

For a small application with a straightforward CRUD surface, the whole stack is overhead. You would be running an event store, a command side and a query side, a React and Redux client, and a set of aggregate classes, to end up with the same rows you would have queried directly. The README's own prerequisites tell you this, in a way: Node 14.17 or higher, a generator, a workspace install, and a tutorial to work through before the first real feature.

The alternative worth weighing is a backend-only event store, with the client fetching a ready-made view over HTTP and keeping it in whatever state library you already use. The difference in approach is where the derivation happens: reSolve shares the event model across the server and the browser and lets the framework drive the Redux store, while a backend-only approach keeps the derivation on the server and treats the client as a consumer of views.

Choose reSolve when that shared model is the point, and when the team is prepared to operate an event store. Otherwise the framework is a large amount of architecture for a small amount of application.

Editorial conclusion

Adopt reSolve if your team is building an event sourced Node application and wants the read side, the Redux store and the server to share one model of the domain, because that coupling is the framework's reason to exist. Do not adopt it for a straightforward CRUD service, where the command and query split, the event store and the React and Redux assumptions cost more than they return. Before you commit, check which published version you would actually install, since the last tagged release is 0.34.3 from 2022 while the repository has been pushed more recently, and read the step-by-step tutorial in the docs directory to see how much of the framework a simple use case pulls in.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. reimagined/resolve on GitHub
5. Releases