Feature Request: allow GraphQL instead of Elasticsearch

[csepulv]

Issue Type: enhancement
Platform: both Web and Native

Description:
This is a great library with a rich set of filter/facet widgets and a mechanism to add your own. I'd like to use it with other backends besides elasticsearch and it seems graphql might be a way to support a variety of backends.

Have you ever considered adding graphql as an option for the underlying queries?

[romainquellec]

Nice timing, I was just thinking the same !
Any plan on that ?

[metagrover]

Guys, the timing is spot on. We have been internally discussing about it and thinking about the feasibility. We will keep you posted on this!

[siddharthlatest]

@romainquellec @csepulv Do you have ideas on how this mapping might look like?

[csepulv]

It would seem aggregations might be the tricky part. It seems graphql has no plans to support them directly: graphql/graphql-js#855

There are things like https://github.com/blueflag/graphql-aggregate, but that isn't necessarily a standard.

Are you asking about how a user would denote their mapping or the expectation on how component field mappings would translate to graphql queries?

[csepulv]

While I think about this too, a starting place might be to see how the GitXplore demo would map to GitHub's GraphQL, instead of the elasticsearch that it currently uses.

https://developer.github.com/v4/

[siddharthlatest]

@csepulv We don't use the Github APIs for GitXplore - except in a worker which keeps indexing new repository data.

The interesting use-case is whether it makes sense for us to have a GraphQL wrapper over the Elasticsearch query DSL. Doing so can offer security benefits similar to adding a backend proxy, with the added (possible) ease of working with other backends a user may have.

Currently though, it seems to me that we would end up creating just another DSL that will need maintenance as the fine-grained querying and aggregations features present in Elasticsearch can't be added without some non-standard GraphQL and will almost always require a fallback to Elasticsearch.

Prisma is an interesting project that is trying to tackle this problem -
https://github.com/graphcool/prisma/. It looks like WIP atm.

[csepulv]

I understand supporting GraphQL might not make sense.

What about possible changes to https://github.com/appbaseio/reactivecore so third parties could add support for GraphQL or even SQL.

Honestly, I have no idea what those changes might be. I can give it some thought if you are open to the idea. But I also understand and respect if that direction doesn't make sense the project.

[siddharthlatest]

@csepulv That is a good point. I am definitely curious about learning more on how and where we can support something like GraphQL.

One use-case I see is that of supplementing the data present within ES - a user may have additional data present in other DBs, APIs that they may want to show in their ReactiveSearch built UIs. I would love to hear more concrete use-cases or other possible benefits it may bring.

However, when the entire data can reside within ES - it almost always makes more sense to use it rather than a wrapper like GraphQL around it.

---

As far as possible changes required to do this go, we would have to start by defining scalar types (term for composite data types in GraphQL) and resolvers for all the queries and aggregations we currently use in the library.

Each component can then have a pre-defined GraphQL query (similar to the ES query) with an option allowing the user to extend it. And each component can be set to one of graphql / es mode -- which decides which query will be fired for it. This also allows for incrementally building up the GraphQL layer.

[csepulv]

I agree that concrete use cases should drive this. And at the moment, I don't have too much that is very specific. In part, I started this thread as a curiosity. I was going to prototype a search UI for something that has data already in a SQL database. If GraphQL was supported, that seemed like a "meet in the middle" option as there are various tools to provide a GraphQL layer on top of a SQL source.

While I could sync that data to elastic for search, I would prefer to avoid that overhead for a prototype. I am not sure what would make the most sense for a real app/production, as I can imagine tradeoffs either way.

I will see if I can get some time to come up with something more concrete. We could either close this for now and I would submit a new issue later, or leave this open for a little while.

[Jscott388]

I been using Mongodb with graphql. I installed a package along with it that gives me the filters, projections, and options. I am able to filter anything I want using the common comparisons, like greater than, greater than equal, etc. I’m also able to define what I want to sort and so on. That being said, I just don’t have a friendly way to build the UI out. This would be great if I could use reactive search and somehow map it to the variables in my graphql query schema.

So for example, a real estate app I’m building:

$type: String, $pricelow: Number, $priceHigh: Number, $beds: Number. $propertyType: Number.

Those are just a few items that I would pass into my query in the client side.

The backend would handle the rest with the package I have install. I’ll link it later (I’m on a mobile device)..

But since the UI is client side, how hard would it be to modify it to match the variables that I pass in?

Note: if the the variable is empty. Such as City for example, I didn’t list it, but it would omit the city being passing in to the variable of the graphql query.

[spencern]

Any recent updates or thoughts about supporting GraphQL?

[siddharthlatest]

@spencern We haven't been able to spend a lot of time on this. Once we have v3 spec out which includes major enhancements and React future compatibility, we will be looking into this again. Timeline wise, we want to get to this by Q1 '19.

Any ideas/specs or an example component support are helpful in getting this kickstarted sooner.