Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

aws-apigateway-lambda based on an OpenAPI specification #840

Open
2 tasks
drissamri opened this issue Nov 6, 2022 · 10 comments
Open
2 tasks

aws-apigateway-lambda based on an OpenAPI specification #840

drissamri opened this issue Nov 6, 2022 · 10 comments
Assignees
Labels
feature-request A feature should be added or improved needs-triage The issue or PR still needs to be triaged

Comments

@drissamri
Copy link
Contributor

API Gateways are often described by using the OpenAPI/Swagger specification, it feels like make sense that having a construct that generates the API Gateway based on an API specification would make sense.

Use Case

Perform contract-first development of APIs and generate the API Gateway based on the contract.

Proposed Solution

Pass in the openapi.yaml and one ore multiple Lambda functions.
An example of a OpenAPI API Gateway based can be found here: https://github.com/drissamri/cdk-examples/blob/main/rest-api-public/typescript/cdk/lib/api-stack.ts

  • 👋 I may be able to implement this feature request
  • ⚠️ This feature might incur a breaking change

This is a 🚀 Feature Request

@drissamri drissamri added feature-request A feature should be added or improved needs-triage The issue or PR still needs to be triaged labels Nov 6, 2022
@biffgaut
Copy link
Contributor

biffgaut commented Nov 7, 2022

Thanks, we'll take a look.

@biffgaut
Copy link
Contributor

We really like the feature, but it's not really what we do (connect CDK L2 constructs in a well architected way) - if this were to appear in our constructs the natural next step would be to add it to the L2 API Gateway CDK construct. Our advice would be to submit it as an added feature to the CDK API Gateway construct.

@drissamri
Copy link
Contributor Author

I might misunderstand, but as there is already a L2 construct that is being used with SpecRestApi it seems like there is value in connecting this with all best practises included like you said?

@biffgaut
Copy link
Contributor

OK, give us a bit to go back and check that out - thanks.

@biffgaut
Copy link
Contributor

Sorry for the delay - it looks like this might be unique enough that it would be a new construct - trying to add it to an existing construct would essentially make the construct perform 2 unique functions. Is that what you were envisioning?

@drissamri
Copy link
Contributor Author

It was indeed my assumption that it would be under a different pattern like aws-apigateway-openapi-lambda
Most of the code could/would be the same as the current pattern besides the setup of the RestApi construct replaced with the SpecRestApi.

I think in general this is seen as a best practise to have API contract first development, so this construct definitely seems to deserve its own spot to guide devs to a good setup.

@biffgaut
Copy link
Contributor

We like this idea and are going to look into it early in 2023.

@mattiamatrix
Copy link

It would also be great to have aws-openapigateway-kinesisstreams reusing the same code. I opened #913

@mattiamatrix
Copy link

Hello, when do you expect to release #912?

@biffgaut
Copy link
Contributor

We're very close, but have been temporarily sidetracked. Keep watch, when we get back to it we should finish it quickly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request A feature should be added or improved needs-triage The issue or PR still needs to be triaged
Projects
None yet
Development

No branches or pull requests

4 participants