unsignedapps / Vexil

Vexil (named for Vexillology) is a Swift package for managing feature flags (also called feature toggles) in a flexible, multi-provider way.
https://vexil.unsignedapps.com
MIT License
114 stars 11 forks source link

Thoughts on adding "in-built" support for external data sources (ie .`FlagValueSource`s?) #116

Open will-lumley opened 1 year ago

will-lumley commented 1 year ago

I feel like it'd be neat to have native / in-library support for other types of data storage types. Such as FirebaseRemote Config, Launch Darkly, or even GRDB, etc. If we're against it because it'll bloat the library, maybe we could have the support in another repo altogether?

Just thinking out loud.

arinjoy commented 1 year ago

Hi @will-lumley - thanks again for raising this topic. We are both on the same boat 🛶 seems like.

I am currently on a spike / feasibility study of using Vexil in a new app project (enterprise scale), where I really want to use Vexil and all its power/glory, but I cannot confidently go ahead unless I know how those remote systems (LD or Firebase, I am using another called Amplitude), can map into this system via custom FlagValueSource. I can see this a protocol I need to implement somehow, but not sure how do I precisely map those bits coming from remote system and what is the glue for the snake-case or kebab-case key names to the key names we define on the remote system portal. Still a bit of of mystery to me. Scratching my head 🤔, and not giving up soon. (hahaha).

https://github.com/unsignedapps/Vexil/blob/main/Sources/Vexil/Vexil.docc/Sources.md#source-hierarchy - tells nicely on the sources array but how to implement the MyRemoteFlagProvider() remains as a question.

@bok- / @huwr - either of you could come to rescue and give me little tips / pointers ? Thanks a lot! 🙏🏽

will-lumley commented 1 month ago

@bok- For what it's worth I'm happy to write these data-storage support myself - I just want to make sure I have the backing of the library before I do this.