Open Feature Project, 20 Jul 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: OpenFeature - Project Meeting, July 20, 2023

Description

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

OpenFeature website: https://openfeature.dev/

A

B

C

Just let everyone join a second.

B

I'm raheed, by the way, I hope you never met.

C

Oh, it's nice to meet you hi, I'm Mike, uh we'll do like introductions to like the broad audience. I! Guess let me kick it off! So if, if you don't mind that I'll I'll kind of I guess call on you and we'll get started.

B

Yeah I'm mobile engineering Spotify so.

C

ah Perfect, oh welcome nice to meet you nice.

B

D

C

All right hello morning for those are in the US at least.

C

All right looks like we got a pretty good turnout. um Does anyone maybe want to take a crack at being a scribe for a kickoff and see that we don't have anyone that's set up for that? Yet.

B

Actually, based in Berlin but like to know where other people are based, mostly.

C

I think we have a pretty broad distribution of people, I'm I'm in the Detroit area, but if others want to chime in yeah, New York.

C

C

C

Almost Canada so yeah pretty uh pretty good distribution.

C

And we got Poland nice cool uh I'll, try to act describe um if I get distracted. That is why and I'm posting the the meeting notes Here in the list. So if you don't mind adding yourself as a participant, if you have any agenda items or questions feel free to add it um and it looks like we can go ahead and get started so I.

E

Can, if you would prefer me to describe I'm happy to be if you've got stuff, you need. We.

C

Can we can try to do it jointly if you want I, just have one topic on here, but I can do my best so yeah. If you don't mind that would be I'll.

E

Step in for you, how about that? Thank you.

C

C

Cool um yeah, so we could do new attendees uh if you're interested in in unmuting yourself and saying hi. uh Please please do that.

A

C

Slight introduction, I guess too I should elaborate.

F

Do as much as you're comfortable.

A

This is my second time joining an open, Future, Meetup uh I am working at Spotify and we, as some of you might know, have been working on the kotlin and on Swift SDK, so I'm part of that.

C

Perfect welcome.

C

B

I, don't know if, like everyone was here and I said, introduce myself but I'm I'm, also mobile engineering, Spotify working on just the case. It's.

C

My choice, nice to.

G

Meet you great I guess I can close the spot if I look down uh for.

A

G

Here I was in the same Meetup last time as well, also working on Spotify.

C

Awesome nice to meet you all right, I think we can probably get started um just as a reminder. If you have any other topics, questions whatever feel free to either add them to the list here or just ask during the meeting. But um first up it looks like uh Todd wants to give an update on the class side.

F

Yeah and um any of the uh folks from Spotify can feel free to hop in um I, wasn't sure if any of you guys would be here, but uh I'm gonna start with stuff on that.

F

um So yeah from my end, uh I have I've basically gone completely through the kotlin SDK and it looks really good I'd say like it's in a state where it might honestly be in a state now where uh it could be added to the open feature um they open with your organization.

A

F

Housed by the open feature yeah it just maintained as a repository within the org um I, don't I don't I'm a little bit on the fence as to whether or not it's in a place where we can do an initial release and I. Think my without going into too much detail. um I'll actually add the I'll. Add the review.

F

uh Well, I'll, wait till I'm done talking, but I'll add the review in in the in the notes in the midi notes, um but without going into too much detail, I think my only uh real concern at this point is there's a little bit of a behavior mismatch and set provider um the function that sets a provider on the on the SDK globally and really uh it comes down to um whether or not we kind of want to block and initialize that provider before that function, returns or not, or find some way of find some way of navigating that most of the current SDK implementations.

F

What they do is they just set the provider immediately. There's no initialization that takes place on that provider uh while that um what I call blocks uh and the way that you're kind of uh supposed to know that the provider is ready to be used is to listen for the on ready event.

F

um So that's like the basics of it, uh especially if the provider needs to do some Network requests or or I o of some kind. uh The initialization is when we would expect that to happen. So there's usually some kind of asynchronous activity associated with setting that setting that provider and in a sense, but they all return immediately in the current implementations.

F

