rcoh
commented
3 years ago A lot of very reasonable concerns here. At the end of the day, we think that the value of a consistent and reliable implementation of credential providers & other cross SDK features will be a worthwhile tradeoff for most customers. In fact, having the CRT be the common core of the three SDKs you described above could actually provide a uniform customer experience for handling those sorts of complex HTTP stack customizations you've described. In any case, a few ways we're hoping to mitigate a lot of the very reasonable concerns you've raised above:
In general, the CRT will be implementing a trait that's defined in Rust. So, as an example, in the case of credential providers, having the CRT as a credentials providers implementation doesn't prevent someone from implementing their own credential provider without ever having to touch C-land (and you could potentially even opt out of the CRT credentials provider if you wanted).
This is also the case for HTTP implementation (via the HTTPService trait). So although the CRT does have good support for things like HTTP proxies, you would still be able to drop in your own HTTP implementation if you need to.
Regarding build complexity, the CRT team has invested a lot in painless builds. The CRT and Rust can build together fairly seamlessly, with the only current target system requirement being CMake (but even that could potentially be worked around).
As we integrate with the CRT, I'm hoping to continue engaging with the community on their experiences—at the end of the day, our goal is building the best possible SDK for our customers.
I am curious to know the rationale for relying on the CRT for so many things, instead of implementing them as pure Rust.
Relying on an external C library will present a number of challenges, including:
Having spent time inside a number of the AWS SDKs (Java SDK v1 and v2, boto3/botocore and Rusoto) my impression is that most of the code is the service-specific logic (i.e. generated in this case) and while there is definitely complexity in the "core" components (connection management, signing, retries and error handling, etc...) that is the code that end-users will struggle the most with. Tasks like building custom credential providers, figuring out how to use an enterprise trust store, dealing with weird HTTP proxy schemes, integrating with third-party application configuration stacks, and other (super common but literally different at every site) customization will become more difficult for end-users (all of which are things that I've personally had to deal with, and integrate into all three SDKs mentioned above).