[MUSIC PLAYING]
WOUTER VAN OORTMERSSEN: Hello, everyone,
and welcome to Going Further with FlatBuffers.
So this talk is about advanced users of FlatBuffers,
so I won't go into details about what FlatBuffers actually is.
But if you've never heard of it, let me give you
the executive summary.
FlatBuffers is a cross-platform serialization library that
is all about memory efficiency.
If you're going to remember just one thing about it,
let it be that it allows in-place access
of serialized data without first parsing or unpacking it.
And it does all this while still allowing the data to evolve.
It is strongly typed through schemas,
and of course, we support lots of languages,
and import, export to JSON.
It is used in game engines, internally at Google,
and externally, for example, in Cocos-2Dx.
It is also widely used outside of games, for example
at Facebook and Netflix.
So today, I'll be talking about seven advanced ways
in which you can get more out of FlatBuffers.
First up, we have schemaless FlatBuffers, otherwise
known as FlexBuffers.
So FlatBuffers, generally, are a great way
to store strongly typed data, but what
if you need to store data for which you
can't define a schema yet?
So with [? FlatBuffers, ?] we took
all the advantages of FlatBuffers,
and we turned them into self-describing data structure.
It still has the in-place access without parsing,
so it's a similar speed advantage to FlatBuffers.
You can share keys and values to get big space savings,
compared to JSON.
And the serializer automatically finds the smallest
possible [? representations ?] for all your values,
often down to a single byte, and you can nest them
inside FlatBuffers.
So you can choose the most appropriate data representation
for all your data.
And on this slide, we have an example
of creating a FlexBuffer, on the fly, without the schema,
and without having to create any data structures first.
Now, don't worry if the code looks a little bit scary.
There's also version doesn't use lambdas.
Then you can read it directly from the buffer,
with random access and no memory allocation whatsoever.
FlatBuffers also has in-place binary search.
The way this works--
if you have a vector of tables, you can mark one of the fields
as a key and have the vector sorted during serialization.
This allows you to do fast, binary search look ups directly
on the buffer, without having to create any map or dictionary
structures.
Next, in place mutation.
So serialized data is not typically something
you want to modify after the fact.
But FlatBuffers allows you to do so anyway.
This kind of makes sense, since a FlatBuffer
is something that can replace a traditional object tree.
So with this feature, you can use it to store values, too,
and then once you're done with it,
you can [? write ?] it back to disk,
without having to do any reserialization of the data.
Next, reflection allows you to work with serialized data
in ways that go beyond the simple read write API.
For one, it allows you to run a loaded schema at runtime
and inspect it programmatically.
It also allows in place mutation of more complex data
structures, like strings and tables.
As you can see from it-- as you can maybe see from the sample
code--
binary schema is implemented using FlatBuffers itself,
using the same generated code API
to access the schema, which is all very meta.
We also have a traditional object API.
There are times when a classical object
tree is the best representation for your data,
and none of the previous methods are sufficient.
In that case, FlatBuffers can generate code for you that
turns these buffers into idiomatic C++.
It's not as fast as using buffers in place,
but if you happen to need it, then it's
better than writing it all by hand.
And now for something completely different.
GRPC is Google's open source RPC library,
and now, FlatBuffers works out of the box with GRPC.
So you can specify your RPC in the schema,
and have all the glue code generated for it.
And last, and maybe least, to make migration
from Protocol Buffers to FlatBuffers
a little bit easier, we now have an automatic way
to translate Protocol Buffer schemas into FlatBuffers.
And that's all I have for you today.
For more information on FlatBuffers,
please check out this URL, or just come chat to me
afterwards.
Thank you very much.
[APPLAUSE]
[MUSIC PLAYING]