um So we were kind of looking at how this is a suspend function in kotlin and suspend functions. uh I'm, not a kotlin expert, but my understanding is really they can be kind of treated as blocking or not. um It really depends on how they're called, but that's my only real concern is uh if, once events are implemented, um it means that we would then have a bit of a discomfort um or a lack of ergonomics on the API because of that I I. Don't really feel too strongly about the solution.

F

That's chosen as long as it's kind of consistent with the other sdks in a sense, um and it feels comfortable to kotlin users and it's not going to break as soon as we Implement a new feature or be unreasonable as soon as we Implement a new feature, so that that's kind of my entire take on the issue right now, um but I'm, not a kotlin expert.

F

So it makes it really hard for me to evaluate even potential Solutions, uh so so in a sense I'm going to defer to other people, even the Spotify folks, on what makes the most sense um and I put a comment in the issue saying as much um I don't know. If anybody has any thoughts on that, but that's kind of my my last concern I guess with the sdks. It stands right now. The rest I think we can Implement as we go um just fine.

B

Yeah I can comment on that. um Basically, we have already a proposal, so we looked into the events uh kind of like proposal by open feature and um except the part that we were setting callbacks and handlers that now we are handling it with uh equipment, concurrency framework, which is core teams, um so I think we have a proposal to go forward with that that basically make the set provider not suspending and running it.

B

um Asynchronously, like the network request and listening for the provider ready, we also created some uh additional helpers and extensions uh to help customers like, for example, when anyone wants to like listen for this provide already.

B

So we can observe the event of the provider ready and um like even make the flag valuations like observable, and so just like, listen and then you can also listen for other events like we added the events that was proposed by open feature specification um like uh provider, error, provider, state and uh yeah um I think we have a solution for that like, but we can check it uh later or go through it.

F

B

That sounds good to me. Sorry go ahead, the the right place to go like a bit technical, because otherwise we can also like present like what we did, but um that anytime works better. We can go through it.

F

um Yeah I would be glad to have a meeting and maybe we could set something up um dedicated um and then the people who are interested in that specific technical Point could come.

F

um But everything you just said makes perfect sense to me, uh like I I, don't necessarily see like event handlers per se as as Lambda functions that are passed around as as necessary, especially if that, if there's kind of a more kotlin-esque um solution that that kind of works the same way effectively in code like I I, don't really I, don't really mind, but yeah. Basically, all the points you just made.

F

They sound, they sound like a perfect solution, um and if we get to that point, then I would feel I would feel pretty comfortable saying this could be like a stable, sub 1.0 release. If we, if we wanted, um it would still be great to have to have more um call-in expertise uh from within the org I think, maybe Oleg uh you said you might be able to take a look um and and I'm I'm kind of part way through a similar review of the Swift SDK.

F

So I don't know how much of this would be applicable. There, um if any but um yeah I'm I'm kind of just started, I I haven't uh finished, but I want to commit to get that done by the end of the week.

C

uh Related to the at least the kotlin one, um releasing the artifact uh have we looked at that at all? Is that something we have not done in the org.

F

So I I did a little bit of scoping out and um again please uh people who are more comfortable with Android development.

A

F

Correct me if I'm wrong, but it looks like it's it's quite possible and and quite common to host uh um Android artifacts on Maven Central, uh for which we already have credentials and we can publish too. So if that's satisfactory to everybody once it's in the org, we could just use existing credentials and accounts and namespaces we've already validated and we could push up like a Dev dot. You know Android SDK or something like that, whatever dev.openfeature.android or whatever.

F

We want to call it depending on on what we think is the right name, um but but I don't see that as an issue as long as we're, okay with Maven Central.

C

Or something better I guess that is the question then is is something else preferred because we can start investigating that soon.

B

um We we all, we added uh I, mean I'm, not sure, if you've seen it but uh Community using the jet pack um um like jetpack I, all for open features SDK, and uh we also um like integrated in the CI uh like creating the release like when you create a tag. uh There is a new release with release, notes and AR file um to be released there before and yeah.

F

Yeah, so I don't really mind where it's released. I think I think one thing that we'd have to do is we would want to adapt it to be consistent with the rest of open features, release processes which include um kind of a democratized release process via release. Please so releases are open as pull requests at the end of the day. They're they're still tagged, um so we might be able to adapt the CI that that you have, but we basically, we have released processes open with.

F

We have releases open with Automation and then like there's the opportunity for Community buy-in or blocking or whatever, and then once that PR is approved, There's an actual um publish that happens, um but it sounds like we could adapt whatever you have for that am I correct, though that are you saying you're already publishing this artifact publicly or no so.

B

With jpeg I think, a good thing about jetpack is like with any open source uh like a library on GitHub. You can just like get. The version so like there's is no need to kind of like like upload in some package manager or something it's just like work with Maven.

F

um Basically filed from source is every time is that is.

B

Right and then there is versioning and branches and and coming hashes and stuff, and there is all like.

H

Legit pack is a really nice Focus wrapping things and getting initial evaluation, but there are certain limitations. When we talk about large-scale adoption. Just legit Park is prohibited at many companies, because it's not a trusted source of Maven packages and it's also not a default one. So for many users having the packages deployed to move in central Despite, All The Madness of getting it deployed from automation, infrastructure is what you actually have to do. Well,.

F

I just have to we've already done that hard work anyway. So it's so it's fine! We we do the progression through the uh our Hoss repos and everything or osrh repos and everything so yeah yeah.

C

F

Mean yeah! If, if it's a better idea to actually package, it I think that that's fine I'm, not too worried about the CI process. Personally, as long as everybody's okay, with where the artifact fact ends up.

H

Yeah, so we can automate releases. Maybe on Central is quite good even for continuous delivery of RC Fox. If you decide to do so um and regarding tooling Etc actually for GitHub actions, it's something that is possible at the organizational scale why I can say it because I spent just last week figuring it out from my mock, because we have exactly the same problem of publishing right now from GitHub actions.

H

So maybe, if you have something as addon to generalizer, we could reuse it in open future tour but yeah, so something we can also discuss as a part of all this flow, but habit of help.

B

Yeah I'm not also very opinionated about main Central jetpack, but just like the easiest option, you could do.

H

Yeah, just pack is really cool. It just doesn't really work well for Enterprises and yeah. If you talk about higher grade features like as bombs, Etc. Well, nothing is integrated and budget back at the moment and as we discovered today, some ideas also fail to pull javadoc from jetpack.

H

So we just had a conversation with a few that had guys today, because we use the jetpack for new models so that we create- and we apparently in some way these it doesn't work, as you may have expected so yeah for the initial adoption I think is perfect.

D

Just to add, we use jetpack jetpack right, kotlin and right. It's interesting what you say on it we haven't had anyone like complain that it's they can't use it um yeah. It's.

C

A

D

Getting stuff into moving like Central is just very, very painful, but.

F

From a security perspective, if I'm putting on my security, app for a second assigned binary is always going to be more, is, is always going to be more of an easy sell to security teams than compiling from source that that's at the end of the day, mutable well I mean I'm, not.

H

Constructed you don't compile from source, so what happens? A jetpack is basically a proxy server. It is Maven, but when it gets a request, it basically builds the stuff for you and then it provides artifact. It includes the gpg uh I believe it includes too so from the standpoint of end user and security team. If they do not deep dive, it's okay, the problem is that there are companies that blockages back explicitly. I cannot name these companies some reasons, but they are these companies, okay, plus uh yeah. Also all the questions.

H

So, if you use jfrok as a proxy I think it's also going to be a bit of a problem.

F

um I I think that that's really, unless there's any questions or follow-ups I, think that's really all I wanted to say on that topic. uh Yeah I'm, gonna be working on a Swift, swift review um and I'll. Do the same thing: um kind of open up a big document: I'll drop I'll drop both those documents in the slack Channel and I'll put the kotlin one uh in these notes.

F

um uh I guess one thing: one thing from my perspective that uh well maybe we should take that offline I'll connect with um with uh with with you Fabrizio later um I guess. The only other thing that I want to mention uh was the static and dynamic uh context. Aka the client spec PR is is scheduled to be merged.

F

Tomorrow we have a ton of approvals now um and a diverse set of approvals, so I'm going to merge that if you have any objections- or you want to review it before tomorrow, please do and then say something if you, if you want to change I, think that's it for me.

C

Yeah cool yeah, that's a pretty exciting one that one's been a long time coming so uh nicely done and just to let everyone know like we decided from like a technical standpoint. We would keep static and dynamic context is like our terminology in the spec, um but in the glossary we we added a section for client, side and server side that basically like roughly matches uh or maps to the more like technical definitions that we settled on.

C

So we can refer to it as like client-side and server-side sdks, and that's how we'll we'll probably uh visualize it in some of the docs and some of the the filtering and things like that. um But from like a technical perspective, we wanted to have the more like technically correct uh terminology, so um which kind of segues into the topic that I have uh and just as a reminder, I'll link again. But if you have any topics, please feel free to add.

C

Excuse me, um but I, just kind of wanted to uh quickly cover kind of the impact of this uh client-side spec change and just all the different, like considerations that we'll have to make across the org.

C

Most of them are quite minor, but things that I try to identify a list and if, if anyone has any feedback or you know gaps, uh you know, certainly let me know, um but basically we're going to have to very clearly denote on each SDK. Like is this uh intended for server side or client, side um and I?

C

Think coming up with just a simple little badge is probably the most straightforward option there and then we'll update the the template that we're using for uh for basically all sdks and then just obviously go through and then add that to all existing sdks um the Java contribs right now, uh since that one I think that's the only one that will this will affect immediately, but anything that we have like a contribs repo. That could, you know theoretically, span both client and server.

C

We'll also have to make sure that we clearly label like a provider or a hook or whatever, to kind of highlight the intent, and as part of that, we have like a a monorepo like generator for, like creating providers and stuff we'll need to update that to uh to basically support either side or both. Some, like hooks, for example, could run potentially on either a client or server um the uh then the documentation, so that's kind of a big one. The first one would be like that ecosystem page um expanding it.

C

So we actually have that terminology on there and then we have like facet filters. So you could see you know, providers for the client things like that um and then we'll have to expand like the doc section.

C

So I'll have to make sure that we include more information on the client side and basically what what that you know what the impact is um and then existing SDK overview pages will have to have that little badge, basically to specify if it's intended for client or server side, um the playground is more or less been updated, but once it's like officially released we'll have to make sure that we bump that latest web SDK version.

G

C

Then include that in the playground and then I just wanted to quickly identify like a couple areas that I think we can go to next and it's it's basically like once we have a a solid like vanilla. You know um client-side SDK, um having more proper support for things like react and possibly angular depending on you know, kind of user demand. React is probably the most obvious one um at the moment, but then expanding it to other. You know uh popular Frameworks and that's basically it for the impact I probably have missed a couple.

C

I will continue to kind of like update this page and I'll create some issues in the org um to track this, and some of these are already underway, but I'm just trying to identify some basically touch points that will have to be considered. As uh as we merge in this spec change,.

D

Mark, sorry, just out of Interest are there? Are there any client and server-side single Repository implementations out there.

C

So JavaScript will be affected by this, primarily um because for rck it is. uh We have a it's a monorepo, so we have like a bunch of shared pieces, but we also have a client side and a server side. So I'll have to be there and then it contribs you could have a provider, that's intended, for you know node, basically or one that's for the the browser and then same thing with hooks and there's there's minor, like differences between the hook behavior.

C

um So we'll have to just make sure that it's like clearly noted um in in the.

F

And runtime dependencies, like you, basically the little the the modules have to have their like their surrounding run. Time set up differently because obviously the API is very different between node and the browser. So it's like it's configuration like that. Mike's referencing, I think.

E

It doesn't sound like it's really possible to have like a like. A universal lot thing like will work, both both client and and server, or maybe it's not it.

C

Could, in some cases like the memory, one could likely work uh essentially across uh boundaries, and things like really basic Hooks could potentially Do It um like a logging hook or something theoretically could work across both, but.

