Flatbuffers implementation in Elixir

[florian....@wooga.net]

Hi,

I like to point you to an implementation of Flatbuffers in Elixir: https://github.com/wooga/eflatbuffers

The library was developed for a mobile game backend where the game itself was developed by Maxim Zaks et.al.(see also https://github.com/mzaks/FlatBuffersSwift).

The idea of this project was to use flatbuffers for efficiency on the client side. At the same time we did not want to recompile any modules in the backend as soon as a client uses a new schema. Instead we would fetch the new schema from a common storage on demand.

As a result eflatbuffers dynamically encodes and decodes flatbuffers from and to native Erlang/Elixir terms and thus provides great flexibility.

Comments and forks are welcome.

Best,

Florian Odronitz

[Wouter van Oortmerssen]

Very cool, and good to know!

Always dealing with a schema dynamically is very elegant, but also a bit slow. Since FlatBuffers was designed for speed, if this would ever get contributed back to the main project, it would have to done through code-generation instead, like all the other languages.

And you don't have to recompile the server whenever the schema changes, FlatBuffers was designed with forwards and backwards compatibility baked in.

Wouter

--
You received this message because you are subscribed to the Google Groups "FlatBuffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flatbuffers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[florian....@wooga.net]

The random-access-speed, compact representation and backwards compatibility were flatbuffers biggest selling points for us, being essential on the client side (mobile phones with nimble CPUs and limited bandwidth).

We had a couple of reasons to go for a dynamic approach on the server, though:

- operationally, it's much cleaner

- most flatbuffers are generated here so omitting data due to outdated schemas was not an option

- we have much faster processors

- a few milliseconds more are OK in the context of a HTTP request with 30+ milliseconds latency

- we can cache flatbuffer binaries easily (e.g. configs)

So I think this project serves a special use case and and it would not make sense to integrate it into the main project.

~ Florian

- 

We decided to do it dynamically because of our very specific requirements:

-  

To unsubscribe from this group and stop receiving emails from it, send an email to flatbuffers...@googlegroups.com.