Graphql

[jgrund]

Implement Experimental GraphQL support

This change is 

[jgrund]

This patch adds two new endpoints:

/graphql - Accepts a POST and data as described in https://graphql.org/

/graphiql - Loads an interactive query visualizer in the browser.

[johnsonw]

This effectively gives a default it looks like. Seems like a good solution to having to explicitly specify a limit/direction on every call.

[jgrund]

This is just docs for the query browser. The default is due to the unwrap_or calls within this fn.

[mkpankov]

Reviewed 8 of 8 files at r1.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @jgrund and @johnsonw)

---

chroma-manager.conf.template, line 226 at r1 (raw file):

        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass {{IML_API_PROXY_PASS}}/graphiql;
    }

Why no compression here?

---

iml-api/src/graphql.rs, line 62 at r1 (raw file):

Previously, jgrund (Joe Grund) wrote…

This is just docs for the query browser. The default is due to the unwrap_or calls within this fn.

In theory, could we just accept same JSON with limit, offset and direction and not use GraphQL here? Just trying to understand what does GraphQL bring in specifically.

[jgrund]

---

chroma-manager.conf.template, line 226 at r1 (raw file):

Previously, mkpankov (Michael Pankov) wrote…

Why no compression here?

I'll add in a follow-on

[jgrund]

---

iml-api/src/graphql.rs, line 62 at r1 (raw file):

Previously, mkpankov (Michael Pankov) wrote…

In theory, could we just accept same JSON with limit, offset and direction and not use GraphQL here? Just trying to understand what does GraphQL bring in specifically.

Yes, we could do the same with query string params.

currently, the biggest draws are:

1. API Documentation generated from code (which is very important for external consumers)
2. A query explorer
3. A consistently enforced way to structure endpoints
4. The ability to request just the data that is needed from clients

Of all of those, the ability to generate extensive documentation (which we will need to stay on top of) is the most important imo.

[jgrund]

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @johnsonw)

---

iml-api/src/graphql.rs, line 62 at r1 (raw file):

Previously, jgrund (Joe Grund) wrote…

Yes, we could do the same with query string params.

currently, the biggest draws are:

1. API Documentation generated from code (which is very important for external consumers)
2. A query explorer
3. A consistently enforced way to structure endpoints
4. The ability to request just the data that is needed from clients

Of all of those, the ability to generate extensive documentation (which we will need to stay on top of) is the most important imo.

Done.