Project Haystack Rest API supporting predefined ops/filters may be implemented with GraphQL?. I feel its best fit for Haystack data model and has other benefits too. Any thoughts on this?
Brian FrankWed 14 Nov 2018
I think it would probably more make sense to expose a Haystack server as GraphQL in parallel to the REST API - they are really different beasts. But might be interesting to try and standardize how GraphQL might be used with Haystack data. But not sure how the type systems would combine - some of the stuff we are doing in WG 551 might be used to generate your GraphQL schema.
Patrick CoffeyThu 15 Nov 2018
We've implemented a static GraphQL schema and I found it to complement the REST API. We essentially wrapped read and hisRead ops and found it to be quite useful/powerful in some cases while improving on client over-fetching/under-fetching. We also built support for recursive filtering which has been handy. We don't yet see a need to implement mutations or subscriptions in place of hisWrite, watchSub etc.
Justin ScottTue 11 Dec 2018
I was just coming to the forums to see how things were going and myself have been using GraphQL as of late. I came to the same conclusion that the Meta-Model on which Haystack is structured fits well in the context of the GraphQL Schema and Resolvers. I'd be happy to work with any interested folks on getting an open pass at this. I currently use NestJS (Not sure if linking is allowed but google works), Typescript and GraphQL.
I also looked into the WG on Types as well. I believe with Typescript typing for Haystack (Happy to work with anyone interested on this as well) as the ability to create custom scalar types in GraphQL would allow typing of the data in the schema very portable. This can translate with the NestJS platform for keeping backwards compatibility with the traditional RESTful API spec as well by using controllers and Swagger OpenAPI definitions.
I see plenty of use cases for this and a bigger use case for a community driven open-source, nuts and bolts included implementation that reaches an audience geared towards the IoT space.
Sivamurugan S Wed 14 Nov 2018
Project Haystack Rest API supporting predefined ops/filters may be implemented with GraphQL?. I feel its best fit for Haystack data model and has other benefits too. Any thoughts on this?
Brian Frank Wed 14 Nov 2018
I think it would probably more make sense to expose a Haystack server as GraphQL in parallel to the REST API - they are really different beasts. But might be interesting to try and standardize how GraphQL might be used with Haystack data. But not sure how the type systems would combine - some of the stuff we are doing in WG 551 might be used to generate your GraphQL schema.
Patrick Coffey Thu 15 Nov 2018
We've implemented a static GraphQL schema and I found it to complement the REST API. We essentially wrapped read and hisRead ops and found it to be quite useful/powerful in some cases while improving on client over-fetching/under-fetching. We also built support for recursive filtering which has been handy. We don't yet see a need to implement mutations or subscriptions in place of hisWrite, watchSub etc.
Justin Scott Tue 11 Dec 2018
I was just coming to the forums to see how things were going and myself have been using GraphQL as of late. I came to the same conclusion that the Meta-Model on which Haystack is structured fits well in the context of the GraphQL Schema and Resolvers. I'd be happy to work with any interested folks on getting an open pass at this. I currently use NestJS (Not sure if linking is allowed but google works), Typescript and GraphQL.
I also looked into the WG on Types as well. I believe with Typescript typing for Haystack (Happy to work with anyone interested on this as well) as the ability to create custom scalar types in GraphQL would allow typing of the data in the schema very portable. This can translate with the NestJS platform for keeping backwards compatibility with the traditional RESTful API spec as well by using controllers and Swagger OpenAPI definitions.
I see plenty of use cases for this and a bigger use case for a community driven open-source, nuts and bolts included implementation that reaches an audience geared towards the IoT space.