Description

The goal is to mimic the same pattern as other projects have been doing, modularizing the sdk as much as possible, where each folder on the root level represents a module, so the end user don't get bloated with a bunch of dependencies they didn't want and didn't need indeed.

For this we are planning to have this repository working like a monorepo, where by design each of these contents have their own modularization and usage. if for some reason on the future, one of these does not make sense we can easily teardown or halt the work if needed.

we need to have these decisions well documented for future reference and to help onboard other peoples.

Proposed Solution

As a developer, I want to be able to use independent packages, so I can use parts of the sdk on demand, without overloading the end product with useless dependencies.

Alternatives / Workarounds

No response

Acceptance Criteria

• each module should be usable independently in a use-land project
• shared code like client should preserved throughout the modules.
• write tests to ensure modularity as a real functionality including shared clients

Additional Context

it is important to define what is the expected behaviour when the user uses more than one module to compose his solution, should the client being persistent throughout the modules? should each of them being separately in their functionality?
should we have the client behaving as a singleton just when it identifies environment variables on the system?

References

• google-cloud-go for reference
• aws-sdk-go for reference
• Developing and publishing modules (go docs)
• Module release and versioning workflow (go docs)

Code of Conduct

• I agree to follow this project's Code of Conduct