Open Payments: Develop a ts/js client sdk

[matdehaast]

Summary

TODO: Flesh out

Intended Outcomes

How will it work?

Links

[wilsonianb]

Related/duplicates:

• Create Open Payments client library rafiki#663
• Use generated Open Payments OpenAPI types rafiki#662

[mkurapov]

@matdehaast @wilsonianb
What is the initial scope for this client? What are the first endpoints and immediate functionality that it should support? 
Should it support just the resource server spec for now?
Additionally, should there be separate clients for each open api spec? We should consider
@sabineschaller 's spec splitting changes as well.


Following, where should those client(s) live? There are a few options:


• Create a standalone repo with the client (will be easiest to handle versioning this way in the future).
• Create the client in the openpayments repo, and expose the type generation as a step in a workflow.
• Create the client as a workspace package in the Rafiki repo. Easiest to get working & tested before creating more of a standalone thing.


Having this client as a workspace package (as a sibling to the /backend service) made the most sense for me: no need to deal with versioning, package publishing as the initial functionality is built out. I made small POC here.

Currently, if my understanding is correct, the Rafiki to Rafiki open payments API call is the one to query /incoming-payments (or /connection) during a) quote creation, b) outgoing payment creation and c) outgoing payment lifecycle handling. This is the OpenPaymentsClientService that exposes functionality to find the receiver of the incoming parent.
Would it make sense as a step 1 to focus on replacing that class with the client instead?
 After that, we can tackle interledger/rafiki#606, interledger/rafiki#583, interledger/rafiki#587 as @wilsonianb listed for example.

[wilsonianb]

That POC looks good.

Would it make sense as a step 1 to focus on replacing that class with the client instead?

Yes, I think starting out with:

• incomingPayments.get
• connections.get

and exposing the related generated typescript types, in order to replace existing functionality in the aforementioned OpenPaymentsClientService, would be a great start.

Bonus points for including the related openapi validation, which seems a little complicated to me, because ideally you want to use the same version of the OpenAPI spec for both validation and type generation (as well as in the backend's config.openPaymentsSpec interledger/rafiki#662) .
I think putting it in the open-payments repo will actually be the easiest for versioning, but I'm not opposed to having it in the rafiki monorepo for now.

[mkurapov]

@wilsonianb thanks for the quick feedback! I'll start off with those, and see how to best swap out the existing ClientService.

I did consider adding in the validation as well (left a small comment about it on the PR, that we can leverage the open-api package for it). I'll think of something to make sure the schema is validated against the same spec as was used for generation

[wilsonianb]

I've been looking at Stripe's nodejs library and discovered that they have (had?) a closed source OpenAPI generator tool
https://www.npmjs.com/package/stripe
stripe/stripe-node#902 (comment)

Would it make sense to similarly make this an open-payments library, not necessarily client-specific?
Maybe you'd still similarly be able to construct a client instance with a secret (from interledger/rafiki#606), a la:
https://github.com/stripe/stripe-node#usage

[mkurapov]

@wilsonianb what do you mean exactly by

...open-payments library, not necessarily client-specific?

As an aside, it's also a shame stripe kept the tool internal

[wilsonianb]

That whether or not this includes "client" in the name, it can be used by Open Payments resource or auth servers for the generated types and potentially also request validation (plus whatever else we might realize that a server needs that a client doesn't).

[mkurapov]

@wilsonianb makes sense - Ill have it as open-payments and just have a client as a separate thing in there.
I also swapped over to use a script to generate the types so we can pull out the version of the Open API spec: https://github.com/interledger/rafiki/pull/669/files#diff-5d3d70f88392e9da968b96471165a3812a07287c842ee7a3da02cc316c7888f5R2 so we can generate & validate against the same version

[mkurapov]

Outstanding tasks:

interledger/rafiki#663 (comment)