github.com/goldeneggg/goa@v1.3.1/roadmap.md (about) 1 # goa Roadmap 2 3 This document summarizes the areas of focus for the next release (v2). These cover improvements and 4 new features that introduce non-backwards compatible changes. 5 6 ## Breakout the Context 7 8 The generated context data structure contains both the request and response state. While this makes 9 it convenient to write controller code it does not make sense to pass these objects all the way down 10 in all layers. It also creates hidden dependencies. 11 12 The proposal is to break up the generated context into two data structures, one that contains the 13 request state and the other the response state. Concretely today the following design: 14 15 ```go 16 Action("update", func() { 17 Routing( 18 PATCH("/:bottleID"), 19 ) 20 Params(func() { 21 Param("bottleID", Integer) 22 }) 23 Payload(BottlePayload) 24 Response(NoContent) 25 Response(NotFound) 26 }) 27 ``` 28 29 produces the following context data structure: 30 31 ```go 32 // UpdateBottleContext provides the bottle update action context. 33 type UpdateBottleContext struct { 34 context.Context 35 *goa.ResponseData 36 *goa.RequestData 37 AccountID int 38 BottleID int 39 Payload *UpdateBottlePayload 40 service *goa.Service 41 } 42 ``` 43 44 This proposal would break it down into: 45 46 ```go 47 // UpdateBottleRequest provides the bottle update action request context. 48 type UpdateBottleContext struct { 49 *goa.RequestData 50 AccountID int 51 BottleID int 52 Payload *UpdateBottlePayload 53 } 54 55 // UpdateBottleResponse provides the bottle update action response context. 56 type UpdateBottleResponse struct { 57 *goa.ResponseData 58 service *goa.Service 59 } 60 ``` 61 62 The response functions would move from the `UpdateBottleContext` struct to the 63 `UpdateBottleResponse` struct. 64 65 Both the response and request state structs would be given to the controller action function. Today 66 the design above generates: 67 68 ```go 69 Update(*UpdateBottleContext) error 70 ``` 71 72 Under this proposal the generated code would be: 73 74 ```go 75 Update(ctx context.Context, resp *UpdateBottleResponse, req *UpdateBottleRequest) error 76 ``` 77 78 ### Error Handling Improvements 79 80 Move from a model using structs to implement goa errors and check for them to a model using checking 81 for behavior. 82 83 Consider changing the goa request handler signature from: 84 85 ```go 86 func (context.Context, http.ResponseWriter, *http.Request) error 87 ``` 88 89 to the standard: 90 91 ```go 92 func (context.Context, http.ResponseWriter, *http.Request) 93 ``` 94 95 And keep the error in the response struct instead. This means tweaking how error handling is done so 96 that the error handler middleware knows where to look for errors. 97 98 ## Code Generation Improvements 99 100 ### Generator Hooks 101 102 The first planned improvement made to code generation is the ability for arbitrary plugins to hook 103 into the generated code of another generator. The main scenario that this should enable is the 104 ability to inject code in the built-in generator outputs (in particular `gen_app`). This would make 105 it possible to move the security and CORS generation in plugins and help keep the main generator 106 streamlined. Details on how this is enabled TBD. One possibility is to cater specifically to the use 107 case above and have the `gen_app` generator expose explicit hooks. Would be nice to come up with a 108 more generic approach though. 109 110 ### Easier Plugin Use 111 112 Make it easier to invoke plugins on the command line. One possibility could be to have a hosted plugin 113 registry that goagen could look up where plugins could register with a simple moniker. This registry 114 could also provide discoverability of plugins (via something like `goagen plugins`). The registry 115 would only contain metadata (moniker, description, author, last update data etc.) and point to the 116 actual plugin package. 117 118 ### Intermediary Representation 119 120 Generators start from the design data structures then massage that data into a shape suitable for 121 code generation. Today this is done in a ad-hoc way - each generator having its own strategy. For 122 example the `gen_app` generator uses `Template` data structures except for test code generation that 123 use a different kind of structs. Other generators rely on functions called at generation time to 124 perform the transformations which makes it hard to follow. 125 126 The proposal is to implement a standard strategy of first creating explicit structs representing the 127 intermediary representation used by the code generation templates. This would help clarify what the 128 templates expect and keep that up-to-date as the definitions evolve. This should be done in a way 129 that doesn't force generators to use it (some simple generators may not have a need for such a IR) 130 but it should encourage it. For example there could be an additional optional interface that 131 generators could implement that would get called by the generation engine. 132 133 ## Cleanup Type System 134 135 Move `DateTime` and `UUID` to formats on the `String` type. This is to keep the set of basic types 136 small and remain consistent with how `Integer` support formats for various underlying Go data types 137 (see below). This also will allow removing a lot of cruft that supporting these types introduced. 138 From the need to "alias" them to string in code generators to the special cases they introduce with 139 gopherjs support. 140 141 ## Protobuf / gRPC 142 143 Look into generating .proto files from the design and invoke `protoc` on them during code 144 generation. Integrate the generated code with the generated data structures. 145 146 This also requires the ability to specify the bit length of numerical values. The proposal here 147 would be to add support for the `Format` DSL to the `Integer` and `Number` primitive types. The 148 format would indicate bitness and whether the generated integer should be signed. 149 150 ## Client Improvements 151 152 Try to remove the signers from the client package and instead make it possible to integrate with 3rd 153 party client packages. Make the client function generate http.Request to enable that integration.