For backend and full-stack developers
JoinedWorkz lets you model persistence, APIs, controllers and UI flows in a textual DSL and generate the scaffolding for your services. You keep full control over business logic, tests and how you work with Git, builds and frameworks.
Developers are used to tools that overreach: they dictate project layout, hide logic behind frameworks, or introduce lock-in that is hard to undo later. JoinedWorkz explicitly tries to avoid that.
Generated code is regular project code in your repositories. It can be checked in, reviewed, refactored, debugged and extended using your normal IDE and tools. There is no central runtime that you must rely on at production time.
If you ever stop using a generator, the existing code keeps working. You can take over the generated code manually or migrate it gradually. JoinedWorkz is designed so that projects can outlive the generator.
The DSL is text-based and lives next to your code. You see exactly what changes: DSL diffs, generated code diffs, everything in the same pull requests. No proprietary project files, no special VCS tooling.
JoinedWorkz generates the boring parts: persistence mappings, repositories, controllers, API contracts and basic UI navigation. The actual behavior of your system stays hand-written and under your control.
In short: JoinedWorkz standardizes the repetitive, architecture-heavy parts – not the domain-specific logic where your decisions matter most.
JoinedWorkz does not try to replace your framework or IDE. Instead, it adds a few specific artifacts to your repositories and build.
Files such as *.cmn for domain and persistence, profile files for platform mappings
and, where used, UX-related model files for navigation, pages and state.
These files are small and focused. You can edit them in the JoinedWorkz studio or in a text editor.
Code for persistence, APIs, controllers, mappers and UI routing is generated from the model for the platforms you use – for example Java frameworks like Spring or Vert.x, or frontend stacks such as Angular or Quasar.
The output is meant to be readable and aligned with your usual style.
Services, domain logic, tests, configuration and UI components stay entirely in your hands. You decide where to put boundaries, how to structure modules and how far you want to go with generation.
As a developer, you usually see JoinedWorkz in a few concrete workflows.
When a new platform or framework is introduced (for example a different Java stack or a new frontend), you add or extend generators for that platform. The model stays the same; only the generated artifacts change.
As a developer, you get new scaffolding aligned with the existing model instead of re-inventing everything.
For stacks such as Quasar or Angular, JoinedWorkz can model basic navigation and page structure and generate routing and simple views. You still implement UI components and state management as usual, but you get a consistent starting point from the model.
JoinedWorkz is designed to be a thin layer around tools you already use, not a replacement for them.
Models and generated code live in Git repositories, branch and merge like any other code and are reviewed via your usual pull request process. There is no central server that you depend on at development time.
A Maven plugin runs generation as part of your build. Generators are published as Maven modules, so you can pin versions, update them when needed and run builds on CI without extra scripts.
The core model is platform-lean. Generators map it to specific frameworks and stacks. This keeps your model stable even if you swap out parts of your technology stack over time.
The generator controls the structure of certain layers (persistence, APIs, controllers, integration points), but it does not control your domain logic. You can still refactor, add extension points and, if needed, take over generated code manually.
Yes – generated code is meant to be readable and refactorable. For recurring refactorings, it is usually better to update the generator or model instead of editing each generated file individually.
Generators are versioned like any other Maven dependency. You decide when to upgrade. Diffs show you exactly what changes in the generated code, so you can assess the impact before merging.
The DSL is focused on the concepts you already work with: entities, relationships, APIs, parameters, basic UI navigation. Most developers get productive after seeing a few concrete examples.
Yes. Generation runs as part of your builds via Maven. As long as your CI/CD can run your usual builds, it can run the generators too. There is no extra service to deploy.
You add generators for that stack (or extend existing ones). The model remains the same, and you get new generated scaffolding that follows the same rules as your existing services.
If your organization is exploring JoinedWorkz, you can usually start hands-on in a small scope without changing your entire way of working.
The goal is not to automate everything from day one, but to relieve you from repetitive work while keeping full visibility and control.
If you prefer to judge tools by looking at actual code, the best next step is to run the quickstart and inspect the generated scaffolding. From there, you can decide where JoinedWorkz would help in your own services.
Not sure yet? - Download the PDF overview
