[Poll]Universal Clients or Runtime Clients?

[AllanZhengYP]

We are discussing the possibility to ship only universal packages (like @aws-sdk/client-*) instead of separated service clients for runtime like @aws-sdk/client-*-node and @aws-sdk/client-*-browser. It would contain a cjs package for Nodejs runtime and an esm distribution for browser runtime. The universal package will have dependencies from both Nodejs-specific clients and browser-specific clients.

What change would happen after this change:

• There is only one package per service for browser, Nodejs, and React-Native(Universal).
• Current modularization won't change. Browser bundle size will keep small.
• In lambda, if using bundlers or deployment tools(e.g. SAM, serverless), the code size or cold start time will keep low.
• TypeScript definition will be general across the runtimes(e.g. streams will be typed as Readable | Blob)
• Npm package will be bigger because it contains dependencies of both browser and Nodejs runtime, only if no bundlers is used.

Please select ONE option below to show us your preference and comment the reasons for your choice below.

[trivikr]

The poll 👆allows multiple votes and should be updated
Allow only one vote per GitHub user?

The option doesn't seem to be available apex/gh-polls#38

[G-Rath]

You might have already considered this, and I can't speak to how easy it would be to maintain, but have you considered doing both?

The Slack packages on npm are a great example of a package structured with this kind of thinking in mind:

They originally had just a slack/client package, which held the code for their web & rtm api, and their webhook stuff.

They've since refactored into three packages: @slack/web-api, @slack/rtm-api, & @slack/webhook.

However, they've also got a fourth package: @slack/client, which is a legacy wrapper that provides all three of the above libraries by literally just depending on them and importing them into the same file.

It's literally a single file that re-exports a bunch of stuff, with some renaming when needed.

They're also written in TypeScript, and I've not had any issues w/ them i.e type conflicts.
In saying that, I can't speak to what the overhead might be - they might have a really nasty ci script or even do manual re-typing of the definitions to make them work together.

---

Overall, in an ideal world I think it'd be super cool to have both, just b/c of the easy of use factor.

In lambda, if using bundlers or deployment tools(e.g. SAM, serverless), the code size or cold start time will keep low.

That's my only issue w/ having a package that contains both node + browser versions: I currently just use tsc + node-lambda to do my lambdas.

In saying, I imagine regardless you'd provide the aws-sdk-v3 packages in the same way you do the aws-sdk one, which'd make it a non-issue?

[AllanZhengYP]

Hi @G-Rath,

Thank you for your insight. I like the idea of have a monolithic package that re-export all the clients packages.

Regarding deploying to lambda with rudimentary bundler, since the code size will never be bigger than V2 SDK in theory(because V2 is already a runtime-algonositic library). It should be fine.

[trivikr]

Resolving as we decided to go ahead with Universal Clients

[lock]

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.