feat(interledger): ilp account api

[cairin]

Changes proposed in this pull request

• resolves Expose account API to backend via graphQL #57

Context

Checklist

• Related issues linked using fixes #number
• Tests added/updated
• Documentation added
• Make sure that all checks pass

[sentientwaffle]

What does code refer to in all of these responses? Is it the string error enum?

[cairin]

It's meant to represents the status of the data transfer, like an HTTP status code.

[sharafian]

I think all the Ints in the schema need to be changed to allow UInt64 and up. Overall this all makes sense to me

[sharafian]

can we create an input type for Pagination so that we don't need to keep re-defining this?

[cairin]

We can, theoretically, but I don't think we should.

Firstly, the pagination algorithm we use (GraphQL Cursor Connections Specification) defines it this way. This is mostly to optimize for the clients side - making it easier to cache and fetch more data without necessarily having to program the logic each time. Of coarse this can be adapted to take in an input rather than individual arguments. Relevant apollo docs. Example implementation: Shopify pagination spec.

Secondly, it seems like standard practice to only use input objects for mutations, whereas queries usually have individual arguments. Example: Github graphql.

Lastly, a graphql input can't implement an interface. The fields on an input object type can themselves refer to input object types, but you can't mix input and output types in your schema. So you would have to redefine this anyway for each input:

type Query {
  ilpAccounts(input: IlpAccountsInput): IlpAccountsConnection!
}

input IlpAccountsInput {
  "Paginating forwards: the cursor before the the requested page."
  after: String
  "Paginating backwards: the cursor after the the requested page."
  before: String
  "Paginating forwards: The first **n** elements from the page."
  first: Int
  "Paginating backwards: The last **n** elements from the page."
  last: Int
}

Which just feels like unnecessary abstraction, and also more typing ⌨️

We could of course implement it like this:

type Query {
  ilpAccounts(pagination: PaginationInput, other: SomeOtherArguments): IlpAccountsConnection!
}

input PaginationInput {
  "Paginating forwards: the cursor before the the requested page."
  after: String
  "Paginating backwards: the cursor after the the requested page."
  before: String
  "Paginating forwards: The first **n** elements from the page."
  first: Int
  "Paginating backwards: The last **n** elements from the page."
  last: Int
}

But we'd have to agree that going against the standard is a good idea.

[wilsonianb]

#51

As is, trustlines don't have an id. Trustline methods just take accountId of the sub-account to which the trustline is extended.

Similarly, there's no trustline resource, so the trustline query further above isn't necessary. Trustline info is just included with (sub)account balances.

[cairin]

@wilsonianb Cool, I have updated the schema, please check you're happy with it!

[sharafian]

@cairin were there any places here where you wanted input on translating the Account service API to graphQL? Or have Brandon's clarifications on the credit/debt functionality covered everything?

[wilsonianb]

The commit in #69 adds accountId and subAccountId to the credit and debt mutations

[wilsonianb]

👍
With the bigint serialization fix, I can pass a string as a query/mutation variable. It's received by the resolver as a bigint, and the test client receives bigint string in the response. ✔️

I'll be submitting subsequent pull requests with accounts service resolvers.

[matdehaast]

Looks good @cairin . There are lots of TODO's in here. We just need to make sure those get captured correctly in the issues/project board

[matdehaast]

bigint isn't an unsigned bigint. Should we keep the scalar as UInt64?

Also I can't remember but are there any values in the account spec that could be negative?

[wilsonianb]

I think the accounts service (and tigerbeetle) only does unsigned values