A community module registry
A module is a full-stack feature: routes, backend logic and a database model, declared in one manifest. Install one with a single command, no account required, or build your own.
Module
@alice/team-workspace
app/team/page.tsx
Frontend route
backend/module_alice_team_workspace/
Backend router
team_workspace
Database collection
$ nextapi add @alice/team-workspace
Added '@alice/team-workspace'@1.2.0 (pending)
$ nextapi sync
Resolved 1 module, 0 conflicts
Verified before anything was written
The problem
Boilerplate solves the foundation. It never solved the features. Every team still rebuilds the same workspace, the same billing flow, the same profile page, and every copy-paste starts drifting the moment it lands.
NextAPI treats a feature as something you install, verify and version, not something you re-derive.
01
Every module ships a module.json declaring its routes, backend router, database model, env vars and dependencies. add stages it locally without touching your app, and needs no account.
02
Dependency order is sorted and checked for cycles. Every function a module calls on another is checked against what that module actually provides. Collisions are caught here, not at runtime.
03
The backend lands as its own package, the route in your app directory, the RBAC entry merged into your config. Hand-edited files are detected and left alone. It is readable code next to yours.
{"id": "@alice/team-workspace","version": "1.2.0",+"frontend": { "routes": [{ "path": "/team" }] },+"backend": {+"router": { "module": "backend/router.py" },+"collection": "team_workspace"},+"functions": { "uses": ["auth.get_current_user"] },"implementationNotes": "Every item is read live..."}
The registry is strict so your app does not have to be. Everything below is checked, linked or recorded by the tooling, not left to convention.
Dependency order is sorted and checked for cycles. Every function a module calls is checked against what the other module provides. Route, package and collection collisions are refused up front, so an install is never half applied.
A module can adopt a collection you already have. NextAPI samples real documents to catch schema drift before linking, and fields that do not match are demoted instead of guessed at.
A module can call a function another module provides. The registry checks that the capability exists before either one installs.
module
@alice/support-chat
uses profile.get_display_name
module
profile-page
provides get_display_name
Capability resolved before either module installs
Versions are immutable and follow semver. Yank a bad release without breaking anyone who has it. Modules can keep several majors side by side, and stored data has its own schema version with required normalizers.
Overwriting an existing route needs an explicit acknowledgment in the manifest, and nextapi rollback puts it back. Files you have edited by hand since the last sync are detected and left alone.
Modules plug into the auth, RBAC and database layer NextAPI core already ships, on FastAPI and Next.js. There is no runtime dependency on the registry after install: it is your code.
Describe a module and the AI Builder writes the whole thing: manifest, backend, page and preview data. What sets it apart is the discipline it works with.
It loads design standards and section patterns before laying out a page, and looks up a library's real docs instead of guessing its API.
Imports that the live preview or another host cannot resolve are rejected on the spot, with the fix in the message.
Contrast, reduced motion, animated layout properties and missing plugin registration are linted on every file it writes.
The same schema, capability and syntax checks that gate a publish run after every change, so it fixes problems before you see them.
Pick a style before you generate. It changes what gets built, not just how it moves, and the rules underneath do not change. Scroll to walk through them, or pick one.
Subtle style: 150-300 ms, power2.out, no scroll effects.
Start from a working template and edit in a real code editor. TypeScript, JavaScript, JSON and Python are understood, with mistakes marked on the exact line as you go.
Open the BuilderPublish a private module and share it with specific people by username. They can view and install it, and nothing else.
shared with @maya, @devon
Fork any public module and make it yours. The registry records the original author and shows it on the fork's page. The fork cannot remove it.
Forked from @alice/team-list v0.1.0
original by @alice
A module is source code plus a manifest, never a black box. Publishing one is a normal git-style workflow, not a form buried behind an approval queue somewhere.
nextapi validate checks the schema, the capabilities, and the file paths before anything is accepted. If it doesn't pass cleanly here, it wouldn't install cleanly for anyone downstream.
Every module in the registry exists because someone building a real app needed exactly that feature, then published what they had to build anyway for the next person.
Yes, for now. Every module assumes NextAPI core's conventions: the FastAPI backend structure, the RBAC route config, and the shared auth/database layer. That coupling is what lets sync wire a module into your routes and RBAC automatically instead of asking you to do it by hand.
The module's files are committed into your project like anything else, split into predictable regions marked with generated comment blocks. You can edit them immediately. Nothing keeps running against a remote package after install.
Sync checks for route collisions, backend package name collisions, and database collection name collisions before writing any files. If two modules conflict, the install is refused up front rather than partially applied.
Nothing about the output is different. The Builder writes the same module.json, the same FastAPI router, the same frontend route a human would, and it runs through the exact same validation before it's allowed to publish. The only difference is who typed it.
No. Browsing, searching, and installing with nextapi add and nextapi sync are completely public and need no login. An account and a token are only required to publish your own modules.
Every publish is re-validated server-side against the same schema, capability, and namespacing checks the CLI runs locally, and any module can be reported and reviewed. This reduces risk, it doesn't eliminate it. Read what a module does before installing it, same as with any package.
$ nextapi add @alice/team-workspace