| # Overview |
| |
| FlatBuffers is an efficient cross platform serialization library for C++, C#, C, |
| Go, Java, Kotlin, JavaScript, Lobster, Lua, TypeScript, PHP, Python, Rust and |
| Swift. It was originally created at Google for game development and other |
| performance-critical applications. |
| |
| It is available as Open Source on |
| [GitHub](https://github.com/google/flatbuffers) under the Apache license v2.0. |
| |
| ## Why Use FlatBuffers? |
| |
| <div class="grid cards" markdown> |
| |
| - :material-clock-fast:{ .lg .middle } **Access to serialized data without |
| parsing/unpacking** |
| |
| --- |
| Access the data directly without unpacking or parsing. |
| |
| - :material-memory:{ .lg .middle } **Memory Efficiency and Speed** |
| |
| --- |
| The only memory needed to access your data is that of the buffer. |
| No heap is required. |
| |
| - :material-compare-horizontal:{ .lg .middle } **Backwards and Forwards |
| Compatibility** |
| |
| --- |
| FlatBuffers enables the schema to evolve over time while still maintaining |
| forwards and backwards compatibility with old flatbuffers. |
| |
| - :material-scale-off:{ .lg .middle } **Small Footprint** |
| |
| --- |
| Minimal dependencies and small code footprint. |
| |
| </div> |
| |
| ## Why not use... |
| |
| === "Protocol Buffers" |
| |
| Protocol Buffers is indeed relatively similar to FlatBuffers, with the primary |
| difference being that FlatBuffers does not need a parsing/unpacking step to a |
| secondary representation before you can access data, often coupled with |
| per-object memory allocation. The code is an order of magnitude bigger, too. |
| |
| === "JSON" |
| |
| JSON is very readable (which is why we use it as our optional text format) and |
| very convenient when used together with dynamically typed languages (such as |
| JavaScript). When serializing data from statically typed languages, however, |
| JSON not only has the obvious drawback of runtime inefficiency, but also forces |
| you to write more code to access data (counterintuitively) due to its |
| dynamic-typing serialization system. In this context, it is only a better choice |
| for systems that have very little to no information ahead of time about what |
| data needs to be stored. |