Skip to content

feat: initial oas generators support; algod http clients with tests covering transaction endpoints; refinements in python ffi package #63

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

Open
wants to merge 21 commits into
base: main
Choose a base branch
from

Conversation

aorumbayev
Copy link
Collaborator

@aorumbayev aorumbayev commented Apr 28, 2025

Proposed changes

This PR introduces the infrastructure for generating Algorand API clients using the OpenAPI Generator tool. This approach automates the creation of clients in various languages (initially focusing on Python and TypeScript for algokit-utils) from a single OpenAPI specification, ensuring consistency and reducing maintenance overhead.

Motivation:

As outlined in docs/research/openapi-generators.md, manually maintaining API clients across multiple languages is time-consuming and error-prone. Using OpenAPI generators allows us to:

  • Generate consistent clients from a single source of truth (the OpenAPI spec).
  • Easily propagate API changes to all supported languages.
  • Leverage a mature, well-maintained open-source tool.

Changes:

  1. Directory Structure: Introduced new directories and files under /api to support the generation process:
    • api/specs/: Contains the OpenAPI specifications (v2 and v3).
    • api/api_clients/: Will hold the generated client code.
    • api/oas_templates/: Stores custom Mustache templates for tailoring generated code.
    • api/scripts/: Includes utility scripts (generate-api-clients.ts) for managing the generation process.
    • Configuration files (openapitools.json, package.json, tsconfig.json, openapi-config.yaml) to configure the generator and manage dependencies (like bun for running the generation script).
  2. Specification Handling:
    • Uses the v3 OpenAPI spec derived from the official Go Algorand source for better generator compatibility.
    • Includes minor improvements to the spec for clarity and generator compatibility (e.g., formatting, fixing AvmValue schema for Python).
  3. Generation Script: Added scripts/generate-api-clients.ts (run via bun run) to orchestrate the client generation, including handling .openapi-generator-ignore files to protect custom code.
  4. Initial Client Focus: The initial setup targets core transaction endpoints (get pending txns, get tx params, post raw txn) needed for algokit-utils integration.
  5. Testing Strategy: Adopted a custom testing approach (as detailed in the research doc) rather than modifying generated tests, allowing for more robust and maintainable tests tailored to our environment (e.g., Sandbox dependencies).
  6. Documentation: Added docs/research/openapi-generators.md detailing the approach, structure, rationale, and future work.
  7. Dependency Updates: Updated poetry.lock and pyproject.toml in packages/python/algokit_transact reflecting changes potentially related to CFFI or other dependencies needed for the generated clients or testing infrastructure. (Specific updates include cffi, maturin, packaging, pluggy, pytest, tomli, and adjustments to dev dependencies).

This PR lays the baseline for a more scalable and maintainable approach to managing Algorand API clients across different languages within the monorepo project.

…dify

- Instead setting up a structure for custom mustache files implementing manually written tests given that each end point (total around 55) often requires complex state setup
- For the time being the only test established is the test for sending raw transactions
Refines the algokit-transact Python package to improve
compatibility with Poetry and Python 3.13.

Updates dependencies and build configurations for a smoother
development experience.
@aorumbayev aorumbayev force-pushed the spike/oas_clients branch 4 times, most recently from f858c9a to 97af59d Compare April 29, 2025 00:18
@aorumbayev aorumbayev marked this pull request as ready for review April 29, 2025 11:17
@joe-p
Copy link
Collaborator

joe-p commented Apr 29, 2025

Haven't reviewed in-depth yet, but would it be possible make the Python changes in a separate PR? We have merge conflicts anyways after #61 and having that work in a separate PR will make it a bit easier to review and iterate.

@aorumbayev aorumbayev force-pushed the spike/oas_clients branch 3 times, most recently from b79287d to 8e6f806 Compare April 29, 2025 20:33
@aorumbayev
Copy link
Collaborator Author

@joe-p moved python ffi changes to #65

@aorumbayev aorumbayev requested a review from PatrickDinh May 2, 2025 17:03
@joe-p
Copy link
Collaborator

joe-p commented May 4, 2025

Could we add extension to the moustache template files to make them a bit easier to digest? For example, instead of conftest.moustache it could be conftest.py.moustache

],
"scripts": {
"test": "vitest",
"build": "npm run clean && npm run build:esm && npm run build:cjs",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hey @aorumbayev, sorry I missed this in my first round of review. Do you think that we should change this to bun instead of npm to align with the rest of the code base?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants