[Proposal] Add ability to issue GraphQL queries that will transform to Rapid

[wtrocki]

I went through the documentation and got some ideas. The main chance to get more coverage and love of the developers is to simplify some of the client-side work.

My thoughts

• Selection and expansions are very hard to write and unnatural.

• Batching in 2020 should be first-class citizen of every query transport. OData has very robust specification for batching however it is not as easy to use from frontend

• Developers can do $query with POST which is nice, but when target is to keep things simple it is challenging to get served multiple ways to work with the api.

This cannot be done in spec. There should be some implementation like Apache Olingo that will implement or address those concerns (unless spec will address this by using

Idea

As we have GraphQL based DSL maybe we could also explore adding a layer of graphql queries. Wrapping OData (and OpenAPI in general) is a very common use case with dozens of libraries for the client.

https://github.com/microsoftgraph/graphql-demo/

Even Microsoft tried something like this at some point. With additional translation layer to URLs we will get a number of benefits:

• Capabilities will be easy to write thanks to various GraphQL tools
• Batching, Expansion, arguments, filtering available in format that is easy to read and work with.
• Multiple features will be hidden in the translation layer so people will not need to explore them - they will just follow the GraphQL Document spec
• Full compatibility with OData always guaranteed thanks to transforming documents to rest queries.
• It can be delivered as command line tooling (Node.js) that will perform number of transformations for people.

[GEricson]

Maybe not now, but next logical step to specifying a model in RSDL is to making queries in RSDL and expressing payloads in RSDL. This feels like just another negotiated representation choice.

[wtrocki]

This has implications. What we have now is Dev time model that is not being used at runtime. If we decide that this would be wort considering it will be easier to keep RSDL at runtime - at least for reference implementation

[wtrocki]

I think we can:

1. Use GraphQL-Mesh - Developers can get their ODataAPI I have been working closely with Urigo so if there will be need for any changes we can commit them directly to the repository. Developers can use this as proxy if they want.

2. Work on the abstraction for filtering (the biggest change is to define what filters are available. For that we need to start with RDSL ability to define querability - similar to the directives we proposed for GraphQL based solution

3. If developers do not want to use this as a proxy we will provide GraphQLQuery to URL translation client that can be used as a simple client here (however we going to lose cache and graphql compatible responses. What I can think of is if we actually do it for some specific graphql client we can format Odata Responses to look like they came from the GraphQL server (that will be matter of removing some of the metadata and adding operation header. This library will be best to be done as separate repository.

[wtrocki]

CC @mikepizzo @ralfhandl

[mikepizzo]

Note that, for (1), we have added a tutorial (#301) for using GraphQL with RAPID via GraphQL Mesh. The current GraphQL Mesh ODataHandler passes through things like $filter and $top, but that may not be the way that we want to pass through such query refinements, in which case we would want to propose modifying this to address (2).

That leaves (3), defining a tool for converting GraphQL requests to OData URLs (and responses to GraphQL)