I believe AWS already autogenerates their API clients (e.g. boto3) based on some authoritative internal service api spec so I imagine that spec could be used upstream of this tool as well.
replyBut their auto generated API clients don't have the invariant baked into them, which makes them very rough to use in say Rust.
replyThey'll have something like this:
MySchema:
type: object
properties:
enum_member: { enum: [foo, bar] }
enum_member_2: { enum: [quz, qux] }
if: { properties: { enum_member: { const: bar } } }
then: { required: [enum_member_2] }
So your Rust API is full of Option, and it gets really annoying when you're testing things like say Bedrock, which takes 10 minutes, and then fails because what you submitted 10 minutes before doesn't match their schema.
I understand this can be fixed by reading the documentation in more detail, but it has gotten so verbose, and sometimes you just want to start something.
Not internal. Open sourced: https://github.com/aws/api-models-aws
replyYeah whatever they did internally to get service teams to actually adopt AWS Config ~5 years ago needs to happen here or it’s going to get stuck with marquee services and that’s it. Especially given this is a much much larger ask of each service.
replyAWS Config already doesn’t support some pretty important things
replyAgreed but it used to be way way worse.
replyAWS has lots of unfunded mandates like this and they historically just depended on bleeding the souls of engineers and managers to get done.
replyI suspect this is built by agents through bleeding the soul of GPUs until it gets too expensive (unfunded mandates are free after all on the OP1/2). Then it just decays into the place all good PR/FAQs decay once their sponsors are promoted, burned out, or are laid off.
There are many AWS services. Simply offering an alternative to a few of the most used could be a good business. It doesn't have to cover all AWS in all release versions, just enough to get and hold some clients
reply