Open Feature Project, 31 Aug 2023

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: OpenFeature - Project Meeting, August 31, 2023

Description

Meeting notes: https://docs.google.com/document/d/1pp6t2giTcdEdVAri_2B1Z6Mv8mHhvtZT1AmkPV9K7xQ/

OpenFeature website: https://openfeature.dev/

A

Okay, um I guess uh we'll get started as soon as we're at three after uh I see some people who I don't recognize um you're under no obligation. But if you want to feel free to raise your hand physically or with a reaction- and you can introduce yourself um but but don't feel obligated to do that.

B

C

B

Yannick uh um engineer from Google uh Dominique, a colleague of mine has already been here a few times and yeah. We are interested in open Future and we came to Jane listening to what you talk about and above the details of the project.

A

B

A

And as Stacy mentioned, uh we have notes here. um Camille is uh I, just think you're new.

A

I can't seem to hear you I, don't know if you're muted.

A

Okay, um it looks like uh Camille's, also from Google, so good, to see you both here, um hello, Dominic as well uh yeah, so uh we have a decent uh attendance. It looks like um I'll get started with a couple small points, um but feel free to add yourself to the list like Stacy mentioned, uh I'll, try and keep notes as we go um uh so I'll be described for today.

A

uh My points basically I already have my notes, so I don't expect to have to type too much more, but I'm sure um I'm sure I can keep up if we need to uh so. The two things I want to mention. First um I'd like to release a spec zero. Seven zero I mentioned that last.

D

A

uh And I think we're at the point where we actually can do that now um you can see a diff there in the in the notes, um it's very small stuff and in fact it's been implemented in a couple. Sdks I think the go. Sdk almost has a lot of this Behavior already the JavaScript SDK has a pro for it.

A

It's it's pretty small, there's, like one extra provider state for completeness that we're adding um and also we're adding some gherkin test Suites to the spec, which previously were in a different repo, but I, think it makes sense to add them to the spec. So we'll publish that and then make.

E

Those a little bit more available for.

A

For people to run gherkin Suites against, um does anybody have any questions or comments on that? One specifically.

A

Okay, I'll definitely post something in the open feature Channel when I open that zero seven zero PR. But it's going to be much smaller than like zero. Six zero, for instance, which had a whole bunch of new stuff.

A

um Also, the we have an unreleased uh react SDK. So that's a big development. Since the last meeting um you can see it there. It is in the JS SDK repo. So it's it's that's a mono repo. It was already previously.

A

um We have the web components as well as the node.js or you know, back-end components um and now we're also publishing react. A react, uh npm module where we're ready to publish a react, npm module! um It's it's not complete! It's not code, complete I, don't think we'd want to publish what we have there now, um but feel free to open up issues create PRS I know: Lucas has been in there with a few proposals, um and so uh yeah really I. Think my call to action on on this meeting about the react SDK is.

A

We would love to have input, so if people want to open PRS to contribute to it, if they just want to open issues, suggesting how the API should look, it would be great to get that kind of feedback. The really nice thing is it's built on top of the web SDK. So there's not a lot of code that we actually seem to have to write.

A

um It's basically just adding react, react apis on top of our existing JavaScript web components.

A

So if you guys know, um people who you know are uh enthusiastic react developers, um please refer them to the issues, refer them to the JS SDK, and it would be great to have more more input there.

A

Any comments or questions on that one I think I put links in the notes.

A

Okay, that's all I wanted to talk about, so it looks like we have a topic from from Dominic now uh about flag definitions.

F

Yeah I saw that already mentioned before, and I saw also that open telemetric has some definitions for even naming conventions for four things and I was thinking. Should we also have some more more deep definitions because usually feature flux or experiments. There are some logical conditions and- and things like that, and some things related to that and I was you know uh thinking. Would it be beneficial to have that? So we can share that. Also this kind of things it's open question.

A

I'm really interested in vendors takes on this. um Like I, don't know if Ben has any has any opinions on it, but so I think, like the big, for example, one of the big um we've talked about this before one of the big value propositions here for the industry could be, for instance, kubernetes.

A

You know you're, defining Flags in a crd and if you had a consistent definition for Flags vendors could write operators that would reflect those flags and crds basically into their infrastructure, um so that right now really open feature is focused primarily on like evaluating feature Flags, not defining them in infrastructure, but I. Think it's a super compelling idea.

A

I. Think Dominic, like you were alluding to the biggest challenge, is describing conditions in a consistent way like you can define a state for a flag. You can find the type for a flag and I feel like you. Could you could do that very easily? But then, if you want to Define expressions, um how would you? How would you map that into vendor systems? That would that's where the big challenges I think.

G

G

From people here from our development teams, they say they would like to ship deflect definitions alongside the code, like even independent of the system, is eventually going to be used, but it's we know we need to parse the entire code to know which flags are actually in there, which I think the biggest downside of feature Flags right now, because they're defined in the code. But you don't know that they're there, like I've, seen some teams uh explicitly requesting this.

G

Like can we ship which flags we are using in some format that gets them picked up by systems and even like flagged as part of a deployment? Hey you're using a flag? I, don't have a flag definition for this I'm, not sure whether it should actually deploy this I, don't know Ben how, whether you got any requirements from your customers on this, like in a similar way.

E

E

Not we not well, we kind of wrap this generally. This use cases solve with terraform for our customers um terraform be interested in Jonathan's thoughts on this as well like. We was quite surprised how popular it was after we launched it.

E

um One thing, I, don't know about, and I don't I've, never done this and again like I, don't know, maybe Jonathan, if you guys have is like I mean I, is if anyone's done a um a survey on how much of a common denominator in terms of the different rule types like match across vendors, I I know like just anecdotally that, like you know, because they're all trying to achieve pretty much the same thing you know there are, you know, definitely like simple operators.

E

You know like greater than or less than or equal to or whatever that I'm I'm sure, like the majority of vendors, have um but I mean I. When we start when we started this project, I was always kind of like that's.

E

Never gonna happen right, like as in you know, but I don't know, maybe there's a way that if we had like a a kind of a full set of like every provider that every every vendor that has a provider in the platform, if we were to like build some big ass Matrix, that would be really boring, laborious job and figure out.

E

You know which ones which which um you know, which which rules uh uh uh provided by which vendors and then we could potentially just say. You know yeah like there's a semba greater than operator in Dev cycle and flagsmith, but there's not one in blah, and if you use that it will know what you know but I you know. Maybe it is time to kind of look into this I don't know because it that doing that work would open up a whole ton of new capabilities, I. Think of the platform.

E

It's just something that, like we've, never done it for sure. I, don't know Tony. If any, if you're, Mike or anyone is like you know, and and then there are definitely, um uh you know ways to shoot your feet in terms of like you know, maybe you know two operators across two vendors that might seem the same, but then actually are subtly different and things like that and yeah. So it's kind of like it's like yeah that that's that's my thoughts on it I mean just anecdotally, I think I.

E

Think probably like you know, I well, I I can't and you start hitting little edge. Cases with, like you know, I, don't know like uh very very value types in different languages, and you know whether a greater than is you know, blah blah blah so yeah I don't know. There's definitely like there's definitely Minds around this stuff, but I do.

H

There's also different approaches with like how strict certain platforms are on like data types like I know, launch directly is super loose like you can Define like you could Define something in their interface. That, like is for a different data type like it's, for, like a number where the underlying value is like supposed to be a Boolean or something right, and they just like kind of silently fail and whatever, where we try to be a bit more strict and we've actually also added, like we've added schema support to our system.

H

So you can Define like what your own schema is, like kind of like Json, schema style of like here's, what my custom data looks like and it's like kind of a type schema right um and also I, think there's a couple other vendors who are moving more towards that.

H

So there's a bit of that too, where it's like some folks are just very loose with their schema definitions and like and and their data, and it's just like it's just a raw Json data and then other folks are moving towards more like schematized and and stricter typing and stuff like that. So um that's another challenge with this. I would say.

E

Yeah I think, like the typing, is definitely tricky um that that, in fact, probably like aggregating that stuff, that is probably going to be more. You know, because the greater than the greater than right but yeah like what, if you do greater than tree or something you know, um and how different vendors, because you've got different vendors and then you've got different land. You know, we've got all the languages from different vendors and that's something that we've found quite painful is dealing with different type systems and stuff um yeah.

A

So so there is I like this is the type of challenge that like to me. This particular challenge is the biggest hurdle with this entire idea and I almost think that you couldn't I almost think that it's unsolvable, if you're hoping to map some kind of consistent rule set into an existing back-end implementation, I I, think what you would need to do is use some sort of expression, standard like Json logic or Google, has cell, if you're familiar with it, Cel common expression, language, which is a it's an expression language.

A

It's a portable expression language, so you I think you would need to use some kind of consistent expression, language that is already a well-documented standard and then say: okay, our our back end is going to support. You know our normal rule, rule sets or whatever, but we're also going to support cell.

A

And so, if you define your rules in cell, then you just use a cell evaluator so like or Json logic or whatever it might be, um but yeah my That's, my kind of high level, you guess at what would be necessary to solve this and I. Don't know if that would be a non-starter for some vendors. It might be.

E

B

E

Todd I'll cut you off um Dominic. What's your use case for this.

F

So so, basically Google has also internal language for defining features and logic in them and then generating the libraries in Native languages. But we are also looking to this open feature and I think it will be beneficial to have definition of the feature, a little separated from the technology itself which implements them.

F

So it can be done easily reused across different Technologies, like this Java golang, and things like that, even if it's not strictly everywhere working the same way, because those Technologies are not the same at least having this definition uh would be beneficial because, usually you are comparing the values. So you have this greater or you are doing the sharding operation when you are looking for for for sharing or maybe defining some small small logic.

F

D

F

But of course it must be rather inclusive for for everybody, so you don't have to be so specific, maybe on the definition level, but but I think it will be beneficial to at least have some some naming and basic uh operations defined, and maybe this basic things plus some extensions uh provided by Verdo vendors, could help being more portable on the definition level. Of course, you need the whole chain of tools to to work with it, but, but if we agree to to something, maybe it will be easier for the customers.

H

Dominic correct me: if I'm wrong I talked to somebody from Google a couple months ago, and they say a lot of their teams are, are sort of using flags as like static configurations, similar to like terraform or like you're, you're, sort of defining your flags and your audiences sort of in a in a more sort of static terraform like configuration, you do PR requests against that.

H

It builds sort of a static configuration and, and a lot of like our systems that, like Ben and I run, are more Dynamic, where, like we have a dashboard interface and and like product managers, can go, enable and disable flags and stuff like that, where it seems like what I understand. Google operates on more of a sort of like a static like um uh more I would say, back-end, engineer or engineer, driven um uh release process is.

F

That correct so so maybe Camille can can tell more because he knows more in that area can.

I

You hear me now because I had some problems.

F

I

Okay, okay, thank you so like I didn't have a chance to introduce myself so hi I'm in Camille I'm, a software engineer at Google. We are all like. All of us are like all three of us who have joined her from Google Cloud and, yes, we are like deeply involved in the experimentation in Google Cloud. So back to the question, uh so I believe that at Google, yes, we do use static flux with static configuration, but the technology that we all are developing are actually Dynamic.

I

uh Dynamic configuration driven flux so so uh to make sure like we have the same understanding. There is a there is a service running. There is a binary running somewhere on the server and the flags are evaluated based on the configuration that is dynamically dynamically delivered to the running binary so that they they change dynamically during the runtime.

I

But it is like this flux might be used for like just enabling feature flipping just flipping flags, and so that, like the the feature is gradually enabled and then the flag is removed and but also they might be used for some static configuration, but in a sense that yeah there is some configuration flag that we want to quickly change dynamically or maybe uh have this configuration take different values, depending on which customer the request, like the like? What what is the the customer who sent the request that the server is is handling so yeah?

I

These are. These are the use cases. So does it answer your question.

E

A

D

Think, like this is actually interesting.

E

This is, this is I think this is probably like the first time like I can think of a bunch of stuff that this would be useful for, like in or for the flights with platform. Sort of speaking, um like you know like it would help us build stuff into flag Smith. So it's like from a selfish point of view.

E

This would be super interesting because we could start to Define yeah, some sort of like way of formally defining what we call segment rules um which would help with a bunch of stuff like being able to Import and Export to different platforms, or you know um so, there's def, there's def it would, it would definitely be like it would be valuable to us over and above open feature as well um yeah.

E

Maybe it's maybe maybe we'll try and spend some time. Looking at the looking at some different vendors and and seeing.

G

Yeah I mean I think it's definitely worth at least creating an offap for it. Or will we use a GitHub discussion? I mean thought you might have videos I would best structure it for the project, but to I.

A

Think so I may have already created a nofap correct me. If I'm wrong Dominic did you did you create one at some point.

F

I think it was not maybe directly for that. Okay.

A

Yeah I mean that that may be. That may be a a good place to start I mean it. Nofap might even be too um too much at this point, because we don't we don't have very much that's concrete I mean maybe it could be a good uh place for an org level discussion.

A

You can do or a couple discussions now in GitHub, so we could just do something more free form and then, if, as we come closer to maybe some kind of some kind of at least hazy goals, maybe we can have a an offep but I mean um I, I. Think there's a lot of interesting, interesting stuff here and a lot of potential um I I mean I'm.

A

Always thinking about this in terms of kubernetes I mean kubernetes is the de facto way people are managing Cloud infrastructure these days and if you can have an abstraction for something like increasingly, you know, there's more and more abstractions that are being um kind of made. First class kubernetes uh API objects. If we had feature Flags in there, I feel like that would be a huge leap forward in terms of this as a practice right.

A

um So I I think that would be great, but it would require us to do this kind of work and I think we're basically some of the best positioned people to do this. In terms of your specific question earlier, Ben, um Mike and I did do a little bit of Recon in terms of the availability in terms of like expressions and stuff like that available across vendors I, don't know if we have that captured somewhere.

A

We might like, as part of some of the initial work we did when we first started open feature, but there was a lot of variability like things like sember and like our some vendors have them some. They don't like. That's a really good example, because it's a very specific feature that some vendors just don't have um and also like yeah different kinds of comparators yeah.

A

So um there's a lot of work to be done here, but I think it could be a huge next step for the project and and uh and a cool thing to have across the kind of Tech Community and the future flag practice. I guess.

H

I wonder if the approach of like there's always the approach of like creating an open, API spec of like how how we'd like it to to work and then creating sort of translation layers between the different providers like there's, obviously going to be edge cases on that, um but I wonder if you could, if you could call if you you could handle some of the errors of that gracefully, that's kind of what we've done, like we've created an importer from launch Darkly and for some customers who are transitioning and that's kind of what we.

H

What we were able to do and I wonder if you could do that in a more generic way, where you create, like a a common importer across different languages to to a common spec and obviously the Importer would like. Let you know of things that are incompatible.

H

um It's not a perfect solution, but um but that is one solution. I know we have some customers who who do that and like through their transition process. Just like run that importer every day or something like that to make sure things are. Things are in sync, but um but yeah foreign.

E

Like there's a bunch of stuff, it would help with, like you, could ship like defaults with complex rules um for things like it would definitely help in terms of best practice.

E

um Yeah I feel like it's probably time to sort of like look at the you know Mountain, um and maybe it's maybe it's not as um maybe it's not bad. The other thing I was thinking was um flag. These kind of it it leverages um I, can't remember the light, there's a library that it leverages for this right. It.

A

Is Json logic is what flag do uses right for for kind of a standard for rules? So that's why I brought Jason logic up like I said: there's also, there's also a cell but um yeah it does, and that was mostly out of just like pure efficiency like we. We didn't want to invent some kind of expression language, so we just looked at what existed in many languages and used that, but.

E

I think just on account of the Paradigm that we're working to they would need it would need to be extensible right like we could potentially use those things, maybe like the schemas of those things as a starting point, but just by definition like I, think well, I can't think of any that we've blacksmith's got itself but I'm sure there are vendors that have.

E

You know like like some sort of product, specific thing or or operator, or something that you that wouldn't actually live in a general purpose. Expression, language definition, I think they.

H

Know a bunch of people have like csvs or my trackly has their like their big audiences. They call them or whatever, which is like external store of audience data so I know other, and a lot of those are are really powered by a lot of integration.

H

So a lot of flag providers like integrate with things like mix panel or amplitude and those places actually manage a lot of your audiences for you, and then you use those audiences within your flagging provider and those are generally like kind of under the hood, basically just CSV Integrations, where you're you're you're, basically keeping an updated CSV on a CDN somewhere and accessing that, and um and that's where a lot of a lot of those. So there's there's a lot of Integrations like that that maybe I, don't think, would fit very well into this.

H

This this setup.

A

um Yeah, specifically, um that's interesting about the external like large external audiences, because that's something we've we've tried to at some in a more naive way deal with in in flag D, with like basically trans things you can transpose into the rule site, which could be quite unwieldy to manage directly and repeat everywhere.

A

um The other thing is uh is like December stuff, so that's like sember, for example, or even like a fractional evaluation like doing random distribution, random and uh well really it's pseudo-random and deterministic distribution.

A

um That's obviously not part of Json logic, so we've added custom rules to Json logic, kind of like you're, describing Ben um to like extend the feature set so yeah. What whatever, if we were, gonna, try and standardize on some kind of language like that extensibility would have I think have to be important. Yeah.

H

Like I, don't think the basic like Boolean, like like the basic logic, stuff I think is, would be pretty easy to map. It's like it's the distribution project, the um the rollout logic like um big audiences, like those are the the sticking points, I think um frankly,.

E

I I think like yeah, the the percentage split like I think I think everyone's got like a different way of calculating that, but like maybe based on two or three different approaches. I know like we're the same as some other folk as well, in terms of like making sure that experiments are sticky to users and things like that, but I I think you know I think you could probably get it would be. It would be super useful.

E

You know, even if they were even if it, if it was only a subset of like for a flag, Smith's rule set um I still I still think it would be useful and then like being able to like I, don't know like ship those rules as as part of a release or something so that you know, applications have like same flag defaults that can have sex there's a bunch of stuff that you could leverage with it. Yeah.

A

Okay, well at the risk of spending too much time on this very interesting and potentially huge topic, I think we'll move on unless there's any last minute final thoughts. Anybody wants to add um I, think I, think the call to action is uh I'll, set up a discussion and I'll try I'll advertise it in the channel um and uh like I'll, just set it up org wide, and we can put some of these thoughts there, like I'll, start by dumping.

A

Some of the thoughts that were mentioned in this meeting there um and I'll also try to see if I can find any research from like the the Inception days in terms of um what particular Expressions um and operators are supported across vendors. I can't remember: if we have a document about that or not.

A

um Okay, the next topic I, will go to Yannick, I I hope, I pronounced your name right this time.

B

Yeah, that's correct, so I I think the question was actually fairly simple. uh What is the rationale for having default values in flux like in in the API I I can see, definitely one of them being that for some vendors and external IP call is needed and it can fail for whatever reason and we never want to fail on the evaluation of the the feature flag.

B

That's that's being that that seems obvious to me, but is there anything else behind this decision to have something in the API so so for the context why I'm interested in that is? We are evaluating open feature uh for internal usage and with quite different part of igmat uh on that and would like to understand it's the different approach and I would like to understand like why to go this way, I'm curious about the decision behind it.

A

um Well I mean I can say from a historical standpoint, uh yeah the reason you mentioned, whereas, like it's a kind of an obvious fallback mechanism, but the other thing is a lot of the sdks that we kind of um uh wanted to make sure we were compatible with also have defaults right so like if you look at I, think even both the vendors represented in this meeting have defaults in code.

A

So correct me if I'm wrong guys, but um it's pretty it's pretty common, um but we have heard people request, and maybe this is uh maybe this is what Giovanni might talk about kind of alternatives to providing uh default directly with every API call, so that that's my that I guess. That's my addendum to your your guess.

H

Yeah there's various reasons like it's: it's basically a code safety thing um it's like yeah, if, if the SDK fails to start up for some reason, it fails to connect to like a CDN to download config or something like that. Obviously you want you want something in your code to run.

H

um There's also like type mismatches so like. If the type returned from uh from your server, is it different than the the default type that you're using? Then you always we base most providers default to whatever you set and don't change the type of that value under underlying you. So that's a big one, um um but yeah and generally it's mainly a safety mechanism. uh I agree that, like default and code, aren't the best solution for this.

H

Ideally like I, think for a lot of our client side, I think pretty much everyone's client-side implementation of this stuff. Generally, you you go to some cached config value like the you default to like the previously cached, like um version in like local storage or cookies, or something is generally better than your default and code for the server side is a bit harder to do that. So maybe something that you can bundle in like I know we have like.

H

We have kind of like type files for typescript that we we we sort of bundle in like a set of defaults with strict typing um that are that are up to date with what's like what what what the values were set um um at the time of the compile, um which are probably better defaults than just like, whatever you put in code when you created the flag but yeah, that's that's generally.

H

um Thank you behind it.

B

So if I understand correctly, the last idea is that, at the same time, you package your binary or code. You also package the latest version like at the same time of the flags and that's what you ship as defaults in case of Errors when connecting to obtaining the values dynamically right. That's.

H

One option but like I would say for most platforms: they just whatever is the defaulting code and is what's used, but at least on the server side. Client side is generally whatever the last cache value is um so I.

A

Would say from another like going back on the topic of safety? The other thing is even even if you're retrieving something from cash like a lot of cash. Retrieval mechanisms on various platforms are still not absolutely guaranteed, never to throw an exception right. So if you have some possibility of exception somewhere in your code, the ultimate like you can handle that. However, you want, you can have try catches everywhere or air handling mechanisms relevant to the language in question, but having available at call time the default. So no matter what happens?

A

That's what you would you know ultimately are going to fall back on fits with the Paradigm of not not ever throwing, which is generally how we approach things in openfeature. We never want to actually throw at runtime if there's if something has gone horrifically wrong at the end of the day, what you get is the default, which is again consistent with what I've seen for most most vendors. Nobody wants their feature flag um evaluation, to throw exceptions.

A

At the end of the day, you basically choose a least harmful default path and that's that's kind of explicitly um reflected in your API with the default value.

H

I would say, there's also two approaches to like how defaults are used so, for example, like launch Darkly and some others, maybe that's how flagsmith Works um they will basically in your dashboard, always have you set like a a default value in your interface right so like even if your flag is off. Their servers are serving a value for that flag right, um even if you've disabled the flag on their website um where we actually operate a bit differently.

H

We chose to like not do that and we're like we if your flag is off we're using the default value in your code. So that's another difference between platforms where it's either like this, the the provider is always providing a value and and generally like 99.9 of cases or even higher than that. It's using a value provided by the server um where we're we're our our systems um more often you're using the default value. That's in code, if you, if you've disabled a flag on our on our server. So that's another difference. I would say.

B

Okay, just quick questions; I'm, sorry, I'm first time here by referring to our system I'm.

H

From Deb cycle, yeah, okay,.

B

Thank you thank.

H

You a newer vendor yeah.

I

C

Maybe maybe one thing I don't know if you've seen that, but on the other hand, if you like to handle that um you at least have the information that you get the that you get the default value right so uh always in the fake evaluation. You see if you are looking at the details, that the reason is, for example, that you got the default value. So at least it's uh it's visible to you. If you like to know that currently.

F

So in post evaluation you can emit the metric about that or log.

C

Now, or maybe throw a few, even if you answer that yeah.

B

B

A

You for the explanation, nope no problem was there any other questions you had as follow-up or another.

H

Thing is maybe, as part of like I know, a lot of the initialization work. We've done to add, like an initialization status, to open feature, you could potentially catch like a failure of initialization and if you want to like exit your your server-side app because like if you didn't things, didn't get initialized properly, that's another choice you have where you can. You can know in that situation. You're, basically always going to get the default so like. Maybe you just want to exit um your process in that situation? Yes,.

B

I've seen that addition to to the API that uh right now you can block at the initialization level but still like, if that's something external, that you need to call, there's always a chance that there will be some transient errors that will result in in returning defaults and but yeah uh I I. Don't have any follow-ups uh I, just something for us today, just and part of it, and just maybe Camille uh yeah.

I

Maybe maybe one follow-up, so definitely we we could potentially be using this like blocking initialization Pub, because this is how our internal experimentation system and Google works, but I'd like to to check with you how we would implement the following use case. So let's say that we are using a configuration flag that might be having different values for different customers. So that's like for uh for like regular audience like it has some some integer value, but maybe for super large customer. It has like a very different value.

I

It might be, let's say a scalability limit, so in that case I believe that's falling like in some cases, I believe that falling back to some default, like maybe like this default value for the general audience, might be quite harmful. Maybe in that case, I would prefer to file the request uh instead of like switching instead of falling back to the default. What is the best way you would see for doing that, so can I just seem so yeah.

C

That's basically what I, what I meant with you can see for the evaluation details, uh why you got the specific value and one reason is that you got the default value yeah and then, as you said, if you want to fail there, you could throw, for example, um I mean in the end. That would be the same as you would do if you, if it would be throwing from the beginning on just that, you have to emulate yourself and then you have to be aware. That's for sure now, I.

A

See yeah I see, okay, expand on that. Even you. You do understand that it's the default for for one reason and exactly the semantics of that is different provider to provider. The other thing is, you can also understand if it was an error that kind of that caused it too. So you can check to see with the if it depend if you're, using the more detailed API which doesn't have any real performance consequences um it just it will give you additional metadata.

A

um You can see if this reason you had the default was an actual like error case, and then you can choose to throw if that's really what you want to do. That's kind of the idea behind that API.

I

I see I, see so could I install some hook to throw or things like that or would I because, like let's say that I want to avoid falling back to def14, all of the flags would I mean. Would that mean that I would have to implement some wrapper on top of all the flux or or maybe there's some way to plugging? In such logic, in one place,.

H

Wrapper, probably easiest, but.

A

Yeah rapper would be one way to do it. You could do it with a hook too.

A

um You can either do it with a hook on a particular evaluation or a general hook that was configured to like be sensitive to some certain flag, keys, I, don't know which pattern would work better for you specifically, but even if you used a hook, you would still need to use the more advanced API, because even if you throw in a hook, it's still just going to at the end of the day, cause an error uh and a default, because we we never throw the only.

E

A

Throw is on like initialization and configuration kind of stuff.

I

I see I see. Thank you.

A

uh Okay seems like we're kind of at the end of that topic. uh Giovanni. um This seems somewhat related, so I'm interested in what what yeah.

D

It's built on top of what we just discussed, but uh instead of why we have default. What? If build up my default? It's quite expensive and it's evaluated on a critical path of my code. I, don't want to compute the default value until it's strictly necessary, because there is a failure uh for Boolean value. Maybe it doesn't make much sense, but if you think about I want to build an URL that is based on the request. Maybe a tenant ID, it's necessary to build up this URL.

D

So every request, although if we don't need to use the default value, has to compute this request, ID to an external call, fetch it build the string and it's never used so would be possible to change the spec or SDK to allow a callback. So this expensive call is resolved if and only if there is an error.

F

So it's like lazy usage, yeah, basically.

A

D

H

Idea, you could do something like what I just posted in the chat there, where you do.

D

E

H

But I think the risk there is that, like we can't because we're not about like we don't have the value. What do we do if that Anonymous function or promise or whatever doesn't actually return a value like it returns, nil, right or no, like that's the that's like in the in the Loosely typed languages, which we support um it'd be hard to enforce. That.

A

Yeah I mean you: could you could you could force that say in this API you define a function and also a value default, and then you have a default for your default, um which might be a little bit confusing, but uh it's an interesting idea. I I, don't know. um I'm I'm, certainly like interested in the proposal. I could see why it would be valuable and I could see why it would help in some circumstances, I'm also not I, can't quite there may be ways to do this in in um in in some existing abstractions.

A

We have like, with a like a wrapper provider or something like that, although it might not be exactly the kind of thing you propose, maybe with hooks, although I'm I don't think so, because I don't think, we have hooks that. Allow you to mutate, The, Returned value, um but yeah Dynamic default. I guess is like a real. A great way to you know characterize this.

H

Yeah I don't know if I've ever spent. Have you ever seen that look at someone using Dynamic defaults that are like not just static values, I.

E

Mean well, we we so our sdks I mean yeah. We need to find them in code, yeah.

E

So you you, you could do you could achieve that with our sdks. If you wanted to yeah.

H

Yeah I don't know I've ever actually seen someone do that in practice, but yeah. It's interesting, yeah I.

E

Mean we yeah, we, we tell people to be defensive about this stuff, but um quite often they don't listen to us.

C

The point is I think again that you could still I, don't know Implement your use case, but it wouldn't be that nice right so maybe you would put in some default value that you don't care about upwards C and then build up your default value. But that's I get that that is not really nice.

E

Yeah I mean one of the one of the things that I'd be interested in or one of the things that would be valuable to like flags with talking about the the like. A schema definition for the Expressions is like being able to um factor out a bunch of code um into a you, know, Json file or something, and then you've got like all of your defaults, uh like language agnostic in one file, rather than just you know a massive code, basically that that would be really really nice. It's like I know.

E

A lot of our customers would be really into that.

A

It seems like an interesting discussion: I I, don't know I, don't exactly know where to go from here, um but and and I might have to think about more how we could implement this an open future because, again, I think my question is: how would you hypothetically map?

A

How would you accomplish this if the underlying provider you're using hypothetically is, is something that doesn't take this kind of dynamic default um and I guess one of the potential solutions could be to use the default default like we're saying, but that yeah I'm not sure that API still feels a little bit hairy to me. I don't know, but.

D

Why the provider needs to understand this callback mechanism, because I would expect that if the open features SDK fails to connect to the provider or the provider controls, we intercept the exception in the SDK and then we can resolve the Callback. So don't expect the provider to be able to support it.

A

That's true I mean we could but right now, the the differences in a lot of cases. At least the default is passed down to the provider, so the provider does have some kind of awareness of it. um So if you're not like in the case of you, know vendorex that takes a default in their API. What are you going to pass right now?

A

If, if in open, Future you're only past the default function right so there's probably a good answer to that I, don't know what what exactly is optimal, but that's one of the reasons why we have it in the openfeature SDK, as it is right now anyway, because it's quite obvious what you pass to the default for that SDK, since we already have a value default.

D

But you could pass through the resolution of this callback to the provider that accept the default value.

C

But then it wouldn't be lazy, anymore, right.

A

Very interesting, though, it's it's, it's definitely not. It's definitely an interesting idea. I could see the value like I said.

C

I don't know, maybe maybe what really makes sense to open up some discussion somewhere where we can follow up and sketch some ideas and later decided that um I don't know.

A

Yeah, you could also try doing a POC Giovanni. If it's something that's really interesting to you, um you could you could try playing around with it and go or something like that or whatever language you feel like and just seeing if you can get an API that seems sensible.

D

Yeah I can provide a POC to see how it feels like to use it also and open a discussion. Maybe.

A

Okay, any other points on that. Any other points that people would like to discuss in general.

C

A

I guess that's it for today, then thanks everyone very interesting discussion, um I'll I'll, take my action items to open up a uh a discussion on our large talk about uh defining some kind of consistent, potentially consistent, flag definition.

A

um Yeah thanks. Everyone for uh for attending.

F

Thank you, bye.

C

F