Proposal: New SDK Generation with open_api_generator

[chazwatkins]

The current implementation of the SDK generator has limitations in handling objects like BankAccount, which takes polymorphic object inputs such as Source and ExternalAccount, because both endpoints use the same operation method name for the first and second arguments.

Currently, the SDK supports Stripe API v755, and the latest is v1680+. Given that the maintainers are stretched thin and unable to address this issue to allow updating the SDK to later versions, I'd like to provide some help.

I propose we replace the existing custom generator with open_api_generator, incorporating some overrides for module and function naming. This will introduce breaking changes, as the API for interacting with resources will be different; however, it will enable us to automate the SDK generation for new API versions, thereby reducing the strain on maintainers.

I propose this idea because I know the maintainers have expressed a desire to upgrade the SDK to later versions, but simply don't have the capacity. After hours of investigation into the existing generation code, it is nontrivial to handle the issue of duplicate function names. It would be easier to swap out the generator, accepting breaking changes for a new major version, to enable the community to have an updated Stripe SDK.

Please let me know your thoughts. If the team is interested in the idea, I'm happy to put in the work to contribute this change and collaborate with the team on how the SDK's API should look.

[doomspork]

I think this is a fantastic idea @chazwatkins and something I've certainly pondered myself. If you'd be willing to help lead the charge I know myself and others would be greatly appreciative and we can try to contribute as much as possible.

[yordis]

If we are open to break change, I can improve the situation, I tried my best to avoid the breaking change 😭

[doomspork]

@yordis what would be the breaking change if we're still adhering to the published OpenAPI spec?

[yordis]

the module and functions names primarily

[yordis]

Hey @chazwatkins if I have to start over, I would align with the rest of the industry and use https://github.com/OpenAPITools/openapi-generator

The tool is tested (as a generator), and more important, dog footing the tool and make it the best it could ever be would allows us to promote Elixir easier, since the tool is used across multiple products in the industry. We will be available right next to other popular languages; instead of isolating ourselves.

[doomspork]

I'm in favor of using OpenAPITools tooling in place of an Elixir package for this 👍

[yordis]

For a very long time, I wanted to strategically make that generator the best it will ever be. Let me follow up on this

[chazwatkins]

After some research on the Elixir oapi_generator package and Open API Tools generator, it seems the Stripe API spec doesn't generate a separate API for each object and puts all functions into a single file. The functions are all generated using the path id as the function name, which is not ideal. When generating an SDK for polar.sh, it generates the separate files as expected.

The Open API Tools generator is written in Java and needs some updates to allow for overriding default behavior, similar to oapi_generator.

[yordis]

Ideally, we move away from special codegen and things are homogeneous around OpenAPI specs.