amazonka-managedblockchain-query: generate

[wraithm]

Is it possible for amazonka to generate a package for Amazon Managed Blockchain Query? This is a slightly different API from Amazon Managed Blockchain. It's for querying data on chain as opposed to managing their nodes. amazonka currently supports Amazon Managed Blockchain, but not AMB Query, as far as I can tell.

Here's the documentation for AMB Query's API:

https://docs.aws.amazon.com/managed-blockchain/latest/AMBQ-APIReference/Welcome.html

If it's possible to add this API, I'd be more than happy to make a PR to add support for it. I might just need a little bit of direction to make sure that I did it right.

Thanks!

[endgame]

The unfortunate answer is: not easily, and therefore not soon.

Amazonka generates service bindings by parsing AWS' botocore library, and then writing out a bunch of .hs files.

While the generator is battle-tested, it is also brittle. It resolves references between structures (what botocore calls "shapes") essentially by inlining them via a cofree comonad. This falls down when you have circular references (which happens e.g., when a service definition includes things like syntax trees). We have this fixed by using a special Ptr constructor in shapes, which tells the generator to go look it up in a HashMap instead of expecting it to be inlined.

This mostly works, but there are edge cases. See #888 for the gory details, but essentially: we can compute deriving clauses only when a structure is inlined, but we have to guess at the deriving clauses needed by a Ptr. If we advance botocore, the order in which things enter our HashMaps changes, which changes which structures get inlined vs. referenced via Ptr, which breaks generation of existing libraries that we've created and published. On top of that, we're stuck on a pin of hashable-1.3, to prevent a hashable upgrade in the generator from breaking the code we ship to Hackage.

The compromise for the 2.0 release was: ship as much as we can, and fix the generator later. The long-term plan for the generator starts in #957: we need a proper syntax tree for botocore, which captures all the detail we need, including the declared order of fields within a shape. (JSON is not supposed to care about field order in objects, but this lets us commit to a specific order, and stops us accidentally switching field arguments in smart constructors, which has bitten people in the past.) Once we have a botocore library, we can look at splitting the generator front/backend to use it, simplifying the generator-side code into a set of shapes that never does inlining, so that we can write a proper solver for deriving rules once and for all. As a side bonus, this will let us write amazonka-style generators for other data sources, like an OpenAPI spec for an API Gateway with IAM authentication (e.g., Amazon's own Selling Partner API).

I suspect that these are larger PRs than you have capacity to provide, but if you're willing to tackle some of this, I can help coach and review.

Alternative workarounds: you might be able to declare your own Service record for this service, as well as request and response objects for the just endpoints that you need. You might also be able to generate a private amazonka-managedblockchain-query, but then you're back to importing private dependencies from git, which is a situation I'd like to avoid so soon after the 2.0 release.