github.com/ManabuSeki/goa-v1@v1.4.3/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.