GraphQL Asset interface content property not available?

[riccardolardi]

Description

The standard Asset interface has the contents property (https://docs.craftcms.com/api/v3/craft-elements-asset.html#contents) which I've previously used to return the assets (the asset is a JSON file) data. I can't seem to find the equivalent for GraphQL (https://craftcms.com/docs/3.x/graphql.html). Isn't it possible to return a JSONs assets data within a GraphQL query result?

[andris-sevcenko]

That property was implemented to help render SVGs in Twig templates. I'm not at all convinced that GraphQL is a great fit for this.

The data would have to be encoded in base64 format, increasing the payload size by 33%, which is not ideal. Can you, perhaps, use the URL of the file to download it separately?

[riccardolardi]

Hi Andris, thanks for your reply. May I know your reasoning why GraphQL might not be a good fit for this?

Of course, the alternative would be to use the URL to fetch the JSON separately, which would also work in my scenario.

[andris-sevcenko]

Hi Andris, thanks for your reply. May I know your reasoning why GraphQL might not be a good fit for this?

There are layers to this. The first layer is the base64 (to ensure that the GraphQL response is not broken). This increases the payload by 33%. The next layer is the CPU cost of performing basse64 encoding. Add on top of that the traffic cost and the latency involved if the said Asset is on a remote volume (has to be downloaded to Craft server, encoded, and then sent over GraphQL), and you have a (potentially) costly operation.

Since GraphQL API is often used in a public space and the bearer token can be just lifted from the browser's dev console, this opens a rather convenient DDOS attack vector on sites by shooting off a query that sends multiple asset file contents over GraphQL.

While that can be partially mitigated by configuring the allowed complexity for a query, it increases the complexity of the codebase and shifts the burden to the site dev to configure the site correctly, which will not always be the case.

So, in the end, I feel like exposing this is somewhat risky and maybe not worth it, considering the fact it can be worked around.

[riccardolardi]

@andris-sevcenko thank you for the elaboration.

[andris-sevcenko]

I'll keep it open, though. It's not a useless idea - it's an idea that has to be thought about carefully and probably has to go hand-in-hand with some other changes :)

[joshuabaker]

Would love to see this implemented also. There’s a few scenarios where accessible JSON file content (i.e. embeds) and encoding SVG graphics is actually quite helpful. A simple (for end users) @contents directive, or similar, would save a lot of composing effort on the client side.

[tremby]

I got here from #9076 which was closed and pointed here.

The arguments against having a base64 data URI of the image content through GraphQL in this thread are all to do with size bloat, and that's certainly a concern for full-size images.

The use case in the thread I came from, however, is for a tiny tiny version of the image, for which a base64 encoding is entirely reasonable.

I'll point out that there are plugins already to provide this (eg https://github.com/dodecastudio/craft-blurhash), so maybe there's no reason for Craft itself to provide this feature.

[martin-coded]

In Next.js it seems to be common to use a small representation that is not blurred (so using blurHash seems to be the wrong way).
In my case, the size of the small base64 data URI is negligible. As far as I can remember it was less less than 1kb.

https://nextjs.org/docs/app/api-reference/components/image#blurdataurl