[v5] GraphQL schema granularity for sections/entry types

[brandonkelly]

Entry types are becoming decoupled from sections in Craft 5. They will be defined globally, and sections will get to choose which entry type(s) are available to it. Which effects GraphQL schemas.

Currently, you can configure a GraphQL schema to allow editing sections on a per-entry type basis.

There are three ways GraphQL schemas could evolve with globalized entry types in Craft 5:

1. Top-level entry type options

List entry types as top-level options, with no relation to the sections they’re included in. Selecting an entry type would make its entries available to GraphQL queries across, for each selected section.

2. Remove entry type options

Maybe they’re not necessary in the first place? We could remove them entirely, leaving only the section options. Selecting a section would make its entries available to GraphQL queries, regardless of entry type.

(This would be the best option for performance.)

3. Section-specific entry type options

Visually identical to what we have now. If an entry type is included in two sections, each section will need to opt into including entries of that type.

[FreekVR]

I would suggest top-level entry type options BUT would add a union per section, if querying stuff by section is still relevant/possible.

This way you don't have essentially duplicate types for stuff if one Entry Type is used in several sections.

Eg.

#Entry types
type Page {}
type News {}
type BlogPost {}
type BlogCategory {}

#Sections
union LatestStuff = News | BlogPost
union Pages = Page
union Blogs = BlogCategory | BlogPost

Within the UI, I'm not sure which selection makes the most sense. I guess with the type setup above you would only select with Entry types are available, which then affects which types are included in the section unions.

[brandonkelly]

@FreekVR As far that goes, I think we are going to just have entry type-based interfaces. Sections don’t have any effect on the available fields etc.

[lindseydiloreto]

I'm not a heavy GQL user, so correct me if I'm wrong here...

Let's say you went with (2) and "removed entry type options" from the schema. You would still be able to filter a Section by an Entry Type during the query, right? So if you only wanted entries of a certain type, it would still be possible to retrieve only those entries?

If so, I would definitely advocate for (2) as the best (and cleanest) option.

[brandonkelly]

Right – this is about choosing which entries should be available to be selected in the first place, and how granular we should make that.

[khalwat]

I would try to make the GraphQL schema match the underlying schema as closely as possible. If I understand the changes you're planning to make, decoupling entry types from sections effectively makes them global peers.

So what makes the most sense to me is #3, because you can choose:

• What Sections should be available to the schema token
• Within that section, which entry types should be available

To me when I'm thinking of setting access permissions, this is the clearest and most explicit.

I also wouldn't mind #2 but I feel like someone will eventually have a case where they want to limit access by entry type as well.

[davidhellmann]

I also think #3 is the best solution here, to have more control and more context when viewing these settings.

[sjcallender]

How big of a performance boost is 2 over 3?

[brandonkelly]

Minor. (Sorry earlier comment was confusing scopes for types.)

[dlindberg]

If you are going to have permissions by type, it would need to be three. Number one has a high error surface area for either incorrect set up, or otherwise unexpected behavior. Two is probably sufficient in most cases. However, needing both by section and type in complex sites could be critical. Depending on the performance implications, being able to pick the sections you need to limit permissions by type seems like an okay “both ways” option.

[brandonkelly]

We discussed this internally today, and are thinking we’ll go with #2, for three reasons:

1. Simplicity
2. Consistency with user/group permissions, which are per-section rather than per-entry type
3. It will be possible to move entries into different sections in Craft 5 (a la carte or in bulk), so for rare cases where per-entry type granularity is needed, a new section could be created instead.

Existing schemas that partially include nested section components for some entry types but not others will lose those components as part of the migration, and will need to be re-added afterward.

[michtio]

On this note. It would be nice to have user/group permissions on entry type level tho! ;)