Consider making `schema::Schema` fields public for testing

[ginger51011]

I have been experimenting a bit with constructing a single source of truth when developing an adapter. Here is the general idea I'm using right now

• Use a src/schema.trustfall.graphql as source of truth: All Rust types/enums/etc. must conform to this file. It is included statically using include_str! and parsed to a static schema::Schema ref using lazy_static!
• Use testcases to ensure that the standard Token variant (as used in demos) follows this schema

The last point becomes a problem since schema::Schema currently hides for example vertex_names, that could be used to verify naming etc.

In the same vein: Since typename for tokens should be the same as the names in the schema, I would instead suggest a procedural macro that simply make the variant names the type names (see hackernews impl Token block)

It would perhaps be more desirable to generate either the schema from Rust types (like juniper does for GraphQL) or Rust code from the schema, but that would require some macro magic. Something like the $[derive(GraphQLObject)] (#[derive(TrustfallVertex]?) would make development go brrrr

[obi1kenobi]

I wouldn't make the fields themselves public[0], but I'm open to adding accessor methods that expose iterators and point-lookup functions over the data.

Another interesting option: add a built-in adapter for querying schemas, so users could do

{
  Vertex {
    name @filter(op: "=", value: ["$name"])

    property {
      name @output
      type @output
    }
  }
}

or something to that effect.

[0]: Our current schema is fully materialized and parsed from a file. But sometimes schemas are way too big for that, especially once we start combining them across adapters. I've worked with schemas of hundreds of thousands of types, which needed over 500MB of RAM to get represented in this form. So it would be convenient to not get locked into a specific representation with particular fields etc. and instead offer an API that we can maintain stable regardless of the underlying format.

I'm open to a proc-macro for __typename as you suggest, as well as macro magic for Rust -> schema or vice versa. It isn't clear to me that one direction is strictly preferable to the other there, and it may be just a case of "prototype then evaluate."

[obi1kenobi]

If you still need to query schemas, try the new SchemaAdapter in Trustfall v0.5.1: https://github.com/obi1kenobi/trustfall/releases/tag/trustfall-v0.5.1

It already powers the new stub generator crate I recently created: https://github.com/obi1kenobi/trustfall/blob/main/trustfall_stubgen/src/adapter_creator.rs#L127-L133