You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 13, 2022. It is now read-only.
The idea of "Relationship" seems to be a bit too abstract and leads to confusion as most of the APIs we're integrating use the concept of "Customer" and we find ourselves mapping those two conceptually.
Instead of using:
queryAccountQuery {
me {
relationship {
accounts {
id
}
}
}
}
We'll use:
queryAccountQuery {
me {
customer {
accounts {
id
}
}
}
}
Note that we're still keeping the distinction between "me" (as the current user) and "customer" (me in my role as a user). This is still an open area for conversation but we'll try this version first.
We still need to handle the idea of "Top Level Accounts" that we've encountered at FIs (particularly credit unions), where they'll have a structure like:
User
Account 1234
Subaccount 123401 (Savings account)
Subaccount 123402 (Checking account)
Account 4321
Subaccount 432101 (Savings account)
Subaccount 432105 (Loan account)
In a previous project we mapped these conceptually to:
User
Top Level Account 1234 (or "Account Group")
Account 123401
Account 123402
Top Level Account 4321
Account 432101
Account 432105
While most users only have one account and would thus be well served by a "Customer" that maps to a "Top Level Account", we can handle the multi-top-level-account scenario using an optional id parameter passed to the customer query:
queryAccountQuery {
me {
customer {
accounts {
id
}
}
}
}
queryOtherAccountQuery {
me {
customer(id: "1234") {
accounts {
id
}
}
}
}
Notes
While we'd typically maintain but deprecate the existing "Relationship"-related types, we're currently only using it in a single unreleased project and will update that project to use the new "Customer" type.
Despite the above, we should still bump the minor version of the package.
The idea of "Relationship" seems to be a bit too abstract and leads to confusion as most of the APIs we're integrating use the concept of "Customer" and we find ourselves mapping those two conceptually.
Instead of using:
We'll use:
Note that we're still keeping the distinction between "me" (as the current user) and "customer" (me in my role as a user). This is still an open area for conversation but we'll try this version first.
We still need to handle the idea of "Top Level Accounts" that we've encountered at FIs (particularly credit unions), where they'll have a structure like:
In a previous project we mapped these conceptually to:
While most users only have one account and would thus be well served by a "Customer" that maps to a "Top Level Account", we can handle the multi-top-level-account scenario using an optional
idparameter passed to thecustomerquery:Notes