Levels of support for different truss usecases

The tool truss can do many things, however different subsets of truss functionality have different levels of support by the team. This document expands on what those levels of support are, and provides examples of actions which fall in each level of support. As development of truss continues, individual use cases may move between the levels of support.

Support Level 1 (yes, definitely supported)

Example: Only edit code in the handlers/

This is the most strongly supported use case of truss. Within the generated code, the only files you are are explicitly meant to edit are the files within the handlers/ folder of a generated codebase.

Support Level 2 (kinda supported)

Example: Create your own main by importing code from svc/

You can create your own main.go file which orchestrates the components of a truss-generated service however you chose. This operation doesn't recieve the same level of support as level 1, but we do try not to break the generated API's used by such external main.go.

Support Level 3 (not supported, we don't recommend this)

Example: Editing generated code outside handlers/, such as code in svc/

The act of modifying generated code outside of handlers/ is explicitly not supported. It is not something that truss prevents you from doing, but if you do, all your changes will be overwritten with no warning or confirmation when you re-run truss on that same service.