Feature Request: Support for Serverless Backends

[pclements12]

It would be nice if the RouteGenerator was a more generic interface that could support multiple backend designs besides a single Server template file. This would open up the TSOA library to be used by a lot more users and make the process for adding a new generator a little more clear.

Sorting

• I'm submitting a ...

  • [ ] bug report
  • [x] feature request
  • [ ] support request

Expected Behavior

It would be possible to supply a RouteGenerator module to the tsoa config that implements the RouteGenerator as an interface or an abstract base class. The RouteGenerator would only have a single method as an entry, but it would not be opinionated about the way that that backend would produce it's routes (or even other related resources such as CDK/Terraform/CloudFormation files to support that particular backend)

Current Behavior

Currently the RouteGenerator pattern takes in a single template file and creates a single routes file. For backends that require additional templating, for example a handler file per route, it's impossible to implement a template that satisfies this needs in the current architecture.

Detailed Description

The determination of middleware type and template information could be moved into an implementing class of the generic RouteGenerator. When routes are generated, the RouteGenerator would be specified by the tsoa.json.

This could potentially still be backwards compatible by allowing a base route config that can be extended and provided as a constructor arg to the RouteGenerator.

A simple example of what this abstract base class might look like:

export abstract class AbstractRouteGenerator<Config extends ExtendedRoutesConfig> {
  constructor(protected readonly metadata: Tsoa.Metadata, protected readonly options: Config) {}

  /**
   * This is the entrypoint for a generator to create a custom set of routes
   */
  public abstract GenerateCustomRoutes(): Promise<void>;

In a serverless application hosted on AWS Lambda, this could be implemented to generate all of the handler files with the appropriate validations and meeting the models of the spec, and the CDK scripts for the API Gateway and Lambda stack that would be needed to support the HTTP/Route parts of the spec.

In this instance the route generator would need to produce a handler file for each route and possibly a "stack" file that creates and returns the CDK resources that would need to be deployed.

[github-actions[bot]]

Hello there pclements12 👋

Thank you for opening your very first issue in this project.

We will try to get back to you as soon as we can.👀

[pclements12]

Also, I would be willing to contribute to this effort. I created a POC that would move the existing single file generator pattern to an implementation of the AbstractRouteGenerator and confirmed that all of the tests still pass with this approach.