Graffiticode + GraphQL

1

Motivation for using GraphQL as a programming interface for Graffiticode.

  • Graffiticode is a language oriented interface to task centric web services.
  • GraphQL is a language oriented interface to data centric web services.
  • Graffiticode allows developers to compose pipeline of tasks that generate data.
  • GraphQL allows developers to write queries that compose and filter data.

Using GraphQL as an API for Graffiticode gives developers request-time control over the data returned for a given compile. Equally important is that using GraphQL allows us to leverage the extensive ecosystem of tools and expertise that has grown up around GraphQL.

For example, every Graffiticode SDK could just be a GraphQL SDK, for which there is one in every conceivable programming language. Also, we can use the GraphiQL Explorer to integrate our API into the Console and documentation.

GraphQL is self-documenting. Graffiticode aspires to be self-documenting. By self-documenting we mean that the type system is used to generate API documentation, as well as code hints and suggestions.

GraphQL Explorer uses CodeMirror. Graffiticode uses CodeMirror. We can learn from how GQL implements its mode and coding tools.

1 Like
2

I really like the idea, but I’m especially excited about the community support and the tooling around GraphQL

Re: developers request-time control over the data returned for a given compile

I would like to explore this more. The limited amount I know from GraphQL and some of the request time data masking. I’m not sure how it connects all together with how we pipeline tasks to data. I don’t think it excludes it. I just don’t have a good mental model yet

3

My idea is that you would write tasks using the GC task editor, or call to POST /task, or the GQL equivalent, and use a query like this

{
   data(id: `${id1}+${id2}+${id3}`) {
      field {
         subfield
      }
   }
}

We can dynamically generate the schema based on the computed data. I’ve done this for at least one language that used GQL to filter data. Here is some code that does this. And here is it in action.

4

Clearly that won’t work, since we don’t have the data for the identifier yet. Not sure it pays for itself, but we could do something like this:

type Query {
  data(id: String!, query: String!): String!
}

{
  "id": "abc123+xyz456",
  "query": "{ field { subfield } }"
}

where the resolver for data gets the data, constructs a schema for it, applies the query, and stringifies it.

Okay. This doesn’t make sense. GraphQL isn’t a fit with GC API. But one can imagine other uses in the app frontend. Or as a language, like L137 that gets data piped to it.

5

I’m reviving this idea.

If each language defines a json schema for its compiler output, then we can construct a gql schema from that json schema. We already do this for the v2 languages.

E.g. here is the schema for L0002:

{
  "$schema": "",
  "$id": "",
  "title": "L0002",
  "description": "A starter language",
  "type": "object",
  "properties": {
    "hello": {
      "description": "The person, place or thing being greeted",
      "type": "string",
    },
    "theme": {
      "description": "Light or dark theme",
      "type": "string",
      "enum": ["light", "dark"],
    }
  },
  "required": ["hello"]
}