Coming soon

These features are not in the starter yet. They are listed here so you know what is planned and can decide whether to wait for them or implement them yourself.

Database adapters

The starter currently boots with an in-memory NoopUserRepository. The plan is to add optional adapters for real databases:

• TypeORM — for users who want a full ORM with migrations and decorators.
• Drizzle — for a lightweight, SQL-first query builder.
• Prisma — for schema-first development and generated clients.
• MikroORM — much later, because it adds more concepts and a different mental model.

You can already replace USER_REPOSITORY with your own implementation today; these adapters will be provided as drop-in options later.

Environment variable validation

ConfigModule.forRoot currently loads .env values without validation. The plan is to add an optional Joi schema so missing or invalid values fail at boot time with a clear message instead of later at runtime.

You can add this yourself by installing joi and passing a validationSchema to ConfigModule.forRoot.

Optional JWT authentication

JWT-based auth was removed in favor of session-based auth. Sessions work better for the starter’s default real-time WebSocket pattern and avoid refresh-token complexity. However, some users still prefer JWT, so the plan is to add an optional JWT module that you can enable instead of the default session-based flow.

When this lands, it will be opt-in and will not replace the current session implementation.

AI-friendly development

The starter already relies on strict typing, opinionated patterns, and clear documentation. These qualities work well with AI agents, but the plan is to do more. Future releases will ship an AGENTS.md file alongside the generated project, a set of skills, and extra documentation that help agents produce less slop and generate code that matches the starter’s conventions and quality standards.

Internationalization (i18n)

The plan is to add a lightweight i18n layer for API messages and validation errors:

• Constant code names — the backend returns translation keys (e.g. errors.auth.invalidCredentials) instead of raw strings.
• Argument placeholders — responses can pass structured arguments alongside the code so the frontend can interpolate values.
• Frontend-driven rendering — the frontend receives { code, args }, injects the arguments into the translated string, and displays the localized message.
• Catalog endpoint — the backend will expose an endpoint that serves the full translation catalog so the frontend can load only the languages it needs.

This keeps the backend language-agnostic and lets the frontend own localization, which works well for teams building separate web, mobile, or desktop clients.

Want to contribute?

If any of these features interest you, feel free to open a PR. The roadmap is driven by what the community needs, and contributions are welcome.