Fetch arrayBuffer data is not inlined during ssr

[Elia872]

Describe the problem

During server-side rendering fetch responses using text and json are inlined in the rendered HTML, there is no such thing for arrayBuffer.

This causes an additional network request and can lead to consistency problems and unused assets loading.

Describe the proposed solution

Fetch request using arrayBuffer is inlined in the HTML response using base64 encoding

Alternatives considered

No response

Importance

would make my life easier

Additional Information

Currently i added this feature to a local copy of kit

[siccovansas]

I ran into this problem as well (when fetching a PDF in a load function). I searched around and found this comment by Rich Harris:

The assumption was that if you don't consume the body with res.text() or res.json(), it's because you're streaming the response or using res.arrayBuffer() — either way we don't want to serialize it.

I asked a question on Discord and got this response:

the most efficient way is to fetch it directly from an endpoint
for the same reasons that we use <img> tags with src set to the server location, rather than base64 encoding images (which would cause them to be included in the page source twice)

So I now simply fetch the PDF in the .svelte file. Fetching static data in a load function indeed doesn't seem to make sense as the data isn't actionable.

@Elia872 would this also fix your issue? Or is there an explicit need to fetch an ArrayBuffer in a load function?

[Elia872]

I can see why including arrayBuffer as default could lead to problems, but it would be nice to have some sort of option to enable it, because if the data you fetch is in a non-text format, i can't think of a workaround.

I initially noticed this behavior by fetching 12 random objects from an API using a custom encoding, and I saw that when the hydration finished the thumbnails would change.

So yes @siccovansas i need arrayBuffer in the load function.

[siccovansas]

Thanks for your response @Elia872!

What happens if you use fetch() to get the objects from the API in your .svelte file? Note: This is the normal fetch() and not the modified SvelteKit load function fetch(); you don't need to import this fetch as it is already globally available.

[Elia872]

@siccovansas Using the browser's fetch() in the .svelte and an #await block works with no problems, but only on the client, and loosing all the advantages of a +page.js like preloading, ssr or less roundtrips.

[siccovansas]

There is no advantage to retrieving static/binary data on the server if I understand Rich Harris and the response I got on Discord correctly. Like the Discord response says, you also don't load your images on the server and then send them to the client. Images are only directly loaded client side.

SvelteKit could add this functionality, but binary data then needs to be base64 encoded which results in a larger file size. I guess this would undo advantages like preloading and ssr. There are also no extra roundtrips if you place your fetch call in e.g. onMount so it runs only once on the client side.

[Elia872]

I didn't mean static data, my bad. I meant dynamic data like 'comments of post x', but in a binary format instead of json.

[lbguilherme]

I also needed this functionality in a project. For my use case I had an API endpoint that returns binary data (it was a collaborative document serialized to raw data). This makes sense as an API result and is dynamic. We had the requirement to SSR the route that views this document. The solution was to add another endpoint that does the same thing but returns the data base64-encoded.

I believe SvelteKit should support fetch with arrayBuffer, and should encode it as base64. The only downside I can see is that this encoding enlarges the data and would result in a network impact. But the thing is that GZIPing base64 data results in only a 2~5% size increase, that's very small. Also, it would only affect people who use binary data in their APIs.

[ximus]

My app relies on a lot of grpc-web calls. These use a binary data format, hence needing arrayBuffer. I would greatly benefit from having these inlined during ssr.

here is some more prior discussion on the subject not yet mentioned here #8317