Key Terms

This page collects the foundational terms used throughout the GalleonQL manual, along with short examples. It is the common foundation referenced by the other pages.

Environment (Connection Profile)

An environment bundles "which endpoint to connect to, and with what authentication and headers" into a single switchable connection profile. GalleonQL adopts the same orthogonal model as Postman: an environment is not an intermediate node in a hierarchy.

Queries do not depend on the environment; they live inside collections.
A request is assembled from "a query × the selected environment." Just by switching the environment in the top bar, you can change where the same query is sent — dev / stg / prod, and so on.

Example: environment dev points at the local http://localhost:4000/graphql, and environment prod points at https://api.example.com/graphql. You keep a single query getUsers and switch its destination with the environment toggle.

Visually, an environment filter may make things look hierarchical, but as a data structure they are orthogonal (query and environment are separate axes). For details, see Registering and Switching Environments.

Environment Variables (`{{...}}`)

Environment variables are the key-value pairs an environment holds. You insert them using the {{...}} form into the value of an endpoint URL, a header, a GraphQL variable, and so on, and they are resolved to the actual value of the selected environment at send time.

Example: define the environment variable baseUrl = http://localhost:4000/graphql and write the request URL as {{baseUrl}}. When you switch environments, the contents of {{baseUrl}} are swapped. You can also define token and use it in the Authorization header as Bearer {{token}}.

Environment variables are a different thing from the "GraphQL variables" below. Do not confuse them.

GraphQL Variables (`$id` / `$input`)

GraphQL variables are the arguments of the GraphQL query itself. They begin with $, like $id or $input, and you pass values when the query runs. They play a different role from an environment's {{...}} environment variables.

Example: the $id in user(id: $id) is a GraphQL variable. It is a different mechanism from baseUrl or token (environment variables).

In the query builder, you can enter a field's arguments through a key-add UI and emit them into the generated query in the field(name: value) form. In addition, when you switch the input mode to "Variables", top-level arguments are replaced with $name named GraphQL variables and the builder generates query($name: Type){ … } together with a variables (JSON) object; you enter the values in the variable matrix. For details, see Query Builder.

Header Cascade

The headers for a request are determined by layering (cascading) in the order project-wide → environment → query-specific. If the same key appears, the lower (later) one overrides it.

Example: if you set X-App: galleonql project-wide, Authorization: Bearer {{token}} at the environment level, and X-Trace: 1 at the query level, the three merge into the final set of headers.

Before sending, you can preview the final headers, with {{token}} and the like resolved to the actual value of the selected environment. For details of the cascade (including how authentication fits in), see Registering and Switching Environments and Sending Queries and Reading Responses.

Schema

A schema is the full set of type and field definitions that a GraphQL endpoint exposes. GalleonQL fetches it per environment (endpoint) via HTTP introspection and caches it locally. An imported schema can be browsed as a type catalog and becomes the foundation for the query builder.

For the import procedure, see Importing a Schema; for how to browse it, see Browsing the Schema Documentation.

Leaf and Branch

A field in the schema is classified as a leaf or a branch according to the kind of type it references. This distinction governs how you traverse the documentation and how you build a query.

Leaf: a field whose target is a scalar / enum. It cannot be expanded further.
Branch: a field whose target is an object / interface / union. You can expand its inner fields further (add Child).

Example: User.name (String) is a leaf. User.friends ([User!]) is a branch, and you can expand its inner name and so on further.

add Query / add Child

add Query and add Child are the operations for building a query step by step, growing it by grafting new fields onto branches so you expand only what you need.

add Query (+ query): inserts a field of a root type (Query / Mutation) from the type catalog as the root of the query. The main button always adds it with no children.
add Child (+ child): expands one level of only the immediate scalars for an inserted branch.

Both are split buttons made of a main button and a ▼ menu. Choosing "Scalars only (one level)" or "All fields (one level)" from ▼ overrides the granularity for that one time only (the fixed default does not change). For detailed operation, see Query Builder.

Collection

A collection is a container (folder) for organizing queries (Query / Mutation). Collections can be nested. They are designed so that they can, in the future, be handled in two tiers: a personal scope and a shared team scope.

Project

A project is the outermost unit that environments and collections belong to. When you switch projects with the top-bar selector, you switch to the environments and collections under that project. For per-project export and import, see Exporting / Importing Projects.

License Check at Startup (Automatically Applying a Subscription Lapse)

The license check at startup is a mechanism where, when you have an extra-slot license registered, GalleonQL verifies your license validity online every time the app starts. This automatically applies a subscription cancellation or lapse to the app at the next startup (it does not run when you use only the free slot).

Valid (subscription active, or canceled but still within the paid period): your extra slots are kept as-is.
Lapsed (expired, revoked, canceled and past the paid period, and so on): your extra slots automatically return to the free slot (1 slot), and the license key is removed from this device (projects beyond your slots become beyond-slot, and their data is kept).
Starting offline: a previously valid license is temporarily kept as long as it is within 24 hours of the last successful online check and still within its validity period, showing a "Cannot verify license" notice. Past that, you return to the free slot. Once you are back online, it is re-checked automatically.

For details, see Project Slots and Plans.

Deactivating a License vs. Canceling a Subscription

Both are ways to give up your paid extra slots, but the timing of returning to the free slot (1 slot) differs. Do not confuse them.

Deactivating a license (Deactivate license on this device): immediately returns to the free slot and removes the key. However, billing does not stop.
Canceling a subscription: stops billing. Your extra slots automatically return to the free slot after your paid period ends, at the next app startup (via the license check at startup above).