Mobile needs

[justinabrahms]

Hey folks.

I had a good chat w/ one of eBay's android engineers, @bfasching. He took a look at open feature with an eye towards what would work and what wouldn't.

There were 4 big things that came out of that.

1. We don't have a kotlin provider, so they basically wouldn't use our thing. They need support for suspend methods and flow to play nicely in their control flow.
2. There's no clarity around blocking vs non-blocking calls. Even though the providers will have a specific implementation, not knowing if you're going to make a blocking call is a big deal in mobile world. The risk to not getting this right is "application not responding" messages (aka freezing the app; eew!)
3. A mobile client should have some awareness of caching, especially in offline use-cases. This is something that can/should be implemented in the client rather than something provider specific.
4. When doing local testing, it's important to support specific overrides. Like, "don't call the backing provider... actually just return 9", even when that may not be the configured default in the code. I think we can do that with an aggregated provider that checks a local setup first.

He also demo'd a cool feature we have in our internal SDK that allows conditional defaults based on context. We use that, for instance, to provide different defaults for the German website versus the US website, because the app is aware of which site people use. The specific syntax was kotlin oriented.. but we didn't have an extension point where someone might do something cool with the default value. The best idea I had was we could maybe have another aggregate provider to check to interrogate the context/flag eval options to do the right thing... but that's really hacky.

Interested to hear others' thoughts on the above.

[beeme1mr]

Hey @justinabrahms, thanks for putting this together. It's very interesting to learn more about how you're doing mobile feature flagging. I'll have to think a bit more about your specific concerns. They all make sense but I'm not sure the best way to solve them at the moment.

Conditional defaults is an interesting idea. Perhaps we could do something similar if we allowed the after hook to change the return value. I'll have to think about this one a bit more too but I could see how this could be very useful.

[justinabrahms]

1 is pretty straight forward, though a fair bit of work. 2 could be solved at the client level by making it explicit that it's blocking or not. If not, we could name the method correctly or do it based on return type? 3 is also do-able, but is probably something that would be a bit complex.

I think conditional defaults may work if we did something like provided a thunk (delayed computation) for calculating the default in addition/instead of the raw value. So the param would be OneOf<String | Function<String>>, as an example.

I'm hoping to have a meeting w/ some iOS folks in the next few weeks.

[justinabrahms]

I had a chat w/ eBay's iOS group this week to get feedback about how they saw our spec / implementations. This is their feedback.

1. They need a swift provider. Async/await primitives are important.
2. The examples in the spec all were java, which made them think that was the actual API. They wanted to be sure their client wasn't java-y and played to the strengths of swift.
3. In our current implementation of feature flags, developers are not allowed to pass strings for keys. Instead, they get enums which are code-gen'd. This lets them lean on the compiler to ensure flags are removed.
4. Hooks were not well understood.
5. Experimentation is a key concern for them and is intrinsic to how eBay thinks about flags. They were worried about regressing to a time where they had to juggle that manually. They have a solution internally, which probably means someone should write about it.
6. As it relates to flag lifecycle & experimentation, they have a pattern where sometimes they'll query for a flag value early and actually use it much later. In that time, the values may have swapped. As such, I think they want the ability to include other metadata along with the EvaluationDetails (like timestamp of fetch, etc)
7. They were concerned about the way that defaults were passed in. It sounded like in our current world, they configure the default value for a flag key/enum in a single place. This prevents the issue where you are using the same flag in 3 different places, but have slightly different defaults.
8. Mobile has specific needs around caching and timing. While a lot of this is up to the provider, they will need to have an understanding of if something is a cached value. I don't know how we'd represent that today. There are a few states they care about: default, cached or live.
9. They also care about transfer size. In the current model, they have what amounts to server-side rendered values. That is, they don't ship the rules down to be evaluated on the client, but rather just get the mappings of true/false/etc for each of the known keys.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in next 60 days.

[marandaneto]

1. Makes sense but not sure if this should be builtin in the open feature spec, which can be easily done as a thin wrapper on top of the Java SDK, as a Kotlin extension, would probably require multiple packages as well because there is Flow, and some other types/libs as well, but making it suspendable is already a good start. Do not forget about KMP, at some point a full Kotlin rewrite would be needed.
2. the SDKs could adopt the async/await, suspend, Future, Promise, or whatever makes more sense in the specific SDK/language. One important note is that Android cannot make HTTP calls in the main thread, so even if it's a blocking call, the request has to be done off the main thread.
3. The caching mechanism probably varies a lot depending on the provider, not sure if it makes sense to have this in the open feature spec, maybe a Cache interface would do, but the implementation is up to the providers.
4. Good point, I agree that the SDKs should offer a user-friendly way of unit testing things, this probably makes more sense in the Provider itself tho?

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in next 60 days.

[github-actions[bot]]

This issue was closed automatically because there has not been any activity for 90 days. You can reopen the issue if you would like to continue to work on it.