BRMW runs the whole ER modelling course in a browser tab

Three models derived from one conceptual diagram

The workflow is the textbook one, and staying close to that is the point. You draw a conceptual model, convert it to a logical model, then generate SQL. A separate NoSQL module takes the same conceptual model and produces collections, embedded documents and references instead of tables.

The conceptual notation is Peter Chen's, with the Heuser conventions common in Brazilian database courses: entities, relationships, attributes, keys, cardinalities, weak entities, ISA hierarchies and associative entities. The logical side adds tables, columns, primary and foreign keys, and views with query expressions.

Conversion between the three is automatic but not blind. The README is explicit that ambiguous cases produce interactive choices: which ISA strategy to use, where an attribute belongs, and whether a relationship becomes a reference or an embedded document. Those questions are where most of the learning value sits, and they are exactly the questions a real migration forces you to answer.

No server means no file, and that is the real limitation

Everything runs in the browser. There is no server, no account, and models stay on your machine, persisted in the browser's localStorage.

That has two consequences. The first is privacy and simplicity: nothing is uploaded, nothing needs hosting, a classroom full of students can run it without provisioning. The second is that the model has no file on disk. The README says it plainly, clearing site data erases them.

So there is no export to a repository, no diff, no pull request review of a schema, and no way to share a model other than sending a browser state or moving to the hosted version. For a schema that will outlive a semester, that is a real ceiling, and it is a design decision rather than a missing feature.

The project is explicit about the alternative it offers: a hosted version with accounts, cloud storage and sharing, at app.brmodeloweb.com. That is a separate product from this repository, which stays free and self contained.

Running it locally needs Node 24 and pnpm 10

The manifest pins the toolchain in its engines field, so a mismatched local setup is refused rather than silently degraded:

"engines": {
  "node": "24.x",
  "pnpm": "10.x"
}

The README recommends installing Node through nvm or n and asks for an editor with EditorConfig support, since an .editorconfig file is part of the repository. The two commands to get a running app are short:

pnpm install
pnpm run:fe

The dev server then serves http://localhost:9000. The build output goes into app/dist, and the test script runs Jest with coverage.

There is a Dockerfile as well, based on node:24-alpine, exposing port 9000 and starting the same development server through `pnpm run:fe`. That image is a convenience for a container, not a production image, since the command it runs is the dev server.

JointJS shapes split by notation, one folder per screen

The canvas is JointJS, with @joint/core at ^4.3.3 as the open source package. The custom editor widgets live in app/editor/, and the shape definitions are separated by notation in app/joint/, one set each for conceptual, logical and NoSQL, plus links and notes.

The React side is organised as one folder per screen under app/react/pages/, covering workspace, conceptual, logic and nosql. Each page splits into a PageWrapper that wires routing and services, and a Page that is presentational, which keeps the routing concern out of the rendering code.

The conversion engines sit next to their editors, as pages/logic/conversor.js and pages/nosql/conversor.js. The filename is a Portuguese word, which fits a project maintained by Brazilian contributors and shipped with an English and Brazilian Portuguese interface.

Modern React stack, two versions behind in the repository

The frontend stack is current: React 19 and ReactDOM at ^19.2.0, React Router 7 via react-router-dom ^7.15.1, styled-components ^6.3.5, react-i18next with a browser language detector, and Radix UI for dialogs. Other runtime dependencies include Font Awesome 7, hotkeys-js and sortablejs.

One oddity is bootstrap at ^3.4.1 as a runtime dependency alongside styled-components. This CSS framework is listed alongside styled-components in a React 19 project. If you adopt this code, that is a cleanup item, not a design choice to preserve.

Build tooling is Webpack 5 with Babel and Sass, and Jest with Testing Library for tests, including a __mocks__/ directory at the repository root.

Where it is the wrong tool

It is wrong for any schema that needs review or history, for the reason above: no file, no version control, no diff. It is also wrong for live production change, since generating SQL is a manual step you then apply by hand and nothing checks the result against a running database.

The dialect question is worth checking against your target. The README says SQL generation for the logical model without naming a set of supported dialects, so assume you will need to read the generated DDL before running it.

For a document store, the NoSQL module covers collections, embedded documents and references, which is enough to teach the modelling vocabulary but not to reason about sharding, indexes or consistency. And for anyone outside the Brazilian course tradition, the Heuser conventions are not the only common notation, so the shapes on screen may not match what your syllabus teaches.

Licence and release history

The code is released under the Apache 2.0 license, stated in both the LICENSE file and the package manifest, which makes it safe to modify and redistribute with attribution.

Development is current. The last push was on 2026-10-13, days after the v2.0.0 release on 2026-09-10. Before that, releases ran at 0.3.x in April 2025, so the jump from 0.3.3 to 2.0.0 marks a deliberate break in the versioning scheme rather than an incremental bump, and the README does not document a migration path between the two lines.

The repository also carries a CLAUDE.md file alongside CODE_OF_CONDUCT.md, the latter of which the README asks contributors to read before opening an issue.

Editorial conclusion

Adopt BRMW for teaching database modelling, for sketching a schema before anyone writes DDL, or for comparing a relational and a document design from the same conceptual model. Do not adopt it as the system of record for a production schema, since clearing site data deletes the model and there is no file format to check into a repository. If you need collaboration, the hosted product at app.brmodeloweb.com is the part of this project that adds accounts and cloud storage.

Frequently asked questions

Official sources

1. brmodeloweb/brmodelo-app on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases