Data access panel: graphql API

[dmitriy-borzenko]

Create graphql API for support Data access panel.

Initial developments according to the API schema(prototype):

type DataQueries {
  """
  Lists protocols known to the system and recommended for use
  """
  knownProtocols: [ProtocolDesc!]!
}

type ProtocolDesc {
  description: Protocols!
}

union Protocols = LinkProtocolDesc | CliProtocolDesc | RestProtocolDesc
                     | FlightSqlDesc | JdbcDesc |  PostgreSqlDesc | KafkaProtocolDesc | WebSocketProtocolDesc  | OdataProtocolDesc

type LinkProtocolDesc{
  webUrl: String!
}

type CliProtocolDesc {
  pullUrl: String!
  pushUrl: String!
}

type RestProtocolDesc {
  lastEventsUrl: String!
  arbitraryUrl: String!
  pushUrl:String
}

type FlightSqlDesc: {
   url: string!
}

type JdbcDesc: {
   url: string!
}

type PostgreSqlDesl: {
   url: string!
}

type KafkaProtocolDesc {
   url: string!
}

type WebSocketProtocolDesc {
   url: String!
}

type OdataProtocolDesc {
  endpointUrl: String!
  collectionUrl: String!
}

[sergiimk]

Note that for ProtocolDesc schema I would suggest to implement elements at the level of individual protocols rather than groups or flavors.

For example instead of a group like StreamProtocolUrls I would prefer to have:

• KafkaProtocolDesc
• WebSocketProtocolDesc

and instead of SqlProtocolUrls something like:

• AdbcProtocolDesc
• JdbcProtocolDesc
• PostgresProtocolDesc etc.

The grouping of different protocols into flavors like "Stream" and "SQL" can be left to UI.

Please design schema first and include me in review.

[dmitriy-borzenko]

Changed schema, please review @sergiimk

[s373r]

I'd like to add my two cents:

1. Q: Do we need a type that wraps Protocols? Or is this for the future, since the ProtocolDesc type is planned to be extended?
2. I would like to suggest in LinkProtocolDesc to rename webUrl to url, for parity with other types

[s373r]

In terms of implementation:

~~- I plan to add --domain (kamu system api-server --domain) which will be used to generate URLs~~ ~~- Passthrough domain value through the value object inside cli_catalog~~ KAMU_BASE_URL env var will be added

~~- Extend QueryService with get_known_protocols()~~ we don't need a separate service for preset values

---

Since this will be my first work in the field of GrapthQL I provide extra details

[s373r]

Got a comment from @zaychenko-sergei that it's better to use an environment variable -- no problem

[s373r]

Schema-related

Since, we need to know which dataset it is and who owns it in order to display (combine) URL mapping for a dataset, a "move" from DataQueries to Dataset scope will be performed.

Since we plan to query all protocols, in order to avoid complex queries [1] (since our data is heterogeneous), I would like to propose that protocols from the collection be organized into specific fields.

The proposed new home for knownProtocols: [ProtocolDesc!]! will be Dataset - Endpoints:

type Dataset {
    ..
    endpoints: DatasetEndpoints!
}

type DatasetEndpoints {
    webLink: LinkProtocolDesc!
    cli: CliProtocolDesc!
    rest: RestProtocolDesc!
    flightsql: FlightSqlDesc!
    jdbc: JdbcDesc!
    postgresql: PostgreSqlDesl!
    kafka: KafkaProtocolDesc!
    websocket: WebSocketProtocolDesc!
    odata: OdataProtocolDesc!
}

---

[1] We continually need to specify which one of the union it is.