NODERYX
FRAMEWORK v0.7.1

GETTING STARTED

BUILDING

PRODUCTION

DEVICES

REFERENCE

NODERYX / DOCS / WHAT COMES NEXT
WHAT COMES NEXT

Future roadmap

The direction of Noderyx: a smaller distance between an idea and a dependable product on every screen.

01

Now — strengthen the core

The current focus is depth rather than surface area: stability, documentation, testing, database consistency, security defaults, and the everyday developer experience.

  • More complete documentation for every subsystem, with runnable examples.
  • Wider test coverage across the router, compiler, models, and security layer.
  • Consistent behavior across MySQL, PostgreSQL, and MongoDB.
  • Clearer error messages that name the likely cause and the next command to run.
CURRENT FOCUS
STABLE CORE / CLEAR CONVENTIONS
02

Next — expand the ecosystem

Once the core is boring in the best sense, the useful work moves outward: making it easy to share and reuse what people build.

  • Package discovery and a predictable convention for publishing extensions.
  • Reusable application modules—authentication, admin, billing—as packages rather than framework code.
  • Deployment adapters for the platforms people actually use.
  • Observability integrations: structured logs, traces, and health signals.
  • Community examples that show whole applications, not snippets.
PLANNED DIRECTION
PACKAGES / DEPLOYMENT / TOOLING
03

Future — one product system

The long-term goal is that shipping to a browser, an API client, and a phone stays one codebase and one mental model.

  • Deeper native compilation, covering more of the Cool.css surface.
  • Shared design primitives that translate faithfully across web and device.
  • AI-assisted workflows that stay inside your architecture, not around it.
  • Seamless web-to-device delivery while the source stays readable.
LONG TERM
WEB → API → AI → NATIVE
NOTE

Long-term direction; priorities may evolve as real applications reveal what actually matters.

04

What will not change

Some commitments are not roadmap items—they are constraints on every future item.

  • Application code stays yours: updates change the framework dependency, never your files.
  • Security defaults stay on, and turning one off is always an explicit decision.
  • Generated code stays readable—no artefact you are not allowed to understand.
  • One project shape, so a Noderyx codebase remains familiar to anyone who has seen another.
05

How to influence it

The roadmap follows real applications. The most useful contribution is a concrete account of what got in your way.

  • Report the exact command, the expected result, and what happened instead.
  • Share the shape of the application you are building—constraints matter more than feature names.
  • Publish a package: the ecosystem grows faster than the core can.
  • Do not report security issues in a public tracker; the framework has not had an external audit.