Feature request: Fetching asset contents

[ParallelUniv3rse]

It would be super helpful to have the possibility of fetching the contents of a JSON, HTML or Text asset directly as plaintext. This feature would cut down on having to query once to fetch the url to asset from graphql and then fetching the asset afterwards.

I'm open to helping out with a PR, but I need a bit of a nudge in the right direction in terms of what needs to be done for this to work.

[narration-sd]

This might be a little more complicated than you think, as Craft doesn't really deal in images. Which might be as far off as a remote AWS storage bin, and in several sizes according to transform, for example.

Further, the various sizes' files (bytes) are most often lazily constructed on demand from first requests, triggered from a faux initial url which returns a redirect to the actual thing once present.

I guess you could force prebuilding, find a way to load the result (on the Craft side) into DB Blobs, and some people have played with hexifiying and returning such within JSON, but it sounds pretty messy compared to a little roundtrip latency (vs. delivering all the bytes, especially?)

[ParallelUniv3rse]

@narration-sd I see what you mean, but I'm not suggesting any handling like this for images, which are affected by the transforms and are generated on the fly.

My particular use case is using the craft-embedded-assets plugin, which enables users to store any embed's info as json file in the local filesystem. When fetching a .json, .txt or .html file, I can image developers will in many cases want to access the contents of a file instead of just a url pointing to that file. Reading the url which is now provided for the asset via for example file_get_contents and returning under a contents key is more what I'm proposing.

Or would you see an easier alternative of how to fetch the file pre-render so I can render content based on the data in my Nuxt app without affecting site load time?

[narration-sd]

@ParallelUniv3rse Arnost, I'm out of the office today until too late your timezone, but something Brandon mentioned in mail reminded, and on principle, I wonder if a Preparse field (a plugin you can find) might not be a better way to approach this?

That's if CraftQL will process it, but if you are setting it to return text, it may well do this...good fortune

[ParallelUniv3rse]

Sorry, I don't think that's an option. I'm looking to query all assets in the same way, only have the contents of the file available when it makes sense (HTML, JSON, Text).

[narration-sd]

Well, it's up to you to design what you wish, within the constraints of the overall systems present.

I may understand your drive for a 'one way for all' pattern, but then aren't you then kind of missing some of the reasons the web works as it normally does? Something like nature: sometimes messy, but effective?

• browsers have caches. When you use the normal url method for images and other resources is that they only download once, so it's only on some never-visited entry that you spend their time. Consider what would happen if you insisted on pulling each one each time?
• and, browsers beneath your app also interleave calls to servers, etc.. There's a lot happening invisibly to help.
• if images or anticipated distances are large, edge caches like the excellent, can-be-free Cloudflare are used. This assures good bandwidth at location, but often more importantly, cuts any distance-based latency round-trip delays, including the unexpected ones that can come within protocols, endpoints, etc..
• if somehow the response time of the server itself, running an active CMS for each request, becomes important, then modern days bring tools to let you pre-compile the initial load, so that it comes up with all the advantages of a static site, and then still be able to have an interactive js-based app. Gridsome, Gatsby, etc.. Nuxt should also do this, if that's what you've dived into...
• another known design move that can be effective for users or in cases is to present a simple skeleton image of the app at first, then filling in from data as it arrives. This is related to hidden background loading you could be able arrange for information that will be used later -- if such is necessary....

Nobody said SPAs are easy, if pasting some components together for a prototype can often impress us with potentials, I think?

[narration-sd]

@ParallelUniv3rse

Arnost, I thought to throw in here an apology, just in case I've explained what you do know already.

It can't hurt, I think, as may be useful to someone else if not to you.

I'd tried to imagine your train of thought, and the above is what formed up as an answer, perhaps a little formal written first thing before breakfast. But of course I could have gotten this wrong.

I've been focused for a while on a nice answer to needs with Gatsby and Gridsome, but looked a bit now back again for a moment at Nuxt. It seems it's cleaned up some of its problems. I seem to see in discussions among its developers planning futures that it doesn't quite have the abilities of these two platforms, though it started out with and does have others .

You and your project will know if its the best choice for you, and what needs to get done. So again, right solutions are the ones we see to design with our own view.

Best,
Clive