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

Note for Future Improvement #21

Open
CalebCourier opened this issue Jun 24, 2024 · 0 comments
Open

Note for Future Improvement #21

CalebCourier opened this issue Jun 24, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@CalebCourier
Copy link
Collaborator

CalebCourier commented Jun 24, 2024

Note for Future Improvement

As you can see from these changes, it has become abundantly clear that the code generation tool chain for python is inadequate. Most of the issues are the result of the library trying to do too much (ser/de, using restrictive pydantic types, etc.), but in some cases the generator is just buggy (i.e. not including all properties in ser/de methods). If we want to limit the number of customizations we have to apply to the generated code in the future, I believe we have a few options:

  1. Contribute to the existing python generator
    • PROs
      • Continue to use the same library
      • Contribute back to the community
    • CONs
      • Difficult to find source code (activation energy)
      • Have to deal with legacy code (backwards compatibility)
  2. Develop our own code generator
    • PROs
      • Can write it to suite only our needs
      • No baggage
    • CONs
      • High effort
  3. Write the API client manually and use pydantic generated OpenAPI Spec to generate other language clients
    • PROs
      • Python native, less chance of churn in open source
      • No baggage in Python classes
      • Can support both http and gRPC
      • Can use current auto-generated classes as a base (less activation energy)
    • CONs
      • Will likely still need hot-fix scripts bc pydantic uses some undesirable patterns when producing OpenAPI Spec (i.e. anyOf type + null instead of just using required array)
      • Limited to OpenAPI Spec instead of full JSON Schema
      • Will have to write endpoint methods ourselves (not complex, just toilsome)

Originally posted by @CalebCourier in #20 (comment)

@CalebCourier CalebCourier changed the title ### Note for Future Improvement Note for Future Improvement Jun 24, 2024
@CalebCourier CalebCourier added the enhancement New feature or request label Jun 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant