Pivot to Rust being a helper library #8
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is a major pivot from Rust being the major architecture component to being a helper library. The main reason we are doing this is because of the restrictions we have in FFI layer. Specifically on Android, we found that calling Kotlin from Rust is less than ideal - as JVM can drop the memory or the memory might be in a different thread. Although these issues are possible to get around, we don't want to build a new library on a house of cards.
We've gone through several design explorations so far and this time, we are going to keep the FFI layer as simple as possible by making the Rust library act as a helper. There will never ™️ be a callback from Rust to native and there won't be any asynchronous code - not for now anyway. We still get the benefit of generating the bindings, so we can work with the same objects in Kotlin, Swift and Rust. We are also able to build a generic request in the shared layer and parse a generic response to a specific type. This still leaves some room for extensibility in the future where we can build more "helpers" on top - i.e. for caching.
A lot of this code was written extremely quickly to prove whether this approach works or not. So, it should be treated mostly as a throwaway code and not used in production. We still have a few things we'd like to test on top of this - for example Swift bindings and implementation. So, we'll merge it as is for now. Once - and if - we decide to proceed with the project, it should be relatively straightforward to clean up the code.
Note that the Android layer has some extra changes applied and removed in the commit history of this PR. I've thought about removing extra commits that we won't use. However, I found that I re-used some of the code I've written for previous experiments, so I believe there is benefit in keeping them in the git history.