LogScale collects server logs and related metrics to provide the ability to monitor server activity, identify security breaches/attacks, improve server performance, and more.

Consider this example using the fictional GraphQL query thing(). In this example, consider that this query confirms that a given "thing" exists in a list of "things" in LogScale. Its syntax might look something like this:

thing( name: string! 
         ): boolean

GraphQL syntax shows what input is necessary in parentheses, and the input is always given as a key and a value. Here, the key is name, where the name of the element is provided, and the value is a string, provided in double quotes.

The exclamation mark appended to 'string' is an important detail. This indicates a required value, and is automatically supplied by the system. Similarly, a colon appears after the closing parenthesis of a query, signaling the result of the query will follow. Here is another example:

query {
      thing( name: "thing-one" )
   }

When you run a query in the API Explorer with real elements, the results appear in the right panel. For this example, if the elements were real, the results would look something like this:

{
  "data": {
    "thing": true
    }
}

The results for this example query uses Boolean datatypes, meaning a value of true will be returned if the query is successful and the item is found, or false if it is not successful because the item is not found. If the query is entered incorrectly or another issue occurs, an error message will be returned.

Consider another fictional query, things(). For this example, assume that things() provides a list of things in LogScale, not just confirming that they exist. The following example is how its syntax might look:

things( 
       includeDisabled: boolean 
      ): Thing!

For this query, a different input parameter is involved - it specifies whether an item that is disabled should be included in the query results. Note that this is optional, with a default value of false. While the syntax does not indicate whether the input parameter is required, LogScale's GraphQL documentation includes that information for each respective query.

Results for the syntax shows it uses the fictional datatype Thing - for queries that are real, the documentation will show the returned values that can be chosen. Below is an example of how the query might look while in use:

query {
      things( includeDisabled: True )
         { name, id, enabled }
   }

This example query is asking to include disabled 'things' in the search, and requesting the name and identifier of each thing. This indicates whether each is enabled or not - note that the Boolean input parameter's value is not contained within double-quotes, and that the list of requested returned values is contained within a pair of curly braces. This is a common aspect of real queries.

Below is how the results might look for the query above:

{
  "data": {
    "things": [
      {
        "name": "thing-one",
        "id": "abc123",
        "enabled": true
      },
      {
        "name": "thing-two",
        "id": "def456",
        "enabled": true
      },
      {
        "name": "thing-three",
        "id": "ghi789",
        "enabled": false
      }
    ]
  }
}

Results are provided in standard JSON format, which is dependable and allows users to capture returned values using an API script written in a programming language like Perl or Python.

More possibilities exist when using queries. How their syntax is composed, the use of special datatypes for input, the use of sub-datatypes for input and results, and more are all options for constructing a query that meets the needs of the situation or problem at hand. These examples should serve as a baseline for understanding queries and how they work, but should not be considered exhaustive.

The recommended next steps for learning about GraphQL are to go through the generic tutorial for mutations, which is similar to this tutorial, and/or experiment with real queries with the intermediate query tutorials like Repository Queries, which cover core queries that are used and needed more often.