MessagePack for Communication

[theHamdiz]

Is there any reason as to only use json for TB?

Generally speaking a format like messagepack is usually faster to transmit & parse.

Can we make it optional in both the backend and the client libraries?

[ignatz]

Welcome!

Is there any reason as to only use json for TB?

No, not really. I've played with the idea before. Note that it's not just JSON, we'd need to replace JSON + JSON-Schema. The two requirements are: schemas for type-safety and self-describing. The latter rules out something like protobuf. It has been a while, but if I remember correctly from the ones I looked at (msgpack, bson, ...) apache avro looked the most promising.

Generally speaking a format like msgpack is usually faster to transmit & parse.

That's true on many platforms. For web it's actually the opposite. While messagepack is denser and easier to parse, any JS implementation is handily outperformed by the natively provided JSON parsers in V8/JSCore/SpiderMonkey.

Can we make it optional in both the backend and the client libraries?

It would always be optional based on the content-type header.

I'm curious, what platforms are you considering to build for? How critical is this? Are you specifically interested in msgpack?

[theHamdiz]

Welcome

Thanks for your time & effort.

what platforms are you considering to build for?

Mainly web & Tauri.

How critical is this?

Not critical, I was just curious.

Are you specifically interested in msgpack?

Yes, but I am more interested in enabling developers to use TB for wide range of use cases which requires optional everything, including by the way a message queue system, an in-memory db (which in TB case is absolutely not required regarding how fast it is but still), a server based db, a backup solution, multiple data transmission protocols, etc... you get the idea.

[ignatz]

Mainly web & Tauri

Thanks. We already touched on it and I'm sure it's clear but in case you eventually need the messages in your JS runtime everything other than JSON would probably slower in practice.

Yes, but I am more interested in enabling developers to use TB for wide range of use cases which requires optional everything, including by the way a message queue system, an in-memory db (which in TB case is absolutely not required regarding how fast it is but still), a server based db, a backup solution, multiple data transmission protocols, etc... you get the idea.

That makes sense, thanks. I'm interested in that too. Let me touch on some of your points:

• message queue system - I've toyed with this before and it's not entirely clear to me what's the best setup there. Talked to 3 people, got 5 opinions :). I think with WASM we're getting closer to allowing for more of a multiple plugin approach.
• backup solution - Is top of mind. Somewhat related, I'm also interested in continuous replication for disaster recovery and potentially edge reads.
• multiple data transmission protocols - This one we touch on. I agree but my intuition is also that this more of a nice-to-have... but am very open to be convinced otherwise.