RFC: Support OpenAPI generation for micro functions via CLI/script

[ran-isenberg]

Is this related to an existing feature request or issue?

No response

Which Powertools for AWS Lambda (Python) utility does this relate to?

Event Handler - REST API

Summary

Hi,
I'd like to use event handler with event validation turned on for my micro functions service. At the moment, the /swagger generation is done via one endpoint and unless that handler defines all routes in the app, there's no way to generate all the routes for the OpenAPI.

Use case

I have a service with multiple micro function, I'm not a fan of mono lambda for large service.
In addition, I'm more interested in generating the OpenAPI doc offline and saving it to my service repository where it can be later published to various location, and not necessarily served via the rest endpoint.

Proposal

Create a CLI that I can run locally on my service in the shell that generates the OpenAPI doc. It will need to init the event handler and it's all uses in the different lambda handlers and then generate the document and save it to a destination folder in a JSON format.
I have created a CLI that works with the current implementation - it accesses the deployed API GW at the /swagger?format=json and saves the output. Now, this is obviously not the solution, but it's an example of a possible interface (replace stack output input with the lambda handlers folder patch and it might be enough.

Here's the current CLI:
https://github.com/ran-isenberg/aws-lambda-handler-cookbook/blob/main/generate_openapi.py

Out of scope

I have added this script as a makefile command of my AWS Lambda handler cookbook and now it's part of my CI/CD pipeline where I can fail PRs if developers added/changed the REST API but forgot to update the documentation. Expect a blog post about it very soon :)

Potential challenges

Thanks @leandrodamascena for this section:

1. • OS compatibility: It's a CLI, we'll make sure it works on at least Windows, Linux and Mac.
2. • Security: what are the possible problems when we provide a CLI (even if it is pure python code) to install on someone' computer?
     3 - Performance: do we need to worry about any performance issues? - i dont think so, it runs locally,. can be several seconds at max.

Please note that it can even be just a script that i can run from powertools library.

Dependencies and Integrations

No response

Alternative solutions

No response

Acknowledgment

• This feature request meets Powertools for AWS Lambda (Python) Tenets
• Should this be considered in other Powertools for AWS Lambda languages? i.e. Java, TypeScript, and .NET

[leandrodamascena]

Hey @ran-isenberg! Thanks for kicking off this RFC – it's a great starting point to outline the requirements for this CLI.

After reading the code, I saw you've built a sort of "downloader" for an existing OpenAPI schema deployed in AWS via Cloudformation. While I see potential use cases for this implementation, I think it's important to consider some drawbacks that must be reviewed.

• One of the key features of this CLI could be the ability to generate a unique OpenAPI schema from one or multiple directories containing Lambda functions. How can we cover this?

• Customers may not use Cloudformation to deploy their resources in AWS and it's a potential limitation.

• Customers may prefer not to deploy the generated OpenAPI file directly to AWS. Instead, they may wish to create a local OpenAPI file from multiple Lambda functions and then upload it to their organization's dev portal, for example. This approach provides flexibility for teams to collaborate, document and establish contracts between applications across the organization.

• Customers might run into issues deploying resources on AWS, like making endpoints public (or private) without authentication. Do we need to think about adding authentication when this client downloads an OpenAPI spec from a given URL? And what kind of authentication?

Taking these points into account, it might be a good idea to reconsider our approach to building this CLI. Perhaps we should place more emphasis on local generation, rather than assuming that the file has already been deployed to AWS.

Please let me know what do you think.

BTW, I'll be adding the help-wanted and need-feedback tags to gather additional ideas from others as well.

Thank you!

[ran-isenberg]

@leandrodamascena I think i didnt explain myself well.
I totally agree with the local approach. I meant that the CLI that i built works with current implementation of the event handler.
Going forward an offline variation is preferred like you wrote.

[leandrodamascena]

@leandrodamascena I think i didnt explain myself well. I totally agree with the local approach. I meant that the CLI that i built works with current implementation of the event handler. Going forward an offline variation is preferred like you wrote.

I think this CLI should have the ability to download OpenAPI, as you wrote, but my opinion is that the core features should be something more offline to allow for more functionality with fewer restrictions.
What do you think about writing down some ideas in this direction and after that thinking about a PoC to validate?

[ran-isenberg]

We have implemented an offline OpenAPI generator CLI internally so i know it can be done.

What kind of ideas? i thought i already did that :)
"Create a CLI that I can run locally on my service in the shell that generates the OpenAPI doc. It will need to init the event handler and it's all uses in the different lambda handlers and then generate the document and save it to a destination folder in a JSON format."

what did you have in mind?

[rberger]

If effort was put into this, it would be nice to not require that CDK/Cloudformation be the basis of generating the OpenAPI info.

[ran-isenberg]

@anafalcao what are we discussing? :) let's build it