[zeeg]

You're extremely limited in what you can compile as a GraphQL query, so while yes I agree with you that likely there is some stuff we're simply doing wrong.. good luck doing it right. After all, its a database query language trying to create a giant cache of its results.

For example, we have what roughly amounts to an <Include> component. It uses some contextual information to include language-specific code. That include component pulls in a markdown file from disk based on 1) the includePath you set, and 2) the language selected. In order to make this function, we have to pull in _all_ possible includes within the static query, and then filter it down to the ones we need. There is literally no better way we could do this, because static queries are exactly that - static. There is no fixing this problem because the design of this data layer is broken by default.

[nephs]

You are basically complaining that the client is loading too much data because you are sending them too much data.

You could publish the different languages in different folders/path, thus, using the static queries to build static pages.

If you want them on the same path while loading different language content dynamically, that migh not be the best use case for gatsby. In that case you probably need to load every translation for each of the included paths, but not every path with every language for all of the different pages.

[kualto]

Have you tried using page queries? Page queries can accept arguments passed in via the createPage API. Here's some (admittedly hard to find) documentation about it: https://www.gatsbyjs.com/docs/page-query/#how-to-add-query-v...

The basic idea is your page context just contains identifiers for the content you need to display on the page and then the page query uses those identifiers to query for just those objects and request all the properties of those objects that the page needs.

[zeeg]

That only helps when it’s coupled to the page. Doesn’t make a ton of sense in our use case as it’s just an arbitrary component. It would have to support queries based on component props, but that’s even more complexity in an existing nightmare.