4 ms·
From the previous article in the series: > Our problem is further complicated by the fact that we’re not shipping an app but a framework for others to use in t
by aazaa 6y ago
From the previous article in the series:
> Our problem is further complicated by the fact that we’re not shipping an app but a framework for others to use in their own apps. We have to be mindful of the impact our technology choices have on our customers, such as the potential for harmful interactions with their code, and user-visible performance impact in terms of CPU and memory usage.
https://bionic.fullstory.com/rust-at-fullstory-part-1/ https://bionic.fullstory.com/rust-at-fullstory-part-1/
Without knowing the details, framework-as-a-product argues strongly for a native-only approach to me. Xcode + ObjC/Swift on iOS and Java on Android.
The article(s) might make a better case for polyglot by talking in detail about what the framework does in more detail. The bar for going in that direction would be very high for me.
- tedmielczarek 6y agoThanks for the feedback! You're right that describing our usage a bit better might have helped clarify our thinking. For the record: the FullStory product is a session record and replay tool for both web and mobile. We record details about how your users interact with your site or app and you can watch replays of them as well as get analytics across sessions. Privacy is important to us, which you can read about here: https://bionic.fullstory.com/private-by-default-mobile-analytics/ https://bionic.fullstory.com/private-by-default-mobile-analy... The bulk of what we're doing in Rust is data serialization, along with business logic, part of which is a state machine and part of which is applying specific rules to app content. We did have fully native implementations of this in our prototype. Supporting two parallel implementations would be way harder for us than supporting our Rust implementation. It's hard enough to support the code that's platform-specific by necessity!