(iggy-website) branch main updated: improve zero copy blog post

[gk...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

gkoszyk pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/iggy-website.git


The following commit(s) were added to refs/heads/main by this push:
     new 87f5d49a4 improve zero copy blog post
87f5d49a4 is described below

commit 87f5d49a49a22c1663d793888703150edf579e48
Author: numinex <g....@gmail.com>
AuthorDate: Wed May 7 21:02:28 2025 +0200

    improve zero copy blog post
---
 blog/2025-05-08-zero-copy-deserialization.md | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/blog/2025-05-08-zero-copy-deserialization.md b/blog/2025-05-08-zero-copy-deserialization.md
index 8534c0b74..f6dbe2056 100644
--- a/blog/2025-05-08-zero-copy-deserialization.md
+++ b/blog/2025-05-08-zero-copy-deserialization.md
@@ -46,12 +46,11 @@ pub struct IggyMessage {
 }
 ```
 
-Rkyv internally figures out the memory layout used for serialization, such that it can later on cast it back into its Archived form. A couple bits of trivia: rkyv, when performing zero copy deserialization, turns the byte representation of your data into its Archived form, so instead of `IggyBatch` we receive `ArchivedIggyBatch`, rkyv has to reimplement certain complex types such as `Vec`, `HashMap` etc. and that’s why it yields back your type in Archived form. You can learn more about i [...]
-
-Upon further evaluation of `IggyBatch`, we concluded that despite its sufficiency, it left room for improvement.
-
-Imagine a scenario where the client sends a batch with 100 messages, the server receives it, turns it into Archived form, updates metadata fields, caches/persists it and sends an ack back to the client. The client sends a fetch request for 10 messages, the server receives the request, peeks into the cache, finds our batch of 100 messages and here is the tricky bit.
+Rkyv internally figures out the memory layout used for serialization, such that it can later on cast it back into its Archived form. (A couple bits of trivia: rkyv, when performing zero copy deserialization, turns the byte representation of your data into its Archived form, so instead of `IggyBatch` we receive `ArchivedIggyBatch`, rkyv has to reimplement certain complex types such as `Vec`, `HashMap` etc., and that’s why it yields back your type in Archived form.)
+You can learn more about it by reading the **[rkyv book](https://rkyv.org)**, or from this **[presentation](https://www.youtube.com/watch?v=ON4z2LbTD-4)**.
 
+After a further evaluation of `IggyBatch`, we found that while it was good enough, there was still room for improvement.
+Imagine a scenario where the client sends a batch with 100 messages, the server receives it, turns it into Archived form, updates metadata fields, caches/persists it and sends an ack back to the client. The client sends a fetch request for 10 messages, the server receives the request, peeks into the cache, finds our batch of 100 messages and here is the tricky bit -
 We would like to send back **only a slice of the cached data** (10 messages instead of 100), but due to rkyv's memory layout, one cannot simply take a slice of those bytes and perform the transformation into its Archived form.
 
 So rather than deriving rkyv's traits to `IggyBatch`, we decided to refine our approach by working at the individual message level.