Mathieu TricoireM
Convex Community•3y ago•
4 replies
Mathieu Tricoire

I wanted to provide some feedback on my

I wanted to provide some feedback on my use of UniFFI in this POC. I decided to go with UniFFI primarily because it significantly reduces the complexity and workload involved in manual implementation. Additionally, the recent async support through the foreign language executor is a great advantage IMO. Another beneficial feature is the generation of foreign language bindings.

UniFFI is used by Mozilla for some of their projects (one example: https://github.com/mozilla/application-services) and Matrix (for their client SDK at https://github.com/matrix-org/matrix-rust-sdk), among others.

UniFFI handle data exchange with foreign languages by "serializing" the data (see: https://github.com/mozilla/uniffi-rs/blob/main/docs/adr/0002-serialize-complex-datatypes.md). For primitive types it's a simple cast, but for complex types it creates a buffer. For instance, a 
Vec
 is serialized by storing the length of the vector as the first bytes and the remaining data after that.

One limitation I encountered is the lack of native support for 
BTreeMap
 and 
BTreeSet
. However, I managed to make it work by leveraging the experimental proc-macro feature. Additionally, I have a question: Did you choose to use BTreeXXX collections not because you needed a binary tree, but rather because implementing 
Hash
 for 
Value
 would have required to implement 
Hash
 for 
HashMap<String, Value>
, and 
HashMap<Value, Value>
 or there is another reason? (That's the reason I preferred to use 
BTree
, but 
HashMap
 would have been easier since it's a built-in UniFFI type)

I believe UniFFI is not perfect but it's the best solution I've found thus far, except building everything from scratch...
Was this page helpful?