Stacks-blockchain-api client library

[zone117x]

Reference issue: #170

This uses openapi-generator to generate a client library based off the openapi.yaml and json schema files.

There's currently a bug with the transaction responses not being typed correctly, see OpenAPITools/openapi-generator#6513

All the newly committed source files are auto generated, except for test.ts which has a brief demo of how the generated client is used:

[codecov]

Codecov Report

Merging #185 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #185   +/-   ##
=======================================
  Coverage   59.65%   59.65%           
=======================================
  Files          44       44           
  Lines        2917     2917           
  Branches      496      496           
=======================================
  Hits         1740     1740           
  Misses       1174     1174           
  Partials        3        3           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 780c84e...55bf0a3. Read the comment docs.

[kyranjamie]

I'd love to get some mileage out of an auto-generated client tool like this, but I'm not sold it'll be worth the time investment and tying ourselves into a tool.

First, I'd imagine were we to proceed using this, we'd quickly come across some requirement we want to add that is not easily added, and requires some ugly monkey-patch. It'll have a limitation somewhere (similar to bug shared).

Second, I'm not sure what problem it solves. A simple client library is trivial to build. All the types are there. Hank's made a start. Give it two days of dedicated dev and we'll have a pretty decent client ready.

Curious on @hstove and @aulneau's input. They'll also be heavy users of whatever client lib we end up with.

[zone117x]

I'd like to avoid maintaining multiple sources of truth for the public API. We currently maintain two. One in OpenAPI format and one in server ts code. This approach avoids adding a third.

Spending a day or so fleshing out a full client implementation isn't my concern, it's the maintenance burden that I'd like to avoid.

[kyranjamie]

I wouldn't disagree. There should only be one source of truth, the spec.

But is auto-generating a client the only way to achieve this? TypeScript can import JSON (build step to convert yaml).
We can conform to the source of truth by referencing all the details in the spec.

My main critique with this approach is that we're not able to make our own API design decisions. The client should be as friendly to use as possible. If we can make a request easier to use/consume with a few lines of code, we should. With a generator you get what your given. Maybe a hybrid approach could work, if we can set it up to extend/rewrite methods ourselves.

The generated types for requests parameters here would be pretty useful, though.

[blockstack-devops]

🎉 This PR is included in version 0.6.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