# Choice of FlatBuffers to replace JSON

**URL:** <https://mediasoup.discourse.group/t/choice-of-flatbuffers-to-replace-json/5621>\
**Category:** mediasoup libraries\
**Created:** [October 26, 2023, 12:15pm UTC](https://mediasoup.discourse.group/t/choice-of-flatbuffers-to-replace-json/5621 "2023-10-26T12:15:34Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![j1elo](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/j1elo/32/1010_2.png) [@j1elo](https://mediasoup.discourse.group/u/j1elo)\
**Post date:** [October 26, 2023, 12:15pm UTC](https://mediasoup.discourse.group/t/choice-of-flatbuffers-to-replace-json/5621/1 "2023-10-26T12:15:34Z")

</div>

Hi,

Yesterday I discovered that [mediasoup is moving to FlatBuffers](https://github.com/versatica/mediasoup/pull/1064) instead of JSON for its internal comms between the programming API and the worker executable.

This technical decision interests me a lot, and I would love to learn a bit more about this. So I’d like to ask you guys if there’s any writing I could read about the thought process behind the change. Once leaving the slow and bulky JSON, there are some obvious choices like FlatBuffers, but also others widely known like Cap’n Proto (such as used by Cloudflare). So this decision -as seen from outside- is not that clear-cut.

Kenton Varda -the author of Protobufs v2 and Cap’n Proto- has [a popular post comparing these](https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-sbe.html), but I’d love to know if you had some practical takeaways for mediasoup to tip the point in favor of one instead of another.

(or, you know, maybe all were just equally fit for the needs, and the choice was merely a matter of what’s the most popular! I’d imagine that’s a possibility too)

---

<div class="post-metadata">

**Author:** ![ibc](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/ibc/32/1540_2.png) [@ibc](https://mediasoup.discourse.group/u/ibc)\
**Post date:** [October 26, 2023, 1:06pm UTC](https://mediasoup.discourse.group/t/choice-of-flatbuffers-to-replace-json/5621/2 "2023-10-26T13:06:51Z")

</div>

flatbuffers covers C++, Node and Rust and avoids memory copy when parsing. The decision was taken almost a year ago. If there were other choices we discarded them. If there are new ones it’s too late. It’s a year already working on this.

---

<div class="post-metadata">

**Author:** ![j1elo](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/j1elo/32/1010_2.png) [@j1elo](https://mediasoup.discourse.group/u/j1elo)\
**Post date:** [October 26, 2023, 1:32pm UTC](https://mediasoup.discourse.group/t/choice-of-flatbuffers-to-replace-json/5621/3 "2023-10-26T13:32:46Z")

</div>

> [@ibc](#):
>
> If there are new ones it’s too late. It’s a year already working on this.

Oh I absolutely didn’t mean “_you should have chosen something different_” or anything like that!

I just meant “_I would like to know if you compared them and learned something_”. To also learn myself. If I had to choose a general purpose serialization format today, I would hesitate between flatbuffers and cap’n proto, so that’s why the question. They seem pretty on par, but there must be _some_ difference.

Language support is definitely a strong reason, though. Regardless, I think any of those two would probably be a good enough choice anyway.

---

<div class="post-metadata">

**Author:** ![ibc](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/ibc/32/1540_2.png) [@ibc](https://mediasoup.discourse.group/u/ibc)\
**Post date:** [October 26, 2023, 1:38pm UTC](https://mediasoup.discourse.group/t/choice-of-flatbuffers-to-replace-json/5621/4 "2023-10-26T13:38:29Z")

</div>

Existing alternatives were considered. flatbuffers was the best one by far.
