-
Notifications
You must be signed in to change notification settings - Fork 28
Initial GraphQL setup #53
Initial GraphQL setup #53
Conversation
* Make auto test work with typescript * Business logic for migrations * Overall migrations saga code * Make sure migrations stop after a failure * Implemented IdentityManagerChangeOwner Warning: This has only been tested in unit tests. * backup migration reducer actions * Implement proper deletion * Cleanup missing seed * Run cleanup as first step of PreHd migration * UpdatePreHDRootToHD migration * Create new seed before calling addowner * Update uPort Registry with new details * Fix tests for persona * Saving work * Improving logic of Migration screen * Improved Pending Migration checks * Fix updateIdentity reducer * Add Rouven Simulator * Fix failures * missed error * Always use root * Fix identity reset for HD * Complain if hdroot address is not the same as device address * Fetch FuelToken properly * Remove logging * Always "complete" process even if failed * Improve Migration Screen * Full Identity Migration works and extra checks are included * removed a few log statements * Better handling of odd transaction mining failures * Remove SIMULATE_ROUVEN feature * Fix error props & add debug info to Device * Update nonce during migration * Use resolve nonce for signing tx * Update tests * Update snapshots * Add unsigned tx to system messages
release-v405 v405
* support rpc parameter * Check if rpcUrl is valid
I think we will need mutations too if we are to use graphql as our proxy to SQLite. Eg. We would have a createClaimMutation and signClaimMutation. Essentially all our create actions like create identity, writing to BC all should be mutations. The nice thing about mutations is that the callback can be configured to refetch the resource and cache it. We can also do optimistic cache updates so the ui updates immediately and only changes if there’s a conflict. |
Another thing to consider for scalability (to cloud) is to have 2 graohQL proxy layers similar to how Prisma works. We have a database proxy that maps exactly to the database. The types describe the database 1:1 and then we have a application layer with app specific logic that sends its queries and mutations to the root database later. We can then just simply move the database layer to the cloud when the time comes. |
adding accessibility label for the left hand menu bar - used in local automation scripts
…estation-callback execute callback if callbackUrl is included in claim when adding attestation
* upgrade to typescript did resolvers * update uport-credentials
ebc83e3
to
c6c26b1
Compare
This sets up Apollo Client, React and the first iteration of a graphql schema.
root.ts
me
(currentIdentity),accounts
etclib/sagas/databaseSaga
to schemaWith this setup it should be easy to wire in the sql work from @simonas-notcat into the graphql schema.