My concern is with the actual JS SDK API. They shifted from a dirt-simple, chained methods API to a setup where you have to create class instances for everything (including creating config). To make it possible, they also had to shift to a naming scheme for each class that just makes the code unnecessarily clunky.

E.g., it used to look like this:

// This was callback-based but could have easily been wrapped with promises.

s3.putObject({ option: 'blah' }, () => {});

Now it looks like this:

import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";

const client = new S3Client({ option: 'blah' });

const command = new PutObjectCommand({ option: 'blah' });

const response = await client.send(command);

---

It's improved now, but when this first dropped for 6-12 months the docs were just TypeScript auto-generated docs that were a nightmare to decipher (and a lot of stuff didn't even have examples, so you had to guess).

As for a "why this approach," it looks like they were trying to reduce the footprint of the SDK as a whole by breaking it into individual packages (smart) but instead of just keeping a simple API, they added all of this extra class instantiation and a funky client.send() pattern.

The ideal would be something simple like this:

import s3 from '@aws/s3';

await s3.putObject({ bucket: 'my-bucket', body: '<Some Binary>', key: 'my_file.jpg', });

Or even better:

import s3 from '@aws/s3';

await s3.buckets.post({ name: 'my-bucket', region: 'us-east-2', });

await s3.objects.put({ bucket: 'my-bucket', body: '<Some Binary>', key: 'my_file.jpg', });

Why I prefer the above: it's predictable and obvious. You have a structure of <library>.<resource>.<method> which can cleanly map to HTTP methods/API endpoints. You could even (easily) have aliases for methods like s3.buckets.create() or s3.objects.upload() that just map to the canonical function.