Add GraphQL Endpoint - REST handler to accept graphQL requests

[YANG-DB]

What ?
Add GraphQL endpoint for receiving graphQL queries

Steps

• Select java GraphQL framework -
  -- https://github.com/chentsulin/awesome-graphql#java-examples
  -- https://github.com/graphql-java/awesome-graphql-java

• Add Rest Handler

• Add Validation

• Parse query

• Dispatch request to appropriate GraphQL controller

• Process the query

• Submit response

First stage

• Support 'Get Schema' request

{
  __schema {
    queryType {
      fields {
        name
      }
    }
  }
}

checkout https://docs.github.com/en/graphql/guides/introduction-to-graphql#discovering-the-graphql-api

[Swiddis]

Had some discussion about the different handlers and their roles. The main takeaways are that there will be three primary endpoints:

• The object store endpoint /object stores all parts that make up a GraphQL schema: types, queries, and inputs. Validation should ensure that the schema parts are all valid on their own: they will be composed into a full schema later. This is already implemented but missing validation.
• The schema endpoint /domain stores GraphQL schemas. These are immutable compositions of objects, and allows the user to describe data and queries. An open question is if this will also contain logic to describe Schema-Index mappings or if that will be separate. Validation should be at the schema level.
• The GraphQL endpoint /graphql will handle Queries, Mutations, and Subscriptions. This should act on top of a defined schema. The initial groundwork for this endpoint was laid in Add Skeleton for GraphQL Rest Endpoint #23. Validation should check against the target schema.

A big point is that GraphQL engines should be maintained in-memory to validate and execute queries. These are computed based on schemas. For consistency and validation, the schema objects should be immutable once created, so updating a schema should involve an explicit create-migrate-delete process. To manage and cache engines, a special manager object should be written later.

Some short-term future work is to add functionality to:

• Be able to configure the plugin to use a specific schema.
• Be able to configure the plugin to handle a simple data ingestion use case.
• Define better separation in-code between physical data storage and logical query representation.

Another open question for later is what internal representations to translate to, in order to execute queries. The main choices are DSL and SQL. DSL has the advantage of being the native OpenSearch format but has relatively limited functionality making representation generation harder. SQL is more flexible and ubiquitous, but it's likely to involve more work upfront. The two have similar performance.