Product relationship
Programmer is the separate product for executable sandbox environments. Framework is the Go foundation for the services and systems around them.
| Topic | Nexss Programmer | Nexss Framework | How to choose |
|---|---|---|---|
| Primary purpose | Run code and workflows in controlled sandbox environments | Build services, microservices, and multi-tenant systems | Choose Programmer for controlled execution. Choose Framework for system architecture. |
| Primary runtime layer | An execution environment with sandbox requirements | A Go foundation for applications and systems | Independent products with different technical centres of gravity. |
| Core boundary | The environment where code runs | Application capability, transport, tenant, and data boundaries | Choose the boundary that matches the problem you are solving. |
| Operational focus | Executable workloads and controlled environments | HTTP, NATS, cron, workers, persistence, audit, and deployment building blocks | The products can complement each other in a larger Nexss solution. |
| Connection point | A sandbox workload can expose a controlled execution surface | A Framework service can coordinate the wider product system | Integrate deliberately. Do not treat one product as a replacement for the other. |
Architecture path
Identify the work
Decide whether the challenge is controlled code execution or building a durable product system.
Choose the product
Use Nexss Programmer for executable sandbox environments and Nexss Framework for application and microservice foundations.
Define the boundary
Describe where sandbox, service, tenant, data, and event responsibility meet.
Connect deliberately
Use clear interfaces when a Programmer workload becomes part of a Framework-based system.
Next step
Two products. One deliberate architecture.
We can help identify where Nexss Programmer should run a workload and where Nexss Framework should own the application and service boundary.