Rockets API SDK Discussion

[tnramalho]

We need to start a discussion about the creation of an SDK for Rockets API. The goal is to define how modules should be grouped, how the SDK should be accessed, and what the best structure would be for ease of use and scalability.

Why is this needed?

Developers need a streamlined way to interact with the Rockets API.
Standardizing module grouping will improve maintainability.
A well-designed SDK can enhance developer experience and adoption.
Key Discussion Points
Module Grouping

Package Proposal

Should we follow a feature-based, service-based, or use-case-based grouping?

How should dependencies between modules be managed?
SDK Access & API Design

What should the initialization process look like? (e.g., new RocketsSDK(config))

Should we expose a fluent API, promise-based methods, or event-driven design?
Language & Platform Support

Which programming languages should be prioritized? (JS/TS, Python, Go, etc.)

Should we provide official support for multiple SDKs or focus on one initially?
Potential Approaches
Use an interface-based structure with different implementations.
Provide built-in authentication handling.
Offer a lightweight vs. full-featured version of the SDK.

Next Steps

Define a high-level architecture proposal.
Start a proof-of-concept implementation.

Implementation Approach

Implementation Approach

The idea is to generate the SDK using Swagger/OpenAPI.
However, Swagger does not generate NestJS-like API references (e.g., auth.github.login).
We need to define how to structure these method calls while maintaining a clean and intuitive interface.

Possible solutions include:

• Post-processing the generated Swagger client to match NestJS conventions.
• Creating an abstraction layer to map Swagger-generated functions to structured namespaces.
• Manually structuring key modules while still leveraging Swagger for basic API communication.

Potential Approaches

• Use an interface-based structure with different implementations.
• Provide built-in authentication handling.
• Offer a lightweight vs. full-featured version of the SDK.