Product relationship
Programmer is the separate product for runnable sandbox environments. Framework is the Go foundation for the services and systems around them.
| Topic | Nexss Programmer | Nexss Framework | How to choose |
|---|---|---|---|
| Primary purpose | Execute code and workflows in runnable sandbox environments | Build services, microservices, and multi-tenant systems | Choose Programmer for controlled execution; choose Framework for system architecture. |
| Primary runtime | TypeScript product with sandboxed execution concerns | Go application and systems foundation | They are independent products with different technical centres of gravity. |
| Core boundary | The environment where code runs | The application capability, transport, tenant, and data boundary | Use the boundary that matches the problem you are solving. |
| Operational concern | Runnable workloads and controlled environments | HTTP, NATS, cron, workers, persistence, audit, and deployment building blocks | They can complement one another in a larger Nexss solution. |
| How they connect | A sandboxed workload can provide a controlled execution surface | A Framework service can coordinate the wider product system around it | Integrate deliberately; do not treat one as a replacement for the other. |
Architecture path
Identify the job
Decide whether the challenge is controlled code execution or building a durable product system.
Choose the product
Use Nexss Programmer for runnable sandbox environments; use Nexss Framework for application and microservice foundations.
Define the boundary
Describe where the sandbox, service, tenant, data, and event responsibilities meet.
Connect deliberately
Use clear interfaces when a Programmer workload becomes part of a Framework-based system.
Next evidence
Two products. One deliberate architecture.
We can help identify where Nexss Programmer should execute a workload and where Nexss Framework should own the application and service boundary.