Has anyone looked into OpenAPI/Swagger with cdk/sst ? Feels like we should have all the information available to produce an openapi spec for our

sst.Api

constructs

@Peter Hausken looked into this a bit, apparently aws provides a way to return an openapi specification from an API

Thanks @Ross Coundon and @thdxr I’ll follow along in github 🙂

Very Cool, thanks @Peter Hausken 😄

People just replies with links these days 😂 .

Sorry, guilty! I usually try to provide some context but was multitasking (and failing)

Hahaha kidding.

Replying with another link, I POC'd this out, tsoa (mentioned in the ticket) supports deep merging, so if you use the APIGateway schema as the base, and the decorator annotation for the responses etc. it seems to work out quite nicely https://github.com/simonireilly/poc-openapi

Great POC @Simon Reilly! I've been tackling this for quite a while before but couldn't wrap my head around combining SST and Tsoa. So much goodness

@Simon Reilly I saw your POC, that’s amazing! what if we also used tsoa to generates the routes in MyStack.ts and to link the app.ts endpoints with the controllers?

Hi guys! Thanks @Simon Reilly for a great POC. I'm wondering if anyone has succeeded in: • generating stack routes with it (as @João Pedro mentioned) • validating against the spec in runtime

I think currently because tsoa generates the verifying middlewares we would need to lean into that frameworks adapter patter ( it has KOA and express adapters) and write a apigateway adapter. That's not something I'm up for myself, but it seems like the logical way to get runtime verification

I'll keep on experimenting then 🙂 . Feels like we're quite close to a "holy grail" setup with SST now. Having a proper generated and runtime-validated OpenAPI spec in SST is a very desired evolution of the setup. In our previous project in serverless, we used to generate JSON schemas from our models and validate them with ajv directly in lambdas, however that was only applicable to the body, neither helpful with query and path params, nor with generated interactive docs.

It's a nice idea to have, but it's a case that apigateway already supports schema validation. So for me, I would like to see:

routes: {
  'GET v1/items/{itemID}': {
    function: sst.Function('src/v1'),
    schema: {
      // Open API here, when deployed, we
      // update the apigateway integration
      // to validate this
    }
  }
}

Then my lambdas can just do business logic

Good idea. I haven't yet evaluated the quality of ApiGw support for OpenAPI, but I will also try that out. I did try with JSON schema though, and unfortunately we had to move away from ApiGw schema validation to lambda in-code validation with ajv because of poor quality and lack of control over that. It was returning super cryptic validation messages in

$context.error.*validationErrorString*

, for example when property was of a union type, the whole error message for the body was like "Can't match schema {0} or {1}" without stating anything useful. Also, there are a couple features of TSOA that would be very useful when parsing stuff, such as:

noImplicitAdditionalProperties?: 'throw-on-extras' | 'silently-remove-extras' | 'ignore';

that we'd miss when only validating on ApiGw. I'll be sure to let you guys know if I manage to come up with anything useful. In the meantime we can subscribe the feature request in TSOA directly :)

@Maciej Gościński I am adding apigateway v2 proxy event support to TSOA, then I think a follow-up PR to put a thin wrapper around that and map the routes from the SST API routes definition would be quite straight forward 😉 https://github.com/simonireilly/tsoa/pull/1

Sincere thanks for being so actively helpful! 👏

I have put together a full proposal for tsoa, if you have any comments about the proposed API that would be awesome to add here GitHub.com/lukeautry/tsoa/issues/1139

@Simon Reilly meanwhile - you can use the

serverless-http

npm package - that will give you the ability to generate routes for express.js that you can route in a single lambda

If I'm reading this thread correctly, I think it will do what I want too... I have a 3rd party API to integrate with and I want to make a stub version which I can use for local dev and testing (happy path and setup failures)... they provide me with several swagger json files (one for each concept, like Customers, Tickets) which I combine into one json file, then I use openapi-generator to generate a nodejs express app... I'm trying to then convert that into an SST application. I found https://www.npmjs.com/package/serverless-http which I'm trying to use but seem to be unable to get the yaml file to be available when the lambda starts up. (serverless noob here!)