Clarification of the API-design employed by the SDK

[thuringia]

Describe the issue with documentation
A clear and concise description of what the issue is.
Hi everyone,
I'm reposting this as an issue, as there were no replies on Gitter.

Hi everyone,
I was thinking it might be better to ask this question here first, before opening an issue. Checking out the current gamma release there is a lot to like in the v3 SDK, however when trying it out I was left a bit disappointed by the proposed new API. It doesn't feel like an API designed for node... yet there is no description in the README or the issues giving insight into the design.
I'm not sure if this is just my personal biases regarding API design talking though. Hence this long question here:
Why is the "modular" API designed as a pattern of const c = new Client() and c.send(new Command())? I would have anticipated an API more in line with patterns in other libraries like const result = await command(options, client()), that way we could easily curry SDK-functions with project-specific configuration etc.
Please ignore my non-usage of new this question is really not about "why classes".
The current API feels very much like it is wrapping a set of RPC endpoints... which is absolutely fine, but wouldn't it be preferable to more closely align with other projects in this space.

On a related note:
Maybe the SDK could ship with a babel plugin or macro to rewrite the "enhanced v2" syntax to the "modular" one? The v2 syntax in many ways feels like a rather cohesive OOP-API, making it much easier to teach to juniors or team members who are not as familiar with AWS. The v3 API already raised questions like "what's a command" when we presented the v3 SDK as something new in a knowledge session.

Something I missed in my original question was that a signature like const result = await command(client(), options) would be perfectly fine, if functional-patterns are not the focus. That way the SDK would provide an API like lodash or many built-ins.
The reverse, more fp-friendly version, could be provided as a separate export (like lodash-fp), if desired.
A babel macro/plugin would cause too much confusion with tooling here (e.g. type autocomplete).

To Reproduce (observed behavior)
n/a

Expected behavior
A description in the README regarding the API design of the library, ideally this also mentions things like error handling as discussed in #1549 . Personally, I'm hoping for a change towards a more idiomatic API, however this is not the goal of this issue.

Screenshots
n/a

Additional context
I provided some context in my question above. Please let me know, if further details help.

[trivikr]

@thuringia Thank you for the suggestion.

In 2020, we've moved to using more functional patterns in AWS SDK for JavaScript code base in utilities packages, following up with JavaScript community as they adopt more FP patterns. We don't plan to use those patterns in clients in v3, as it's in RC stage and close to general availability.

Having said that, we would be considering removing classes from the codebase in v4 when the work gets prioritized. We've had internal discussions about using FP, and would be making those discussions public sometime in 2021. As a customer, do share your data points on how an fp-friendly version would be helpful.

[trivikr]

I've created a GitHub Discussion on FP-friendly modular AWS SDK for JavaScript #1758

[github-actions]

Greetings! We’re closing this issue because it has been open a long time and hasn’t been updated in a while and may not be getting the attention it deserves. We encourage you to check if this is still an issue in the latest release and if you find that this is still a problem, please feel free to comment or open a new issue.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread.