trabian / banking-api Goto Github PK

Integrate https://github.com/typicode/lowdb to allow both database and memory storage of the mock data.

Ultimately I'd also like to be able to automate the deployment of npm packages from CI.

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)

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:

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.

https://github.com/trabian/banking-api/blob/bd8396742375393bd6a50b5de87be35cf5c5ab4a/packages/mock-data-generator/src/merchants.js

Sky's the limit - whatever you think would be helpful, @treeme.

This was mentioned in a GraphQL design tutorial that Shopify put out and makes sense to me:

First a quick note on naming: you'll notice that we named all of our mutations in the form collection rather than the more naturally-English Collection. Unfortunately, GraphQL does not provide a method for grouping or otherwise organizing mutations, so we are forced into alphabetization as a workaround. Putting the core type first ensures that all of the related mutations group together in the final list.

Rule #17: Prefix mutation names with the object they are mutating for alphabetical grouping (e.g. use orderCancel instead of cancelOrder).

Let's update the mutation names within this project, both the schemas within graphql-types and in the packages leveraging those schemas (a find-and-replace should work).

GraphQL Schema Design: Building Evolvable Schemas – Apollo GraphQL

https://dev-blog.apollodata.com/graphql-schema-design-building-evolvable-schemas-1501f3c59ed5

Our responsible spender will have money left over after most paychecks. This should go into a savings account which can optionally have an interest rate.