Create Proxy backend collection and UI for mandatory fields

[bajiat]

In order to decouple API backends from Api Umbrella, we will need a collection and schema for proxy Api settings (currently only Umbrella ) settings that is separate from "pure" API backend settings/details. As a first step, this collection will contain the mandatory API Umbrella fields like backend and frontend prefix, backend host URL.

For the UI, we can either add a Proxy tab or a partial view in Settings tab to connect the API to a proxy to and to configure the backend.
The page should have a possibility to select an existing API proxy and define the backend configuration. Use the opportunity to explain frontend and backend prefix in a more user friendly manner, possibly selecting new terminology.
The tab/view should be only available if platform administrator has created a proxy and it is only shown to administrators and the API manager

Definition of done

• Collection and schema
  • There is a collection for Proxy API backend
  • There is a schema for Proxy API Backend
  • The collection is connected to Api Umbrella
  • The schema contains all mandatory API Umbrella fields
  • The schema is aligned with Api Umbrella
• UI
  • There is a form for backend settings either in settings or in its own tab
  • Proxy tab or partial view for selecting proxy exists
  • Ensure inline help text clarifies the meaning of each field
  • Optionally, come up with easier terms for frontend and backend prefix
• When the settings are saved, a relational link is made between API backend document and Proxy API backend document

Wireframe

[brylie]

After discussion, we decided to name the Proxy APIs collection ProxyApis. We are not clear on how the schema will be structured, but have some initial thoughts:

# ProxyApis
- apiId
- proxyId
- settings
  - apiUmbrella [apiUmbrella_Backend schema]
    - rate_limiting

[jykae]

For future reference Kong API object schema: https://getkong.org/docs/0.9.x/admin-api/ Look section "API object" fields we need for Kong API schema.

[brylie]

@frenchbread right now we need to remove references to Kong/Tyk from the code and user interface. The form can keep the dynamic functionality, but should only allow the user to select API Umbrella. Default the selection to API Umbrella, if possible.

[frenchbread]

@brylie How can we implement this? I was able to set the default selection (apiUmbrella) for the selectbox, but it did not force autoform automatically render APIUmbrella schema.

[brylie]

Hm, it seems harder than I thought. How did you set the 'type' field default value? Did you do it via the schema?

[brylie]

Lets ask @bajiat for input here.

[brylie]

Comments from chat:

• remove the API Umbrella settings from the initial setup wizard.
• For now, remove the dynamic toggle.
  • Rather, just include the apiUmbrella.settings field and sub-fields directly in the AutoForm.
• Hide the 'type' field from view
  • default the value to apiUmbrella in the schema.
• add inline help texts and icons for manditory fields.
  • Check if the setup wizard contains help text strings, and use those in your Proxy form.

[bajiat]

Note: Discussion in this issue is related to Proxy settings (adding a proxy to the deployment/platform) and not backend settings, but the issue itself is about connecting a single API to a proxy.

[brylie]

@Nazarah here are the manditory fields:

"name": {
    type: String,
    optional: true
  },
  "frontend_host": {
    type: String,
    optional: true
  },
  "backend_host": {
    type: String,
    optional: true
  },
  "backend_protocol": {
    type: String,
    optional: true
  },
  "balance_algorithm": {
    type: String,
    optional: true
  },
  "url_matches": {
    type: [Object],
    optional: true
  },
  "url_matches.$.frontend_prefix": {
    type: String,
    optional: true
  },
  "url_matches.$.backend_prefix": {
    type: String,
    optional: true
  },
  "servers": {
    type: [Object],
    optional: true
  },
  "servers.$.host": {
    type: String,
    optional: true
  },
  "servers.$.port": {
    type: Number,
    optional: true
  }

[brylie]

Here is a current screenshot of the AutoForm based on the above schema:

[brylie]

@Nazarah here are brief descriptions of the fields:

• name: a human friendly name for the Proxy API
• frontend_host: server address for the Proxy (might not be on the form)
• backend_host: URL of the API server
• backend_protocol: protocol to access API (e.g. HTTP or HTTPS)
• balance_algorithm: how the load balancer should balance traffic
• url_matches: path prefixes from the Proxy and API
  • frontend_prefix: prefix added to the Proxy path in all requests
  • backend_prefix: prefix added to the API path in all requests
• servers: one or more servers responsible for handling API traffic (probably for load balancing)
  • host: URL where the API server can be accessed
  • port: port number where the API service is running

[Nazarah]

thanks @brylie !
I am adding the descriptions for INFO icons as per the fields given in your earlier screenshot.
As suggested, I changed the "frontend to "Proxy" and "backend" to "API"

Name: "Give a human friendly name to identify your proxy API." [feedback: we can skip info for this field. Not urgently needed.]

Proxy host: "Add the server URL for your proxy API."

API host: "Add the server URL for your API."

Load balancer algorithm: "Mention the procedure to balance the load of API calls made." [feedback: any alternatives?]

Proxy Prefix: "The added prefix will be available in the proxy path of all requests. Example: "

API Prefix: "The added prefix will be available in the API path of all requests. Example: "

Host: "Add the URL from which the API server can be accessed."

Port: "Add the port number of the server in which the API service is running."

[brylie]

Based on @Nazarah's text suggestions and discussions with @jykae and @bajiat, here is the ProxyBackend form on the API Proxy tab: