Open Feature Project, 17 Mar 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: OpenFeature Project Meeting - Mar 17, 2022

Description

Regular project meeting, including OpenFeature PoC demo by Michael Beemer, discussion of the research and OpenFeature use-cases, planning for the specification v0.1 and outreach plans.

Meeting notes: https://docs.google.com/document/d/1pp6t2giTcdEdVAri_2B1Z6Mv8mHhvtZT1AmkPV9K7xQ/edit#heading=h.krf49umme596
OpenFeature website: https://open-feature.github.io/

A

Did the nth digit of fibonacci, uh probably not the best example, but it's just it's just one. You have to bear with me here uh in this case. Basically, when you go to calculate fibonacci, if you you can register your open feature, client.

B

A

We are looking for this fib elgo feature flag and if it doesn't exist, it's just going to run the default. So if you do not register any kind of provider, this will just run the default value. Why this is interesting is uh if we have a mechanism, it's either. You know kind of manually documented, saying like these are the well-known um feature, flag, ids, and this is the respect or the expected return value, or ideally, we could actually define in code uh potentially the expected feature flags.

A

You would be able to potentially wire this into a system where you could remotely control the flags uh without having to get in touch with, like the the library, authors or whatever. So there's a lot of possibilities here. This one is just kind of an interesting example showing how you could make you know: flag evaluations in a third-party library or, if you're part of like a big company with a monorepo that you know a package in your monorepo could include flag management that is optional effectively. So that's that was the point of this demo.

A

um If we were to wire this thing up into, let's say uh just because this was the last one I was working on. If we look at the harness demo.

A

We can go into here and now, all of a sudden, this code would be registered. You see it's all registering with harness if we go to run the fibonacci piece.

A

So you see it's a bit slow. If you look down here, it's showing what the uh running the recursive algorithm here, and so uh it took us a few seconds. So that's actually perfect. That was the expected behavior here. If we go into the ui now uh in one sec and we change the default value here,.

A

So when it's on we'll just say we'll run this algorithm and say.

A

Okay, let's see, if that not letting me save there, we go okay, perfect! So now we'll see that the change was pushed to the system. If we were to go ahead and refresh this one now we're seeing that uh you know the new algorithm is in place and it calculated much much quicker.

A

So the third part of the demo is now that we have this in place and we have a shared, basically uh developer facing interface. We can also wrap that with open, telemetry and create spans. So if we were to look into uh zipkin, so I just use zipkin as a way to visualize distributed traces.

A

This is just a really really simple, open source tool for for looking at distributed traces. If you look into here- and I were to run a query- we would see here's our fibonacci one, here's the one that took almost five seconds if we were to look into it, we'll see that now, there's a feature flag call here, you'll see that the call itself was actually really really fast because it was just evaluated locally.

A

What happened afterwards took quite a bit longer, but you can start to get a sense of what it actually did by looking here, seeing that harness was the provider in this particular case. This was the flag id.

A

um It was part of the fibonacci uh client library and that the algorithm was recursive, so you can see that it was very, very slow if we were to go back. Hopefully we can find one. That's a little bit quicker like this one or we're talking uh 3.2 milliseconds, and we look into here- and this was the different uh variation return type. So that was the algorithm that was run.

A

That is basically from the demo perspective. Was there any questions on any of that.

B

Just while you were saying that mike this decoupling is perfect for like unit testing and ci cd testing, like that's an issue that comes up quite a lot, um which we don't have a good answer for at the moment, flagsmith, um you know how people unit test their code with different flag permutations and things like that and just being able to decouple that from our api and put in some environment variable. That's like re, that's super powerful as well like, and the design gives you that for free, which I think is a really positive point.

C

Yeah, that's like a really good marketing thing right like if it I mean that's a really good aspect of having this standard is. You can have someone can build like a really good standard like overrideable unit test friendly uh feature, flagging implementation and, and you can just drop it in whether you're, using harness or split or your local internal thing.

C

I haven't thought of that either, but that is super neat because I've been thinking about like oh, we need to add something to the spec about how you can override stuff the unit testing, but you don't you just replace the provider.

A

Yeah, it's actually a good use case for a provider that I thought was not that valuable. So good point thanks ben, although you can.

B

Probably even go to the pattern, it's a pretty good.

A

Thanks cool, so uh let's jump right back into the presentation and, like I said, feel free to interrupt at any point. If there's any questions here, but uh I just wanted to kind of quickly discuss some road map and privatization.

A

um It's come up a few times, but really the focus so far has been on server side, I'd like to at least start or continue defining that and pretty quickly once we start to feel pretty comfortable with our design. There start investigating client side as well. It's similar but different in many ways, and I think a lot of people on this call uh understand that already so kind of understanding where the differences lie and how we want to tackle that, I think should be. You know a focus pretty short term.

A

uh It's something that I think it's it's an important aspect of feature flag management overall. So it's something I'd like to look at in the very near future. uh I just wrote a couple languages out here. This does not mean that that would be the only one supported, but it it's. What I would propose would be the first few that we would try to focus on and then expand. You know if everything looks good.

A

If you have other languages or your favorite language or whatever feel free to you know, add them help out there in any way, uh but this is just this is typically what I've seen in like open telemetry, where they'd focus on on these actually three languages for the most part, because they vary enough, at least to uh have reasonably high confidence that the spec uh supports.

A

You know the popular languages, basically.

D

A

I would say that.

D

On on the client side, mobile is a pretty different use case. Yeah.

E

For someone like.

D

Watching but I think it needs consideration that.

E

Was going to be my big point? Was uh ios? Android are two big client-side implementations that will be popular.

C

Yeah, I also say that, like most feature flagging that I see the the majority of feature flags that I see in the wild are on the ui. So um I like there's in terms of like how many people are using future flags in golang versus client-side, typescript or especially particularly javascript.

C

The vast majority I would imagine, would be client-side javascript is worth asking the vendors, because the vendors have got all the data right, but um it feels like if you want to go for the bank for the buck javascript and then maybe mobile or yeah. I don't know.

E

I would say just as a brief counter argument for that. My this is purely a guess, but my guess is that the reason flags are used in client side is because it's hard, it's very easy to do in the in a server side, because people essentially already do it with environment variables and whilst they're done as environment variables, you are essentially treating them as flags, um so yeah they're they're. They may not be using a uh a feature: flag provider but they're still using flags. In that sense,.

C

A

Yeah part of the reason I think server side is interesting in this case, because it does seem the most I guess ripe for, like I wouldn't say, disruption necessarily but like it could definitely benefit from some of the open telemetry aspects and some of the other pieces that we had talked about um client side. I think that's a little less obvious, um but I I still think we we have to do it. I mean it's, it's part of what people would expect. It also is like the easiest way to demo something like this too.

A

It's a very visual way of showing like this flag was just changed, and now you know you refresh the page or whatever, um and now you can visually see the impact that that flag had.

C

Another question I've got is, is, I would have assumed, react would be just like entirely kind of done in in user land, essentially like on top of the spec, rather than you know, when you've got reactor. Is this just kind of like a really nice example of how you do it in react, or is it actually kind of part of open feature itself.

A

Yeah, I mean, I think I I kind of struggled with that. To be honest, I I put it on there because it just it's it's what seems to be the most popular at the moment. That is something that that's probably the most controversial one on the whole list, so that one could easily be dropped or just have basically documentation around.

A

How you could you know, use it and react could be sufficient. Yeah.

E

Certainly there are, I mean from our point of view. um There certainly are uh the the the react. Implementation is javascript or typescript. That's what it's using under the hood there's very very little difference between that. We may find some some react patterns that we can apply and then build into the open feature. uh Library sets as as best practices, kind of things that's automatically done, but yeah the the actual functionality is typescript or javascript, rather than react itself.

B

We've had um we've had people ask for a react like specific library and we've kind of tried to put put it off, mainly because if you ask five people, what the react library should look like. You'll get five different answers.

B

But actually it's interesting because there might be some kind of primitives around reacts like hooks and things that you could maybe have as things um for like a yeah. You know that that's not like react but like map to react, um but I think just taking on a pure light. Typescript javascript initially is probably the best way to go rather than because yeah like everyone's got a different opinion of how it should how react. You know how it should work and react, and you just end up talking about something that you you.

B

You know you're really not interested in. It's just noise. I think um we've been we've given in and built one, but we know that it's, oh you shouldn't. Do it like that. You know so yeah. If you, if you don't have that conversation, then you don't have that argument.

B

I think it's a good like.

C

I I feel, like you'd, end up building it entirely on top of the spec, but it's a good way of hey it's a good way of kind of validating the spec, because react has some weird kind of things that would kind of, like.

C

I guess, pressure test the the spec a little bit. I think also it again, it kind of demonstrates the value of the standard. Where, like look, here's, here's a here's, a react like a nice, really nice, ergonomic kind of like react, nate like feeling um library that can plug into anyone. Who's got an open feature provider right because, because I'm sure so cloud b's have one I know split have one.

C

Probably every vendor has built like basically their own kind of like mediocre attempt to react uh thingy, because um it's a pain in the up in the butt, but you have to do it, but the idea of like being able to just have one probably someone who's not associated with any of the vendors building, a really nice one on top of the standard and then having it magically work is is like. I think that that would, for some people really help them click like oh.

C

Why is this actually a useful thing, because some people are going to like almost certainly people are going to be like? Why do you need a spec for feature flags? It's like one like method called. It returns a boolean, but so I think it's a good. It's a good marketing thing.

B

Yeah I mean this is a great example of like if there was a react open feature library that plugged into like our provider.

B

That would mean that we wouldn't have to write one, which is like one of the main points that you're trying to achieve right. We're trying to achieve for sure.

A

Yeah and hopefully, ideally in this situation, we could have you know some expert and react uh help build this piece. I think they're, probably people more willing to help uh and kind of a vendor neutral. You know open open component, I suppose, uh as opposed to like a vendor specific one, so yeah. um We can certainly chat about that. One I'll, probably open up a github issue around this, so we can chat about you know what we feel is the highest priority.

A

Mobile is a great point um and it's something that we should kind of discuss and see what the prioritization should be of that as well. uh Next next part was just the cloud native approach and, like I mentioned earlier in the call did try to decouple that one. So there was uh is basically the cloud native piece would be effectively just another provider is the way I was looking at it and we would probably focus- or we would focus on on kubernetes for that well in terms of responsibilities.

A

uh So this one is kind of open-ended, I suppose, but basically we're still working on the api and sdk research. I definitely encourage everyone. If you haven't already check out the research repo um open issues, that would be the best way to track. uh Basically, our conversations around different topics here, there's a few things like the the public interfaces.

A

uh Honestly, I don't really like what I've come up with so far and some uh we've had some good conversations around it already, but I think that would that could definitely use some love. So if there's anyone that has a strong interest around that, we could look at like the vendor landscape, documentation that we have and try to figure out what would be something that we could provide.

A

That would be easy to use and all the use cases we care about, but still be able to plug into you, know the existing vendors and then hopefully support future use cases as well.

A

We have a a ticket already open about context, so feel free to check that one out, but this is where, especially on the server there's some really interesting possibilities. uh This one is something I think we should really take seriously. um It's it's. I think a way we can really make the feature flag experience for developers on the back end, uh pretty slick you know it.

A

Would you kind of just get the it just works, because we're providing the context um at the flag, evaluation and- and it basically would be like a tiered system where you could have like a a global uh context. We- and I proposed it earlier this morning, possibly like a client context- maybe a request context so like it becomes pretty complex.

A

So that's something we should definitely discuss to make sure that we're not over engineering it, but um there are some interesting possibilities there and then we've already started talking about like how to handle default values through error handling things like that, and that's an area that I think uh we could definitely uh spend some time talking about. I think sometimes it's a little bit tricky to tell why a flag was evaluated in a certain way, because the default behavior is too effectively.

A

If something does fail, it returns the default value, but you don't really necessarily understand why. So if we could have some way of exposing more debug information, optionally, potentially um of course maybe some of the open telemetry integrations potentially help with this as well. But it's definitely a an area that we should discuss.

A

um Another piece is the cloud native component. This is something that maybe alex has uh would find interesting. If he's still on the call- and that would be uh something I'd definitely like to have um some feedback there, and then we need to start developing some proof of concept. You just see how that would flow.

A

um The way I see it at a really high level is being able to register uh basically the cloud native implementation as just another provider, but do it in some automated fashion, so you wouldn't actually have to modify your code depending on the language likely um to have the flag evaluations, happen effectively kind of automatically and then outreach too. There's also another discussion on our slack channel about you, know other vendors in the space and uh who were still kind of missing um in terms of like representation there.

A

uh I have I've contacted some of them, but I don't have the ability to contact all of them at this point. So if you do have any connections there, it would be very valuable to at least let them know that this is what we're doing um it's completely up to them. If they want to be a part of it, but um I think it would be nice to at least give them the heads up that they're uh that we are working on this and that's it. Is there any questions about any of that.

C

With I, I guess, with a couple of those kind of pieces, the the outreach and the um the research on the the existing vendors, it would be good to just kind of have maybe track somewhere in a git repo or something like who's tried who's talking to who- and you know who like because I don't know who's who's.

C

I've got some contacts with some of the vendors, but I don't know whether we've already talked to them or not, um with the outreach piece and then also with the with the spec and the research on the vendors api. It's something that I think would be as I was like looking through the code.

C

One of the things that occurred to me is it'd, be really nice to just have um how all of the different existing vendors do like their feature. The flag evaluation call, for example, because I kind of know off the top of my head for a few that I've used, but having that just like in a centralized place, I think, would be really nice.

C

I suspect, like you've, already done some of that right, like you've, already kind of gone and looked at some of the apis, but I'm not sure if, yes, I was supposed to look at it.

A

Yeah have a look at this and see if this uh I'm gonna put it in our chat right now see if that is useful, um or if there's information, that's missing and then uh yeah shout out to steve.

B

E

A

uh Adding cloudbees- that's that was great, so yeah.

E

Appreciate, if, if you want to merge that pr I've raised it's still, not uh it's still getting merged, um but yeah I was, I was going to say there is already that, but it is a little bit sporadic in terms of like here's, a couple of examples.

E

So as pete saying it might be good to have kind of the the the fairly common use cases of evaluating a boolean flag, a numerical one, a string, one which are kind of three main use cases and things like passing in context and then have like a uh how all of the different vendors implement that. So it's easy easy to see in kind of the grid tabular format, because at the moment it's here's a few examples and you're scrolling up and down the document. Yeah.

A

It's looking that's a good point, sure. Okay, that makes sense perfect. So yeah I mean the research is more or less there, but I think it's making it a little bit easier to digest would make sense, cool uh anything else.

F

Yeah, uh I put it in chat as well. I think we should get to a v01 of the stack rather sooner than then later and right now we focused a lot on like talking to vendors and providers, but it would be nice to so.

F

This is what each of like apr looks like, even if it's a very rough first version and maybe creating individual pr's for the individual methods that are in there like what I'm, making this rather big one and then having maybe a very uh very first, maybe assume that as you've shown it today, an implementation like maybe a file based one.

F

Because right now and the users cannot actually try anything- and I think we should get to that point where they can at least experiment with, I think those who can collect and use the feedback rather sooner than later. Even if it's like very simple v01 type of approach.

G

It would be really awesome and yeah in the chat I mentioned, that cube corner would be a good target and speaking of kubecon, uh there is some space at the cd events day on may 17th. So if there is interest to have a kind of workshop, maybe one two hours for discussions, maybe some demos on site- it's possible there. But for that it would also require some specification draft, maybe poc, to make it efficient.

A

A

All right, uh yeah, what else is there any other items we need to discuss.

A

I guess one thing to note: we do have a developer starting on monday, so we'll have some some additional resources that can help answer questions on uh you know on the issues and you can be a little bit more dedicated. uh You know to actually hands-on keyboard and you know writing code and things like that.

A

So definitely start looking at the uh yeah, creating those issues making sure that we have that the conversation going so that when you know he starts up, we can really uh get him up to speed quickly and we can start having tangible items that we can play with as soon as possible.

G

Another topic which I would like to bring up is about the bootstrap governance, uh so in the chat we tentatively said it would be much so. My question uh to the team is whether we are ready to initialize it, because this in cftc will ask about it uh when they review your application, but we can easily postpone it until april or may if you want to have more stakeholders joining before we really vote on these topics.

D

I think it would be reasonable to finish the vendor outreach um before we establish governance, because I would, I would suspect that there are some larger, like people in the space who would want to be involved in some of that governance. That would be my guess.

F

Yeah, I think we can celebrate a bit just like no magic. A massive decisions are taken but like following we've approached it open to land between has taken the most. I think they re-voted most of the governance team after the first year, so the first terms are significantly shorter in the beginning, from especially from the bootstrap team. I think that's also what we have here all like right. Yes,.

G

uh So I like, I can send the governance document, but in principle we start from bootstrap governance uh for five or seven people identical and then within two years there is a commitment to run teach the entire bootstrap governing board to all elected positions.

G

So initial uh list will be selected by all interested parties, plain majority who joined by the time of the election and then yeah. This board will define the new elections. That's the plan.

F

I think we could still wait a bit, but I think we should establish, as we want to make this across company effort to establish, rather sooner than later, um I think we can. We wait, maybe a couple more weeks, but it wouldn't wait too long. It would probably make rather the first terms significantly shorter and maybe even give the board the opportunity, like the the the boots report, to run an election even early after scene that it's a good idea.

F

That's something I would let him do if they decide, for example, to do it by the end of the year, because three more people have joined and contribution structures have changed. I think that would be fine as well.

D

Okay, yeah uh anything else. If we were going to coordinate on which vendors we've talked to, where would we put that information.

D

I'm looking at the repositories that I see and I'm not clear on where to start that thread.

A

That's a good question.

A

F

I would put it in community like community outreach yeah, but it's a good part of who we talk to that.

G

Would make sense, yeah just doesn't get happier.

A

uh That yeah, that would be fine. I think.

C

Do we want to include in that outreach? Do we want to include um open source uh tools as well? It occurs to me there's a few and it is they're kind of very obviously very kind of like text act specific, but there's a few kind of open source feature flagging libraries that have been around for donkey's years, some of them, um but so they've probably got some interesting.

C

um You know lots of interesting experience to bring and also would probably be interesting to to build. um You know providers on top of.

F

Yeah, I think, let's collect the list, maybe uh and then define who we reached out to just putting it in there as a doc and then just following pr, so who we should that we have a complete list of who we talk to. We want to talk to yeah, and so people can always engage with us.

F

Maybe, on the outreach topic so far, we have obviously, and by we mean the uh folks from on the directory side. I've done a lot of the outreach. I also don't want to exclude anybody from like being part of the presentation, uh just wondering how we should coordinate when we engage with others like who wants to be actively part of the presentation.

F

That's pretty much the presentation that mike uh did right now already so maybe put in who wants to reach out to specific uh other companies and then, let's try to find, I mean meeting time slot. It's usually hard if everybody wants to join, but when we have the companies there, you can specify who already has contacts with them. Who wants to join the outreach that we can then set up the proper meetings.

F

I think it was just a very long way of saying: let's get the list together, everybody mentions who they know, and then we get those people together and try to coordinate meetings with them sounds good.

A

Perfect yep looks like justin's, already put it out there too. So.

A

Cool all right.

C

Anything else the stuff- that's there so far looks really good. It's like it's pretty exciting.

A

Yeah thanks yeah, I uh yeah. Hopefully we can and appreciate all the conversation around that too. I think that that's how we can make this thing. You.

B

A

Work really well, I mean there's a lot of different use cases, a lot of representation from different groups here, so I think that will uh hopefully lead to a good outcome here and I think, like after seeing how it can how a provider can be injected kind of like out of the main uh like code base. I think that unlocks some really interesting possibilities so uh start thinking about different use cases around that too.

A

If we can have a better story about how you could use feature flagging in like open source tooling- and you know uh third-party dependencies and things like that- I think that could be even another aspect. That is completely I guess untapped by in existing future flag systems, because most people aren't going to roll proprietary feature flags into you know: public library, for example,.

C

There is, there is some prior art there. I know in the node space, there's kind of like a semi convention around debugs, where you can, where you you put set like an environment, variable, that's like debug, colon library, name or something like that, and so that might be an interesting thing to look at just in terms of how how that's been done.

A

For logging yeah yeah exactly, but I can see even.

C

A

Like uh I don't know, if we have a database driver or something like that, there's some changes being made, it would be potentially interesting if you could do it like make. Those changes only affect a certain user. You know, depending on the situation, obviously that's not going to be a universal solution.

C

No, I mean like I, I'm I'm, I'm somewhat skeptical on it being used for like open source libraries, but for like internal like internal migrations. I think this is like a super super common use case right where some platform team is maintaining the library that everyone uses to talk to the kafka instance or whatever, and they want to upgrade, and they want to do that in a controlled in a controlled way. That's like a total game.

C

Changer, I think even at big companies, they don't have the maturity to kind of do that in a really really controlled way. So the idea of being able to um use like that baggage idea or something like baggage and being able to push like try, upgrading some team's library to or you know, perform this migration to some team and then roll it back without having to coordinate a bunch of releases is is super compelling.

C

I think I I haven't really seen anyone doing that using uh liking a man in a really managed way using future flags. Maybe some giant companies do but yeah.

B

I think I could definitely see um like environment variables quite often get kind of I mean we've got like way too many and they kind of get abused, but there's kind of no other solution to that. If there was parts of an application um that had this plugged in but just had a like yeah flat file, there's a store of flags that you could, then you know you could you could just use it like that if you wanted to, um but you could, then you know plug in something more elaborate down the line like that.

B

I think that's a you know. That's really interesting, um rather than just shipping your code that doesn't work unless you configure, like 15 environment variables, the right way, um I definitely think there's. I think this is like the the like the reference implementation, backed by um a flat file or something I think it's actually. I think it has a lot of potential and, like then turning saying, okay, I'm gonna decouple that and provide like a terraform provider for these values, or something like that.

B

So then I see like there's just um but just having that, because you've got that built in from the start: you're not having to re-engineer everything just to do that yeah. That's really really valuable!.

C

Yeah having that smooth, upgrade path from just like flat files or environment variables through to like a dynamic thing, also.

B

C

Yeah, the idea of eventually not having to like roll your own and calling declaring defeat and going and using like one of the open source things or one of the vendors is, would be a big benefit to the industry, because it's way too much time is spent building internal future flagging systems that are not.

D

Yeah we're thinking about configuring. These various like back ends like the api that we have right now for getting a client, is like provide a string which feels a lot like the logger name or something like that um versus like. I need to provide an api token and I need to like I mean I like. I want to swap the implementation from a to b and we have libraries that need to be able to know this stuff.

C

Go ahead, I have a strong opinion that um you shouldn't make the the person who is evaluating the flag at the point of flag valuation. You absolutely shouldn't make those people be aware of like what the reason behind the decision is unless they have to so. For me, I think it's a lot of value and the dev just that the person who's like creating the ifl statement or whatever says you know. If it's on do this. If it's off to that, I don't care what the rules are.

C

I don't care if it's a canary release or it's like a premium feature or whatever. I just need to call this thing, and and so to me that points to at kind of boot time or whatever. Just like you would kind of configure your hotel thing, you would configure more than one provider potentially and and have them wired up in some some magical way, so that um they're able to decide like I I go to the provider and say: should I show the um the one-day shipping right? So that's a really good example of it.

C

Should I show free shipping and initially that feature flag? Is controlled by like a roll out because we're it's a new feature and we're not sure if we want to use it or not, so we're doing it like a release, toggle, eventually we're going to migrate, that to be something: that's like a permissions thing or like a premium customer thing, but I don't want to go back to the code and change it from like is feature on blah blah to his permission on blah blah. I just want to know.

C

Should I show this thing or not so the idea of being able to the dev? That's writing. That's at the point of the decision not having to think about that at all and you can kind of re re-point.

C

The decision from a release. Toggle type type thing that, like a product manager, is looking at to a permissions or kind of premium feature type thing: that's powered by knowledge of the customer. I think that's really an important thing to get right, because if it's like a kind of key concept in the the semantics of how the the spec would work, I don't know if that makes sense.

A

But you brought up the idea of multiple providers. I we should talk about that, maybe in a github issue, but I don't see how you that would work, but you could potentially wrap multiple providers in a single provider. If that makes sense.

B

A

B

You'd have to make the decision.

A

In in that, like wrapper, effectively like which which of the back-end providers would win, yeah.

C

You know yeah, that's what like. I think I think, if you put enough kind of a few key features into the spec around being able to ask a provider like hey, do you even know what this flag is?

C

Then you could build that kind of like multiplexing provider, basically like in user land and and kind of plug it into um to like you, could give it to kind of like um the actual kind of like the implementation provider so like in my example like whatever is the feature flagging system, that's doing, release management and then the other kind of internal system that's doing like permissions of like is this person a premium customer and then you've got the multiplexing thing on top and when you say hey is this feature, should I show one day, shipping, free shipping or whatever um it goes to each of them in turn and says: hey, do you know about this flag?

C

Do you know about this flag and then um yeah? Then you, you can kind of you've got like that kind of composability. I feel like maybe I'm getting a little bit excited and over engineering things, but I do. I I have a big passion about that. I just see so many code bases where they've got three or four different feature, flagging things and everyone's like. Oh, is it this kind of flag or this kind of flag? um So.

D

It would be really, you know, we have that set up in internally in ebay and it's something we're trying to remove.

C

And, like you know, almost always what what people should do is have an internal abstraction over all this stuff and that you, you just ask it that stuff. For some reason, everyone always just uses the the library, library directory or the vendor directly, which drives me bonkers, but being able to just kind of have a a thing out of the box. Sometimes you just need to give someone an existing tool that encapsulates that strong opinion and then they'll kind of do the right thing from the get-go.

C

Yeah, that makes sense. I.

A

Think you need some.

C

Some semantics in the spec to be able to power that so, rather than just so, for example, today I can't say I can't do like a kind of a peek of like is this feature on? Is it something you know about if it's not don't send any like telemetry, don't like for an exception I'll, just move on to the next one right, like the difference between like evaluate this feature versus?

C

Could you evaluate this feature um would be, I think, would be kind of like required if you wanted to do this multiplexing thing in a um kind of effective way, more efficiently,.

E

D

You can use that, like reason that you get back like how how it made its decision to kind of drive. Some of that also.

A

D

A

A few ideas around that so maybe that's something we could pick up on a github issue or something and kind of go through a few use cases, and I do think it ties back to justin's point about uh having probably better uh data about why yf like was, you, know, made the decision it did. If you could do that, and then you could basically combine multiple providers. Theoretically, you could really make some pretty intelligent decisions on which flight kind of wins in a scenario yeah.

C

And then you could build some nice, like more kind of for the for the happy part of case and more kind of nicer ergonomics thing where you just say. Is it on true or false for an exception? If I'm asking about something you don't know about whatever, but like the underlying kind of more powerful, richer kind of api is powering them.

A

Yep makes sense yeah. If you want uh please open a an issue, then we can chat about it. There yeah.

B

That that's a good point. I hadn't thought about that, like if you're changing your back end provider, you then want to be sure that you're not gonna. You know you don't want to be able to test that somehow, like features like like a future roll out of the roll outside.

C

Like yeah, like it's.

B

Yeah, like you know, I don't know yeah like is- is that how badly is this? You know data mismatching with each other um kind of like almost a meta thing, but yeah. That's, maybe down the line.

C

That's a very matter of thing.

D

For I think the next meeting, because we meet every two weeks, is that right, um I'll I'll reach out to some internal ebay people, so I'm involved in a thing in ebay to like build feature, flagging um and there's a very large mobile use case, but they have a very complicated system, I'll try to get some requirements from them about what they're doing and bring it to discussion because they have a lot of like caching concerns um specifically like I know some of them are you get a set of flags just based on the app version you are, and so you know that very early and it's highly casual information and then there's also some like.

D

I am justin abrams who lives in portland, oregon levels of information that is not very casual um and so being able to differentiate between those types of things um and kind of what their structure is I'll. Get some information on that.

C

Yeah there's like this whole spectrum of dynamism from like at build time. We know it to like at install time. We know it like at boot time. We know it to like at operation time or request time or something. We know it right I'd. Also, I just purely out of personal interest. I would love if you could find out how many future flagging systems are running in ebay, because I bet it's like over 50..

C

No, it's got to be more than that.

D

uh Four, if you count config but yeah, there's not many. I'm shocked. I'm impressed good job, there's one very large one for mobile. There's a experimentation world there's a thing that sits in front of both of those. So you get a consistent answer between the two and then there's config.

C

I've been pressed.

F

A

Cool um yeah we're just about out of time any last thoughts uh definitely feel free to open up issues. I think that would be a really great place to discuss a lot of the topics that come up.

A

A

Cool looks like we may need to potentially ascribe if anyone's interested um for next time.

A

Oh perfect, thanks, justin, well all right uh anything else.

F

It was a good meeting, yeah.

A

Perfect yeah, uh I guess we'll see everyone in a couple weeks.

B

Yeah, that's great progress mike hold on.

A

Yeah, thank you.

B

A

Talk soon, bye.