[5.x]: GraphQL Introspection schema tripled in size

[cornedor]

What happened?

Description

This headless website already had a schema of 11MB, that took ~2 sec to generate. While not ideal, this works fine for its usecase. However, after upgrading to CraftCMS 5 the size more than tripled to 38MB, and now takes more than 8 seconds to generate. I've also had to increase the PHP memory limit in order for it to finish.

While I do not know how the inner workings of an introspection schema work, it looks like it has a lot of duplicates. I searched for a field in the schema, that is only present in a single entry, and I found 1100 results. In the screenshot below you can also see the density of the results by looking at the sidebar. Only in the bottom there is a small part where the field name is not found.

Steps to reproduce

1. In a CraftCMS 4 site, open GraphiQL with the network tab open, and lookup the introspection call
2. Upgrade to CraftCMS 5, and repeat step 1.

Expected behavior

Introspection schema is a reasonable size.

Actual behavior

Exceeded memory limits and very large introspection schema

Craft CMS version

5.1.6

PHP version

8.2.19

Operating system and version

Linux 3.10.0-1160.24.1.el7.x86_64

Database type and version

MySQL 8.0.36-28

Image driver and version

Imagick 3.7.0 (ImageMagick 6.9.11-60)

Installed plugins and versions

• Feed Me 6.0.1
• Redactor 4.0.0
• Redactor Anchors 1.5.0
• SEO v5.0.0-rc2
• Super Table 4.0.0
• Typed link field devedis/craft-linkfield
• Webhooks 3.1.0

[thomasjonas]

We are having similar issues. Did you manage to find a solution for this @cornedor? Or at least a way to improve the situation?

[cornedor]

No, sadly not. Trying to merge entries only increased the schema size. It works just about well enough for us, but our gateway has to work hard starting up.

[thomasjonas]

Thanks for replying! Ah, that's a pity :( I hope GraphQL will get some love soon. For us requests are also quite slow. Way slower than getting the same data via a REST request. But I think that's more related to this discussion