Closed pospi closed 2 years ago
Implementing this will require extending the GraphQL spec with hREA-specific methods, which has not been done yet.
Upon reflecting on the current codebase it seems best to add these extensions within the existing modules/vf-graphql-holochain
since they will be needed for any hREA client application.
This work plan is a draft, but hopefully will hold up as we work through it-
schema-extensions.js
and export a string wrapping the above method with Mutation { ... }
hreaExtensionSchemas
extensionSchemas
before passing into makeExecutableSchema
on line 63 (not on line 44, which would allow it to be overridden)modules/vf-graphql-holochain/mutations/agent.ts
. It is fine to do this here since the custom schema extension will always be included.test/init.js
, remove the direct import of the pre-compiled ALL_VF_SDL.js
and replace it with the same code now used with makeExecutableSchema
in the vf-graphql-holochain module (printSchema(buildSchema(...
)
This is an replacing #302 needed for compatibility with the GraphQL spec.
After some discussion with @mayel and the Bonfire team we have decided that signup / authorisation flows are too technology-specific to become part of the core spec. Bonfire has several custom API endpoints that deal with registration, authentication and authorisation; in their case specifically
createUser
transparently creates an REAAgent
and other linked records.hREA will need to do things differently, given there is no notion of "registration" in Holochain. It doesn't matter much how we deviate in these registration actions, so long as it all results in the
myAgent
query returning what has been associated with the active authentication. It is also true that any UI components built for signup & login will be technology-specific, so there is little point in standardisation in this area. GraphQL should ideally treat authorisation & authentication transparently in any case.On this basis we should add this custom GraphQL mutations for hREA only:
...but the first one is ideal since it has the greatest flexibility to allow for #310 in future.