In this case, using parseFromTokenSourceLeaky instead of parseFromSliceLeaky is presumably roughly equivalent, since in both cases you have already loaded the entire raw json data into memory. What I believe the comment in the groovebasin code is suggesting is that you give parseFromTokenSourceLeaky a reader with the inner reader coming straight from the Response, similar to how the decompression works in http.Client.fetch:
(so in the streaming json case, there would be another step in the chain where it’d go response reader → maybe decompressing reader → json reader)
If set up that way, then the buffer you use would not need to be able to fit the full json response, and the program would not need to hold the entire json data in memory at once–instead, it’d parse it in chunks.
There’s a nice article on this general topic that is actually also very applicable to how Zig’s Reader/Writer works generally (“compaction” in the article is what Zig calls “rebase”):
(however, Zig’s streaming json parser isn’t designed to only use the buffer’s memory and nothing else; Zig will allocate extra memory as needed, and also allocate memory for the parsed values, etc)