vf-graphql issueshttps://lab.allmende.io/valueflows/vf-schemas/vf-graphql/-/issues2023-04-03T04:21:13Zhttps://lab.allmende.io/valueflows/vf-schemas/vf-graphql/-/issues/104Define query API for `Unit`2023-04-03T04:21:13ZpospiDefine query API for `Unit`Time to start thinking about specs for retrieving and managing `Unit` records and the [OM ontology](https://github.com/HajoRijgersberg/OM/). See https://github.com/h-REA/hREA/pull/387#issuecomment-1426941156 for more.
- [ ] Extend `Unit...Time to start thinking about specs for retrieving and managing `Unit` records and the [OM ontology](https://github.com/HajoRijgersberg/OM/). See https://github.com/h-REA/hREA/pull/387#issuecomment-1426941156 for more.
- [ ] Extend `Unit` records with an optional `sameAs` field (corresponding to http://owl.semanticweb.org/page/Owl:sameAs.html). This would allow the GraphQL API to reference not only OM units, but units from other vocabs as well.
- [ ] Add `filter` parameters to the `units()` query API so that `sameAs: [URI!]` can be used to select sub-sets of well-known units.
Other questions:
- Is `owl:sameAs` the correct relationship to be modeling, or is this more of an `rdfs:subClassOf` situation? I figure reasoning logic that makes any comparisons is going to have to recursively fetch and compare all references either way (eg. an `hour` in the coffee shop's network is `sameAs` an `hour` in the bakery's network which is `sameAs` the OM2.0 'hour' term).
- Is one relationship (`sameAs: URI`) sufficient, or would we prefer multiple (`classifiedAs: [URI!]`)?
- Should `sameAs` return a self-referential URI to its own `Unit` record if no value is assigned? Should this be queryable for custom units?Lynn FosterLynn Fosterhttps://lab.allmende.io/valueflows/vf-schemas/vf-graphql/-/issues/102Finalise API for location-based queries2022-06-20T01:35:44ZpospiFinalise API for location-based queriesThere are a number of `withinLocation` queries defined in the document attached [here](https://lab.allmende.io/valueflows/vf-schemas/vf-graphql/-/issues/84#note_39817).
We need to implement these, and decide on an appropriate API format...There are a number of `withinLocation` queries defined in the document attached [here](https://lab.allmende.io/valueflows/vf-schemas/vf-graphql/-/issues/84#note_39817).
We need to implement these, and decide on an appropriate API format for querying them.https://lab.allmende.io/valueflows/vf-schemas/vf-graphql/-/issues/95Remove ability to edit `EconomicResource.containedIn`2022-02-09T03:04:31ZpospiRemove ability to edit `EconomicResource.containedIn`The new way of modifying this attribute is via the `pack` and `unpack` actions.The new way of modifying this attribute is via the `pack` and `unpack` actions.https://lab.allmende.io/valueflows/vf-schemas/vf-graphql/-/issues/94Add descriptions for mutation parameters2022-01-24T02:44:26ZpospiAdd descriptions for mutation parametersJust had the feedback from @Connoropolous whilst [tinkering with](https://hackmd.io/@connoropolous/B1B5qAIpK) the hREA GraphQL explorer that these would assist newcomers a lot.
Some description of how to retrieve the builtin actions whe...Just had the feedback from @Connoropolous whilst [tinkering with](https://hackmd.io/@connoropolous/B1B5qAIpK) the hREA GraphQL explorer that these would assist newcomers a lot.
Some description of how to retrieve the builtin actions when they must be provided would also be worth adding.https://lab.allmende.io/valueflows/vf-schemas/vf-graphql/-/issues/90Finalise connection filtering parameters2021-12-13T09:43:33ZpospiFinalise connection filtering parametersImplementations (Bonfire, hREA & potentially others) need to determine the appropriate filtering parameters for each record type and query edge.
Bridging schemas for `*.filtering.gql` need to be created to provide a `filter` parameter, ...Implementations (Bonfire, hREA & potentially others) need to determine the appropriate filtering parameters for each record type and query edge.
Bridging schemas for `*.filtering.gql` need to be created to provide a `filter` parameter, and the fields of these input types should be well documented in the spec to indicate to implementations how they should behave. Some fields will have complex logic - for example, `EconomicEvent.hasPointInTime` and `EconomicEvent.hasBeginning` might want to be matchable by a parameter `"startTime"`, and that parameter might want to accept logical operators like `<=`, `>=`, `==` etc.
A start has been made on `planning.filtering.gql`, which can be used as a template for the other modules.
See related issues #72, #82 & #85 for more fine-grained decisions & discussion regarding filtering.https://lab.allmende.io/valueflows/vf-schemas/vf-graphql/-/issues/88Add spec for revision handling2022-06-08T07:48:44ZpospiAdd spec for revision handlingFollowing #87, there needs to be a core specification for handling conflicting data and access to prior revisions in eventually consistent architectures.
All UIs (regardless of whether the backend implements such features) will need to ...Following #87, there needs to be a core specification for handling conflicting data and access to prior revisions in eventually consistent architectures.
All UIs (regardless of whether the backend implements such features) will need to implement these interfaces in order to be considered "fully compatible" with the spec. This implementor burden should be kept as minimal as possible; ergo the smallest number of additional fields and simplest application logic should be favoured.pospipospihttps://lab.allmende.io/valueflows/vf-schemas/vf-graphql/-/issues/84Standardize paginated queries2022-06-20T01:35:45ZMayelStandardize paginated queriesThis is the approach we currently take with CommonsPub, it would be good if we could standardise to use compatible queries between apps
Query:
` intentsPages(limit: Int, before: [Cursor!], after: [Cursor!]): IntentsPage!`
Return Type:...This is the approach we currently take with CommonsPub, it would be good if we could standardise to use compatible queries between apps
Query:
` intentsPages(limit: Int, before: [Cursor!], after: [Cursor!]): IntentsPage!`
Return Type:
`type IntentsPage {
edges: [Intent!]!
pageInfo: PageInfo!
totalCount: Int!
}`
PageInfo type:
`type PageInfo {
endCursor: [Cursor!]
hasNextPage: Boolean
hasPreviousPage: Boolean
startCursor: [Cursor!]
}`
`Cursor` is a scalar defined as an opaque position marker for pagination. Paginated queries return a PageInfo struct with start and end cursors (which are actually lists of Cursor). You can then issue queries requesting results before the start or after the end cursors to request the previous or next page respectively.
It's actually a string or integer. May be extended in future.MayelpospiMayelhttps://lab.allmende.io/valueflows/vf-schemas/vf-graphql/-/issues/71Finish schema documentation2020-03-02T05:33:27ZpospiFinish schema documentationhttps://github.com/valueflows/vf-graphql/pull/69 made huge progress; now the input type documentation is to an equivalent standard to the query types, and that helps greatly since these are generally the first structs newcomers encounter...https://github.com/valueflows/vf-graphql/pull/69 made huge progress; now the input type documentation is to an equivalent standard to the query types, and that helps greatly since these are generally the first structs newcomers encounter in GraphQL playgrounds (they have to create data before they can query it!).
There are still some holes that it would be good to have coverage on:
- [ ] top-level query methods
- [ ] top-level mutations: mutation & parameter descriptions (only fields are currently documented, not types)
- [ ] input types (again, only fields are documented- not the structs themselves)https://lab.allmende.io/valueflows/vf-schemas/vf-graphql/-/issues/68Use `extends` syntax in bridging schema modules2020-02-12T05:43:23ZpospiUse `extends` syntax in bridging schema modulesAs of June 2018 GraphQL supports extending types with other fields, which would make the schemas in `schemas/bridging/` more idiomatic in the way they're written. Would be worth doing this, if the merging logic being used supports the ch...As of June 2018 GraphQL supports extending types with other fields, which would make the schemas in `schemas/bridging/` more idiomatic in the way they're written. Would be worth doing this, if the merging logic being used supports the changes.
Further reading https://stackoverflow.com/a/56204966https://lab.allmende.io/valueflows/vf-schemas/vf-graphql/-/issues/67Polish schema compilation process2020-02-12T04:34:44ZpospiPolish schema compilation processThere are some rough edges around #61 that could be worth adding.
- [ ] infer from `@depends` tags in file header comments and throw warnings if dependant modules are not specified
- [ ] create a CLI script to generate SDL schema fil...There are some rough edges around #61 that could be worth adding.
- [ ] infer from `@depends` tags in file header comments and throw warnings if dependant modules are not specified
- [ ] create a CLI script to generate SDL schema files from dynamic combinations of schema moduleshttps://lab.allmende.io/valueflows/vf-schemas/vf-graphql/-/issues/63Add ProcessSpecification.conformingProcesses2020-06-01T02:33:58ZpospiAdd ProcessSpecification.conformingProcessesThere needs to be a way to query all `Processes` via the specification that defines their behaviour, in order to locate all processes of a given type.
The `conformingProcesses` need to be filterable by many criteria, TBC...There needs to be a way to query all `Processes` via the specification that defines their behaviour, in order to locate all processes of a given type.
The `conformingProcesses` need to be filterable by many criteria, TBC...https://lab.allmende.io/valueflows/vf-schemas/vf-graphql/-/issues/51Setup build system for reference website & publish2019-08-21T04:40:32ZpospiSetup build system for reference website & publishThe easiest way to do this would be to modify the [GraphQL Voyager](https://github.com/APIs-guru/graphql-voyager) UI to be built as a static site rather than using the express middleware, and deploy that on a `gh-pages` branch. We'd need...The easiest way to do this would be to modify the [GraphQL Voyager](https://github.com/APIs-guru/graphql-voyager) UI to be built as a static site rather than using the express middleware, and deploy that on a `gh-pages` branch. We'd need to:
- modify the setup to use `react-scripts` and the raw Voyager [React component](https://github.com/APIs-guru/graphql-voyager#using-as-a-dependency) instead of `graphql-voyager/middleware`
- setup a static build of the schema introspection query via some of the `graphql-tools` [utilities](https://blog.apollographql.com/three-ways-to-represent-your-graphql-schema-a41f4175100d) (see `graphqlSync`)
- setup a static build of the site with `react-scripts` which also inlines the introspection query result
@fosterlynn @bhaugen does this sound like (at least a part of) the correct course of action to you? Then that UI can be published to valueflows.github.io/vf-graphql and linked to from the main site as needed (you can preview with `npm start` by navigating to http://localhost:3000/viewer).pospipospihttps://lab.allmende.io/valueflows/vf-schemas/vf-graphql/-/issues/50Decide on spec for record subscriptions API & implement as optional schema mixin2019-08-21T04:43:29ZpospiDecide on spec for record subscriptions API & implement as optional schema mixinThese are a new root-level query type with their own resolvers that return subscriptions via Apollo [PubSubEngine](https://github.com/apollographql/graphql-subscriptions/blob/master/src/pubsub-engine.ts) interfaces.
We need to decide ...These are a new root-level query type with their own resolvers that return subscriptions via Apollo [PubSubEngine](https://github.com/apollographql/graphql-subscriptions/blob/master/src/pubsub-engine.ts) interfaces.
We need to decide on what the appropriate subscription names are for listening to different record updates, and what the most ergonomic way of integrating these with other query results is.