Run up to 0.14.0

[arlyon]

Hello

There are a few things we need to sort out for 0.14, which I will list below. There are essentially two paths here, one being patching the current flawed codegen, and the other being rewriting it from scratch.

The crux of the issue right now is that the codegen is frequently breaking due to a) imperfect generation code and b) frequent and significant changes to the stripe openapi spec. A major symptom of this is having to temporarily change the API to use Boxes, as the latest spec introduces recursive data structures and so broke compilation. These changes are technically backwards compatible on the stripe side, as adding a field doesn't break API users, however for us using a typed language, it is a breaking change. And so we released 0.13.

The goal for 0.14 is to try and simplify the codebase in spite of this change, but we have a major decision to make. Simply put, stripe could make more changes like this, so the choice is, keep everything boxed (and by extension visually noisy, and less space-efficient), with knowledge that new recursive data structures are non-breaking, or only box at known recursion points, requiring extra effort / heuristics to maintain, and potentially causing breaking changes down the line. All of this while juggling the code size and codegen (serde derive) times to make sure the library stays both small and useful.

• 🚨 improve test coverage
• 🚨 make sure the 'unusual params' are implemented properly: https://github.com/arlyon/async-stripe/blob/master/openapi/src/main.rs#L595 (progress started at Updated after rebase, testing CI again, Enums and other stuff #153, Dev destination handling #158)
• explore the effects of implementing Default across the codebase Derive Default on structs #152
• better understand the feature dependencies, and make sure that no combinations break (perhaps through some tooling) Certain feature combination does not compile #137
• consider alternatives to serde (such as nanoserde)
• either:
  • a) accept Box everywhere
  • b) allow the openapi generator to box in specific places Split out and organise openapi code #160
• consider splitting generated code into own crate? this would speed up local changes as the generated code is less frequently compiled
• improve the quality of the PRs and commits
  now that we are approaching an api / feature set that is appropriate, we should probably move away from 'moving fast' and begin to be more clear and descriptive with changes, so that the change over time is easy to digest
• opt-in auto-retry functionality following the stripe retry headers
• apply fix for constant time sig check (and remove dep on subtle): see here for context Use hmac and hex crate for fixed length comparison wyyerd/stripe-rs#210

[arlyon]

Currently we use a lot of Boxing as a result of a loop (causing infinite sized structs). After some investigation of the depedency tree, this is exclusively encountered in the ApiErrors struct which has PaymentIntent and SetupIntent field, both of which an optional ApiError.

I think, due to the small and very maintainable number of cases where this is the case, that we revert the Box change, and rely on some metadata to determine where to box. IMO the best solution is just to Box all the types in ApiErrors that we own. It is a minimal maintenance burden for significantly improved ergonomics.

Thoughts? @erichCompSci @FL33TW00D?

[erichCompSci]

I was trying to find this. One of the biggest things that bothers me the most about the current openapi generation is that it assumes a list of only 4 possible operations for each REST request. This is severely limiting since many of the operations have to then be handcoded if they are non-standard (Like the LoginLink API) or if their are other operations (like deletion, etc.)

The OpenApi is very clearly orgainized. There are structs that are defined at the top, followed by the list of API calls that follow a very clear and simple syntax.

In our reorginization, it would be nice if we could simply code generation to:
a) Generate all the structs
b) Generate all the function Rest API calls with the appropriate structs passed to them
c) Generate any necessary params for the API calls.
d) Handle strange cases (mostly Meta and the APIErrors, hopefully nothing else)

This would be a step away from tying the requests to a particular type, but I argue that this is really nothing more than a namespace change, because all of your API calls are associated functions, so the spelling is all you are protecting here. It will also allow for the automatic generation of ALL Stripe API calls, not just the four that we "guess".