You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem is that my openapi codegen macro was built for openapi 2 while the latest AWS APIs are published in openapi 3. If someone wants to update the openapi library to support the new version, then we can rebuild all the APIs. This is probably pretty straightforward, and a rather large lift for all openapi products out there.
I made extensive use of this library in production when I wrote Nim for a living, but in seeing people try to use it in the wild, most really don't understand why it works the way it does. People seem want a much simpler, less performant, naive API. Point being, I'm no longer sure the means justify the ends.
If you're using other parts of atoz, perhaps you can chime in with whether the approach was burdensome or advantageous to your use-case...
No. I've used several programming languages which generated AWS APIs via the OpenAPI intermediate representation and, net-net, it's a reliable and efficient basis on which to build software.
I'm personally not interested in going back to using these sprawling APIs as composed "by hand", not to mention building or supporting them in the first place. Again, it's just not practical or robust.
If using OpenAPI is too onerous, perhaps you could consider wrapping the C++ APIs instead.
I don't see Bedrock support in the SDK. What is the process for getting the SDK updated to support new AWS services and APIs?
The text was updated successfully, but these errors were encountered: