3 ms·

Doesn't AWS have good reasons for its signature scheme stuff? XML is probably legacy but...

by rendaw 2y ago

rglover 2y ago
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.

Doesn't AWS have good reasons for its signature scheme stuff? XML is probably legacy but...

by rendaw 2y ago

Doesn't AWS have good reasons for its signature scheme stuff? XML is probably legacy but...

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.