E

But even then it would have to it would be essentially like the package would have to provide to kind of parallel implementations. I would assume, because the apis like slightly different.

C

E

C

Say it kind of.

E

C

Kind of probably getting slightly into the weeds I go into it or I can show you the the pull request or something when we finally get to it, but for like a hook, both would have like an after hook, for example. So you can, you could basically just have like a logging hook that would work.

F

H

F

Or something got it.

C

E

Yeah, um whatever it makes sense to have like a like a universal badge, as well as like a client badge for.

C

Sure I think we we should include that. um But it's it's probably a bit rare honestly.

E

I mean maybe that means it's not worth doing and we just have like you know you do get two batches if you think there's a.

C

Universe that could be two yeah um so which actually may be slightly preferred, because then it's like we've already vetted it for both client and server use cases or something.

E

It's probably really getting in the weeds, but it might not be a bad idea from for just from an ergonomics perspective to have those JavaScript sdks like fail really hard. If you try and use them in the wrong context like because I think that might be something that people do when they first get started, is they accidentally download the node SDK and try and use it yeah.

C

I could see that and you could have some kind of devastating effects.

E

Potentially or even worse, like just subtly, wrong right like devastating, is okay, because you notice the devastation but like if it's just like it's vastly wrong, and you only find out three weeks later than that's even.

C

More yeah I guess that I would be allowed worse. Yeah. You.

E

C

Up- and it looks all good until you actually roll it out.

D

To production, the Java ones, the Java one's really good. For that, um because a lot of java libraries work across Android and server-side and.

E

D

You can get into all manner of fun, locking things and you know, yeah.

C

I think that's a good thing to consider. Then maybe it's like somehow in the SDK we could say the intended use or something and when you register a hook we could we could see if it matches or something so I think we can definitely look into it. um That's that's a good point.

C

Okay, um yeah anything else. I uh I think we're basically through our list.

E

Thanks Mike for doing all of the tedious like project management, stuff with the dogs and the updating things and batches and whatnot.

C

Yeah you're welcome um yeah I, guess that would be an interesting transition, though, because like there, it would be helpful to have just start thinking about like developer docs um so like what it would take to create a provider for example, and hooks.

C

We have a little bit of that, but they're kind of nested in, like uh blog posts and things so I'd like to at least have an issue created where we could talk about, like you, know, kind of best practices and expectations for provider developers essentially, um and so, if there's any interest in that, um let me collaborate through the GitHub issue, but I think there would be a lot of value and kind of consolidating that knowledge in the doc somewhere.

F

F

I'll do uh I'll do one other Hail Mary request, just uh if, if anybody, if anybody has kotlin knowledge or Swift knowledge and and wants to to kind of, join in, especially if you're also familiar with the open feature, SDK um or you know, anybody who is- um and you want to help- take a look at uh vetting.

F

Some of the Spotify contributions, um yeah I I, like I, said I'm I'm, getting to the point where I think it might be good to include them in New York, but I would love to have uh additional eyes, especially with more Colin and Swift experience on the sdks.

D

C

Perfect all right, sorry.

E

Go ahead well, I was just thinking if uh faheed had suggested was it was asking whether now this is an appropriate Forum to kind of go into a more techy Deep dive on some of the I think some of the kotlin stuff. If we yeah and told you were saying we could set up a meeting, you could also just use the half hour now. That's.

C

What I was going to suggest? We could maybe wrap up here if there's no other uh topics, and we could basically let people drop if they're not interested in the technical nitty-gritty, but otherwise it may be a good time to Pivot.

F

Yeah and I don't want to put any of the Spotify folks on the spot like if you guys don't want to share your screen or you you'd like to actually have more of like a you know, scheduled meeting. That's totally understandable too, but if, if there's something you want to actually go over now or ask a question or or demonstrate something explain something.

F

The floor is yours. If you want to.

C

F

Yeah before we do that, I.

A

C

I guess you can answer your question, but I guess before we actually dive into it. Let's we can let people uh drop if they yeah, unless they have anything else.

C

Great thanks, Bill.

C

All right thanks, everyone.