Currently most data in WPGraphQL uses the DataLoader pattern and treats data as Models / Nodes.

Options (data stored in wp_options table) do not currently follow this pattern.

I believe they should follow this pattern.

Each Settings Group (ex: general, discussion, reading, writing, etc) could be considered a Node. The Node ID could be the name of the group. For example: Relay::toGlobalId( 'option_group', 'general' );

Then, whenever an option is queried, a DataLoader should be used to load the Model.

For example, a query like so:

{
  generalSettings {
    title
    url
  }
}

Should call the DataLoader for options, asking for the Relay::toGlobalId( 'option_group', 'general' ); node, which should return an instance of an Options Model, and determine which fields of said settings group should be allowed to be returned. Fields, such as generalSettings.email should be restricted by the Option model layer.

Benefits of this refactor

Centralized Actions / Filters

A lot of documentation in WPGraphQL points users to centralized hooks/filters, and options don't currently benefit from these actions/filters.

For example, the filter graphql_data_is_private can be used to restrict an entire model. If someone wants to restrict a specific Post by ID, etc they can do this with this filter. Since options don't pass through this filter, users cannot use this filter to restrict specific options or option groups. Refactoring will allow central hooks/filters like this to be used with options like they're used with other data loaded by WPGraphQL.

WPGraphQL Smart Cache (Cache Mapping / Evictions)

By refactoring options to use the DataLoader / Model pattern, data will pass through central hooks in WPGraphQL that can be used by plugins such as WPGraphQL Smart Cache.

Currently, the WPGraphQL Smart Cache plugin listens for data to be loaded by DataLoaders and tracks the Model that's used to return nodes, and stores a map of said nodes along with the query, then can identify when said Models/nodes are modified and can then evict the caches.

Because Options don't currently use the Model/Node/Loader pattern, WPGraphQL Smart Cache is not currently properly able to track/evict when changes to options occur.

Breaking Changes?

I believe we should be able to do this refactor without making any breaking changes to the Schema.

The difference should be how data is loaded, but the schema should remain the same. Some additions will be made to the Schema, such as adding an id field to all the setting groups and applying the node interface to each setting group.