-
Notifications
You must be signed in to change notification settings - Fork 0
Change "Relationship" to "Customer" #42
Description
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:
query AccountQuery {
me {
relationship {
accounts {
id
}
}
}
}We'll use:
query AccountQuery {
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)
- Account 1234
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
- Top Level Account 1234 (or "Account Group")
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:
query AccountQuery {
me {
customer {
accounts {
id
}
}
}
}
query OtherAccountQuery {
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.