GitLab Pair Programming - Frontend, 6 Jan 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: FE Pairing - 20230106 - Apollo persistent cache discussions

Description

In this session we discuss some approaches and tradeoffs to persisting the Apollo cache on the clientside.

MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106004

A

You don't have to repeat all of that.

B

Yeah we were I, think I I wasn't paying attention, you guys were talking about labeling people and I'm. Joking I'm. Sorry, uh yes! So thanks for hopping on the front end pairing uh we are gonna, be talking about uh Apollo cash, but persisting this um across uh multiple requests for a much improved, perceived and even real user experience, because I noticed sometimes, if I'm just clicking through things like. Oh there's, my issue go I, don't even have to wait for the real request.

B

um So that's um that's the idea and it's a real win, there's a slow query and so we're going to try to persist the previous response uh to remediate the real problem from the user. Obviously, and Natalia could probably deep dive into this is she's wrestled with the need to do this? Is we don't want to do this for every slope rate, because the problem of our query is slow still needs to be addressed, um but this is a nice to have.

A

uh No um and I'm jumping the gun, but I'm really interested to know what your, um what logic you were going to use for timings to like update that cache. If that makes sense,.

C

So the point is updating. The cache is very simple: uh we do it in two ways. Some of our queries, most of our queries, are what we call Smart queries, that's what you put in the Apollo in the components, or sometimes you use a Smart query, but most likely you see them in the Apollo option. Why they're, smart, smart queries are subscribed to the cache.

C

What you see as a result is the result from Apollo cache is if cache is updated in any possible way automatic with mutation manual with write query, you see the updated result immediately because they are reactive to the cache.

C

In the case of the smart query, we simply put a policy cache and Network with again with some hacks about what cache network does is. Essentially it should take the first response from the cache and the data is there because it persist the cache and it should send a network request. In the background, why I'm saying.

A

Shoots not sending.

C

It does send, but unfortunately, with Apollo 3, there is an interesting bug where it just skips. The first step it just sends the network request and ignores whatever is in the cache until we put a very specific option, called notify on network status change.

C

In this case, you can have the first result from the cache and handle the network. Okay. However, we also have simple queries and in the case of filtered search, we have SIMPLE querys. What is simple query, what is different from smartphone, so smartphone essentially is observable. You subscribe to the cache you via the Apollo implementation of observables called Zen observable, but it's observable observable. Camera can have multiple results. Whenever cache is updated, we have so-called next callback and you see the result. Simple query is a promise.

C

It's no different from axios call, so it shows whatever it returns from the API. It doesn't really care about the cash. Whatever is returned by the promise is displayed, and this is the case with labels too. You can update the cache manually, it doesn't care, it doesn't react to the cash update. It only reacts to the call of the message, so in this particular case we are doing even with dirtier thing. I would say we call in two methods.

C

One is fetch labels, which is hitting the cache and returning us whatever is in the cache and second one. What I call fetch latest labels? The naming is weird, but it sends the same request with policy Network. Only simple queries cannot do. Caching Network, they don't know about the cache, so we're sending this strictly to the API immediately after we show the first result from the latest. So whenever you open labels, you see the result immediately, but somewhere in the background, there is an Network request happening.

A

And so I always does the.

C

A

End call, but it will just yes if you've got a cached version, it will show you that until such a point that it gets.

C

Yes, until until the network is resolved, the next, for example, if you open just took the cash yourself, you don't wait for the network money post a drop down, it will still be updated. So next time you open the drop down, you will receive the next version that basically brought them, so it should be very updated cash. It should be up to date with the back end theoretically, and we have other tools to invalidate the cash ball actually asked about this in the Mr.

C

For now, we're not doing any caching validation manually, I'm, not purging the cache we just rely on it exists. We will do this in the future. Awesome.

A

So so, where are we at what questions have we got? What what's our next steps? What's, uh yeah yeah.

B

So I'm I'll share uh the Mr and I was going through replying to some things. uh So there's big crazy idea that I had to Natalia. We could talk about that first or.

C

We could see that, let's, let's start with with the most important part- and this is persistence- mapper, yes,.

B

So um right now we are targeting. What do we persist by looking at the query and we can decorate the query with here's, how we need to persist things, but what Apollo cash persists actually saves is our state, and so we have to somehow transform these Quarry decorations into persist, decorations on the state which are then living inside of uh living inside the cache, and so this creates the need for a thing called the persistent link, which is a.

A

B

Apollo cache, which is like a middleware for uh quarries, coming.

C

In for decorating and undecorating right.

B

Right so looking at this and once I saw once I saw a persistence map where I was like. Oh maybe we could just talk to this and I couldn't get that idea on my head. So I was like I gotta see if I could do it and it's okay, if we don't do it, I was just wanted to see if we could do it. So the idea is instead of the developer, adding persist decorators to the query.

B

We would give some sort of parameters that would get passed to the persistence mapper and that, rather than the mapper looking for these persist, Keys it would just match based on these patterns. So this is a patch I put together that implements instead of adding the at persists and the underscore persists throughout the queries. This is all that we would need is based on what's being stored.

B

These are the keys we need. We need label types issue, types saved and then from project and groups. I only need the issue and labels that have nodes and Page info. So we're not going to Cache the accounts and stuff like that.

B

um This clearly isn't like ideal, like it's weird happened to for one I'm using regex and lots of people don't even like using regex at all and like this is clearly weird. My main question is I. Think it's potentially a better developer experience just decorating this on the query: I want to Cache, but do we save maintainability from the implementation side this way, and are there any other kind of concerns like with the way our with this specific problem and the way our priorities are with this of hopefully we're not doing this too much either?

B

uh Does this approach? Is it more favorable than decorating the queries, and it's.

C

Amazing approach is, we are not selective enough. uh The thing is, we have multiple queries that have root as project and group. That goes for the science model bones, but all by specific for all the options in the drop down, even within the same application.

C

How do we tell in the cache patterns that we want exactly this query to be cached like only this little one with labels, or only this little one with issues, so we can use cache patterns, but they will be much more detailed that we have right now, so what we can do, potentially is maybe we could rely on the query name in this particular case, because probably I mean in our code base. Query name should be unique. This is insured by the Linker operation.

C

Name is unique, so if we could include somehow the operation name in the reject, if we can act, I'm, not sure we can access this on it in the path I think we can try, because the query is passed a whole right as it's just a document as a string.

C

So maybe, if we could do this, it would be fine, but also both patterns are not perfect in terms that, if I modify the query, if I add any more entities or if I add something else in the issue and also we're not including part of the issue here, unfortunately, that we should, for example, in this particular case, we also would need to work with assignees.

C

Sinus of the issue should be also included as a properties- a user like not only label an issue but user or user core I, don't remember what the signing belongs to, because we're fetching a list of issues with the sign is, and this would require us every single time when we add one more nested property to the cached, either decorated with persist, which is apart from perfect or modify the cash patterns. Which is far from perfect two, so I don't have a good I, really like the pattern. I just need to I.

C

Just think that we, it should be more refined that we can ensure that this query, and only this query is persisting, because currently this one will include also five other queries.

B

Yeah, so I, um yeah and I think I think that's this. You bring up a good point if this runs the risk of previously, you have to add the persist everywhere. Otherwise the caching's probably lost here we're probably being way because we're matching so liberously like we're gonna, potentially cash more than we need and finding that balance is going to be the the key um I did, but I did. But the idea is.

C

B

You're wrong enough, like it's just an idea: yeah I didn't get to share this with you. I did so when I was working on this I used. What was shared, um I used, what was saved on your branch and the cash as like I saved that out and I kept iterating to like figuring out okay. What can I do to get the cash looking the same, and so with these properties, the cash looked the same on load and when I searched and when I did the um open up the labels.

B

I don't know if there's any other way to trigger queries, but this was the one like weird quirky thing about it is uh this may be on it. This may not be intuitive that, so we only would include quarries we're not including the count chords, because those show up in the cache but they're not persistent, and we don't want to present those we're only persisting and so here, rather than selecting by query we're selecting by the state of like the issues that actually have nodes, I love.

B

The idea of it would be great if I could just say local cache, queries and I just type in the name or like that would be fantastic or even if all I had to do was just add persist.

B

C

Be really yes and it was possible in Apollo 2. We were discussing it on the one of the front and fairings. So a Polito was way more liberal. In this you could decorate their response. The way you want- and they can find one five properties here- fine, but the policy is like you, don't have this in the request ship everything, so it.

B

Was really bad I have an idea for you, then, regarding that.

B

Why did we move to three in the first place, I'm joking, every time we upgrade things break it's hard for me to understand why we upgrade I'm joking.

B

So here's an idea- um this is weird: these are crazy ideas, so we could get persistent link.

B

What if we had this keys to persist- and this is some sort of thing that will be mutated by the persistent link.

A

Could you just remind me um Paul why so what was the pro? So you said: Apollo 3, there's something with those persist: decorators that yeah? What what's the reason for looking at these kind of cash keys, or this alternate approach? Can you remind me or or help me to understand that a bit more.

B

Well, the reason I bring it up is I. I found persist, link uh is um doing a lot of parsing. Of the query like this is a this is a complex module, that's happening here and I wondered.

B

Do we need to, and once I saw a persistence, mapper I was like: maybe we could provide other keys, but there's a trade-off, and so Natalia is bringing up of like the the idea would just be.

A

See maybe we could do away with this in.

B

Time is there a way for us to do that, especially.

A

But it makes it a lot harder, wow yeah.

C

A

You sort of win some, but you lose some so to speak. Yeah.

C

That's that's the whole point and, unfortunately, for us uh the examples that Apollo cash perceived prints for link and mapper, not working with Apollo 3. Even so the library is called Apollo. 3 cash persist, they just kept them from Apollo 2 and the example of persistent is a bit simpler. Probably Paul would be happier with this one, it's not as big, but it's simpler only because in Apollo 2 persisting didn't need to do so many things it was only removing The Decorator one decorator at persist. The directive likes at Skipper at include and.

A

C

It was only one decorator you put on the aquarium being happy with that and Ebola 2 was fine with them, because then you take the directive and you recursively go through the leaves of the object just putting persist through in every single entity you find and returning it. It didn't need to be in the query, but suppose three, we don't have this nice thing.

C

We just need to do lots of manual work and it doesn't make me happy and as I told in what it was application performance session, that when we move to front and caching, we need to realize that either way we go, the price is high. The price and developer experience is high. Like really high, we will be either decorating queries or just remembering to put things in persistence, number or pass them as a parameters like either way we go, the price is still high.

C

There is no easy way for now to make the caching work and we need to understand it when implementing it in production. So if it's labeled Square most of the people that work with like okay, fine, whatever you, whatever magic, you are doing, please just make this faster yeah.

B

I mean so this this this like persists: yeah.

C

B

Lot of times- and it's um yeah- it's not that's, not ideal, so um I'm! Fine, if we're just like hey we're just gonna, do it this way for right now, I'm just ringing up the brainstorm for us to talk about it. If no.

C

It's amazing: you do because we can try to work with persistent mapper patterns and maybe.

B

I think I think you like this, um because we can't we're pretty much guaranteed a timing of the link being executed and then our persistence map are being executed. So if we had a shared reference to uh some object that just housed keys that we're going to persist, What If, instead of the persist link, writing these directly on the objects. Underscore persists, wrote to some object.

B

That's going to be read by the persistence mapper. So this then we'll we'll share this same shared object to persistent snapper keys to persist. This allows us to circumvent. We don't have to return data. That's not actually in our query that metadata lives inside this, like shared object that we that the link will write to the Keys we need to so anytime. It sees an app persist. Whatever the return was we'll just spread. That of like all of these Keys, we got to persist and that's then, what the persist mapper will read.

B

Every time he needs to persist is like hey. What are my keys? I need to read and or like, but.

C

But how do we return it from the link? The link is, basically it Returns the response of the query. How do we plan to move it to persistence? Mapper, that's that's the problem.

C

What link is doing is interceptor right, has the request and response and it works with request and response. uh That's why we're modifying the response, because that's what we have in hand, so how do we make it pass through link.

B

Yeah, so that would be this I mean this isn't great, because you're we're we have shared I'm receiving shared State, we're playing on mutating.

C

But yeah and nobody.

B

Likes it, it's not.

C

The functional programming, let's.

B

Let's just take you know, let's put all the functional idealism aside.

B

No, uh um so this receiving this intermediary object means I, don't need to return, underscore persist. Information I want to send to persistence, mapper I write to here.

B

So instead of the query having to figure out how to update and resolve persists, it's I would see, I would base I would somehow I would imagine it'd be. Something like uh you know is a persist, worry on the operation query and if it is uh uh right keys from response to keys to persist and then pass through. So this is just a pass through link, it just writes the keys. We need to persist by reading the response.

C

B

It's weird: no, it's definitely weird. This is still in brainstorming land, but it's is this potentially more desirable than requiring underscore persists everywhere and just and requiring these uh like having to update and manage what we're returning as well. It's like this is just the idea um just.

A

Asking another remedial question: um was this only a problem for simple queries? No.

C

That problems applies to okay, all queries. Unfortunately,.

A

No us easy answer. Thank you. I.

C

Mean we can, we could skip all the processed part all together if we were sure that for this sir application, we just want to Cache everything like whatever Apollo sends cash cash, cash and cash. If we cash everything, we can just drop persistent Snapper and persist, link all together, because there is no need right. We just cash in everything, so what caching client is doing is opt out, not not opt-in. For now, it is basically when it's enabled it caches everything.

C

If you wanted to be selective, you need to work with this persistence mapper. So we have this all weirdness going around, because we need to tell okay only cash this this and that Clarity and rest of them skip please so yeah.

B

Does this um I'm now thinking I'm I'm I am naive here, I'm realizing uh the result that data doesn't look like the data we get live in the cache. It looks like the date.

C

B

C

What we return from the API.

B

Yeah, that's frustrating! That's not gonna work, I.

C

Know right, it's like honestly, I know we are recording, but all this Mr was frustrating from start to finish even like before we started on it and the library is very frustrating too, because if, if you work with it, it's very much Half Baked, they just put the basic usage in place and if you want any advanced thing, oh go read these examples. We put here for react native like what okay, yeah and half of it.

C

It does doesn't work, because if you just follow the example, you will see the issue created, saying that it doesn't work for policy, but we need to figure it out.

A

So so again, another silly question, but is this something we should be working on in the Upstream projects rather than in the gitlab project?.

C

The point is that we adopt with that we can work on Upstream project directly, I, don't think that merging anything actively right now, right.

A

C

We can try, we can Fork, we can work with it, but before even starting contributing to it. This Mr serves as proof of concept as just.

A

A validation of the idea, that's why it's very.

C

Questionable I would say too that's why we're doing this praying storm.

A

Yeah yeah absolutely.

C

We need to see if it's safe, if it's secure, because that was a great question from Paul about security too. uh What about validating the cash and are we even sure it works as expected? And for this we need to just put it in place, enable the feature flag and see how it plays with everything yeah.

B

And and that's totally.

C

And unfortunately, that's.

B

C

B

If that's our like feel free to you know, Short Circuit, the discussion of like Hey we're. We want to.

C

Shut up and March, no, no.

B

Well, I mean for me, the discussion is relevant to these are these are concerns I would want to address before we start spreading this, and so it's like okay, we're testing something out all right. Let's comment we're still discussing this: here's where the discussion is happening. We want to test this in prod. That's why we're doing this like? We can totally go that route with.

C

This no I really value your comments on this and that's why I you're assigned, because, if I wanted it to be merged super fast, there are a few minutes cleaners you can just sign and get it merged without any discussion. We know this.

B

Sorry, I don't want to interrupt I'm sorry go ahead.

C

And that's that's why I brought you and team probably will bring Mark as well, because I wanted to station this month request before we even test it in prod, because it's also some certain risk that we have so yeah and if we can find a better way in terms of development experience.

C

That would be the best. Unfortunately, this link is what they recommend as a way on a polar cash process. That's first and foremost, the reason I went this route because that's a recommendation from the library like create a link, create another work with it, and also because it does nice matching with queries and entities.

B

Yeah yeah, I I think it's only it that's probably makes sense and I to me. The alternative would not have been obvious without seeing this implementation, and it's like that to me. This is just the natural thing. It happens when you have multiple eyes on and uh I am now I I think it's got to be possible for us to live with. Just one persist.

C

B

um On top of the ad persist on their own query on the root query on the I think the map is going to have to be a little elegant at being able to Traverse, what's ref and keeping a cast like tracking all of the things that are ref from the root query.

B

C

What do you want to do in the map, or so whenever we have query, we create a list of raft things right, referenced in the root query and then for every single nested. We perform the same kind of traversing down because refs on only on the roots right and a single nested track can also contain wraps. So, for example, if there is an issue around on the project, it also wraps labels and Milestones and assignees and everything so, instead of having a key underscore persist, you want to just basically have all direct scenes.

C

So how do we do this? Do we perform a Traverse first and save all the raft things or do we do this step by step.

B

I would um I think I'm I'm feeling a recursive algorithm coming I like recursion.

C

Yeah that that's why I'm like right, asking I.

B

Think um coming to uh it would start at root. Query it's where we'd want to start.

C

B

Okay, that's where we get clearly that's what we're going to persist or persist. All of those that have this thing, I guess or.

C

Says basically, what whatever we have at persist on the root we want to persist every single entity that is inside of it. Yes,.

B

The decoration, the direct you're right, you're right and this this decorate this and I- did notice that too this exists on the cache as well. So yes, so all of those we would just look for those that's great okay.

B

um um We would look for those I'm kind of feeling, like maybe we could look for this child, but that's irrelevant. We.

C

C

B

Then once we have that we have a function that says deeply persist or like deeply include whatever it is this ref, and so then we would read that ref and we would somehow need to. We would save that out, but then, from there we'd have to read all the other refs and those refs. We would say deeply include this ref and we would just.

C

One thing that we need to account on is that we will have the same graphs coming from multiple different queries and we need to, and but they will also go through persistence member and we need to make sure that we cache only those that go through this query. This particular one, not all the labels that come with the same wrap.

B

Yeah and when I think um yes and that's why we would do it this way going from the root query: first, okay, finding only these ones, and then we just deeply deeply find those ones. Man that that algorithm has got me excited. Do you want you want to try? Do you want to try doing that.

C

Right now, right.

B

Now, if, if you want to call.

C

B

I think we could let's try it, um because the persist link is actually going to behave as we expect so I think what I'm going to try to do. Oh, this is for groups, wait is it for group. Oh, we do groups.

C

There is for projects and groups, I've been testing it on the project. Oh.

B

C

Weird query that they have in place where you skip one of the half of the query and include the second one, depending on where your at the group or at the project issue list.

B

C

You can see.

B

Oh wait: wait, I'm thinking what am I missing, I missed! Oh no something's, I gotta get this running. Okay, sorry, um uh I'm! Realizing something might not be as ideal as I was hoping. It would be.

C

Yeah, it's always like this fashion.

B

No it's because they share the same ID you're right, because the project- oh no, oh you're, totally right, I'm here I am just naively saying. Oh Natalia, have you thought of this and I know you have foreign.

B

You're right, this will have a ref if I remember correctly and this. Why are you? Oh you don't like it because I wasn't writing real code. All right. uh Let me go ahead and just um undo.

C

A

B

B

um This will have a ref to the whole project, object that gets populated from all the queries right.

C

B

C

But that's why we decorated every single property, so, for example, our issue is, will bring us issues that have this little persist through, but at the same time the issue count will bring us issues without this little thing, and that was a different. A project is still this. The route is still the same. The reference is still the same.

C

Yes, apollocation is if, if it's huge pain well.

B

I mean all right all right, so then I'm gonna I'm gonna, probably say the the pain is probably a feature so that we don't do this too much I.

C

Mean we still can play around it and I really like the idea of simplifying the persistence mapper, and maybe we can evolve and just go in this direction. Seeing like what the mapper is. If we include the name of the query, maybe it would do a thing.

B

Yeah, um why is it so upset? Oh, the web hack, um I I think the I think the decision is going to come down to you um and we don't have to make the decision on the call. But uh uh I'll I'll leave a summary comment of our discussion uh on it, but we can either Target this selectively from the Quarry side or very broadly from this state side and I. Think I think that's kind of the.

B

The best we can do.

C

um Yep exactly and we will need team, because team is kind of product owner for this feature. He would need to decide because he knows what is the end goal here for me. It's basically narrowed down to implement the caching and we will see how it works so yeah and, however,.

B

You want to, however, you want to go about it, I'm I'm, just making a suggestion if you feel like, if you feel like our priorities, are going to live better if we could be more selective with it um yeah. If we don't see us doing this too much. The other idea I had was like What. If we have at.

B

um Here, where I'm creating a client, this is where I put like our local cash patterns. What, if I just passed in the persistence mapper here like and I'm, not trying to do anything fancy with it, I just I'm, actually selecting these are the ones.

C

It's fine I think we can simply just alexand ER, take the persistence number that you created and it's completely fine I.

B

Mean it's no there's! No! You know nice developer experience, but it's like it. It. The footprint is smaller than uh than elsewhere.

C

um We just need to make sure that persistence. Mapper is selective enough. Okay, that's my main worry here that we're not caching, things that are not supposed to be cached and we can test it thoroughly because this particular application contains so many queries with the same root like project or group.

C

We can see what this cash pot is. Not how percentage number is working so and yeah forget about nice developer experience it's Holly, Mars.

C

B

You see how I get nerds tonight I'm like I I, get the hesitancy with this in the first place and like okay, this is an un. This is a necessary evil, but I'm trying to make it as nice as possible, which I need I'm, not an efficient person and naturally, in that regard, I'm I'm. The kind of person that my my wife would make fun of.

B

uh Let me not end the sentence there, um because uh when we dated in college and when I was in school, I would have like you know, class in the bag, but it was the final and I could have like failed it and still, you know, gotten good grades, but I'm the kind of person to get try to get perfect on the final, which is perfect on everything. So it's I've I've grown a lot since then.

B

um Let me find uh yeah we're pretty close projects.

C

With issues yes,.

B

Yes, yes, the flighty project with issues; okay,.

B

uh Here we go yep.

B

um Root query project has a ref just to the project.

C

ah So frustrating I know I, know.

B

C

See if there is persistral- and this is what is different, yeah.

B

Yeah um I tell you, though: Apollo is pretty fancy. It's fancy.

C

Tell me about it. I know: it's fancy. That's.

A

C

I still have a job ball.

C

B

Morning, um yeah yeah, no I that it makes sense why we're being selective um cool, yeah now I I, think I'll I'll leave a comment. Summarizing there's just a trade-off here we could be very permissive, and maybe this works on some pages, um but then we wouldn't need these things or we can be selective, I'll leave it up to you and if you want to leave it up to Tim, that's whatever you want to do there, but thanks for talking this out that really helps that helps.

C

Me, okay, thank you. Thank you for the nice review. It's like at some point. I was like oh, was I wrong about persist. Think like yeah I wasn't because I remembered that we also have this anticipation. We need to separate the entities with persist through from ideas without versus true.

B

Yeah, that's man, that's tough uh I feel like there's got to be some sort of like key based approach, but I'm I'm, starting to I'm, starting to let that feeling die.

C

No they're I'm sure that that is easier and nicer watch. The point is, it will come with iteration. There will be someone you or someone else that will come up with better solution to that and I'm quite sure about this, like I'm, just not doing it myself anymore, because I was frustrated for two months to write in this.

B

Yeah 100, um yeah, okay, so I'll I'll write a a summary comment on there. The other big question I had I, don't know if you already tested this and then and then and then I think we can um just take the rest of rest of it. Offline was. uh um This was complete news to me. I had no idea when you signed out I.

C

Had no idea too.

B

That's got to be new because that's not always been there.

C

Can you please log out on the page where you're at the GDK and let's see if the cash is because I have my belts.

B

I did too, but it does it doesn't delete it. This actually breaks a whole lot of other features.

C

Yes, it does because.

B

We do like, if I have a draft of something and then I've that all gets saved in local storage and then, if I, just log out like it's gone now. So it's for some security reasons.

A

I thought I went on the server because, if I do a draft at my mobile, that's what you say it on the basic as.

B

A

Are you serious I.

C

A

C

Might be wrong, sir okay I'll log in log back, and we will see if it populates a local storage on the login. Okay you're on the E is.

B

Now yeah so yeah here's, my my local storage, has got.

C

I mean it's, it's emoji and it's it.

B

Yeah those and then, if I go here, it'll do the um Apollo cash one yeah of.

C

Course, but it's on the refresh, but what, if you? Okay, if you created a dropped somewhere, it goes to the server right. I think please write we'll drop something.

A

And that now you're making me a question myself, I.

B

Didn't think so? Where is new issue? Why can't I.

A

Do it's so just go into one of those existing issues or merge requests or whatever you've got open there.

B

Well, that's why.

C

Here your issue was there yeah, it was there. I was creating issues from issues. I still can't create issues from issue lists. Maybe.

A

C

To leave this master, maybe I'm.

A

Not I used to go into one of these existing ones. For one of these, oh.

B

I can start editing. It.

A

Yeah yeah just start adding a comment.

C

Yeah just create a comment and we'll see about that.

B

A

B

Creating issues is a Enterprise feature, I'm joking.

C

Yeah yeah, of course,.

B

All right, let me edit an issue play like a great one but I'll. Let's.

C

Go to the issue or incident or whatever just create a dropped command, and we will see even.

A

Stories, yeah I think you're right that that idiot I think that probably isn't cervical I think that is here. It is but I think if you do a draft comment like a reply or yeah.

C

I see it in order safe, it's an autosave, it's an incident right test and whatever your refresh, your patient will be here and we know it. Yes,.

B

But if I log out and come back it'll be gone.

C

Cool what if you're logged out forcefully by the instance? It will be the same right, because sometimes we are logged out from the instance. No.

B

That's what's interesting: I was trying to figure this out. It is because I've that's why I've never experienced this.com and.com. My local storage is, is you know.

C

B

On sign out only if I click that it gets rid of it and I was surprised to see that even locally and I couldn't figure out where that's happening, because I didn't think clearly the server can forget cookies, but I couldn't figure out. Where are we telling the clients to delete all of its stuff uh on.

C

The on the bottom, quick.

B

Well, I I tried finding that I couldn't actually I couldn't actually get to it.

C

Interesting yeah.

B

Anyways, that's a that's a mystery to me that I'm like oh, this clearly is doing something right. This news to me, but yeah you see the drafts here, aren't when I say drafts, I meant unsubmitted comments, not our official.

C

B

C

B

um The other big question I had here was um I I. Where did I put it.

C

It's on the bottom of the Mr.

B

I labeled the performance but I, really kind of I. Think I actually mean like reliability, because since we only have a certain amount of size, what does happen if we hit the max? Is it just? This stops working? It's.

C

It starts overriding from what I get, because currently it's okay, just yes, it will start just I, think deleting old entities and creating, but we need to experiment because I never reached one megabyte on my gtk. If.

B

You haven't tried out I'm gonna, I'll, try it out and I'll just say: uh I'll just write it to do for me of uh paint slaughtered.

B

Take it to them all right, um yeah, because I I was just curious, because the I can imagine a worst case scenario of after using this for a week and then all of a sudden worst case scenarios. This tells this breaks Apollo somehow like we don't actually get the real.

C

B

Shouldn't happen, it.

C

Won't that shouldn't happen, because Apollo is smart enough to cash, a network policy that if something is broken, it will just fetch. You probably have noticed a few issues- maybe you didn't, but uh with a bullet. There is huge point that if something is just very slightly off with the cache, it will immediately refetch. It happens, a lot with work items. We have I have a lot of things about this. So, for example, people fetching work, items and fashion work items notes that has slightly different response.

C

Cache is updated and apple is like it doesn't match what I have to do in the cache and just prefatches. Everything like five more queries a fiery, so we are safe in these terms. If something is so, if there is a query asking for, let's say an asset entities with three three levels, and we only put two I'll, probably like not there or a fetch, it will just hit the server every single time. Something is missing.

C

It still needs to be investigated because way to understand what's going on, and we also need to dive into moments where I approach the cache manually, maybe with some time out, because, what's the point of for now, it stays forever. It doesn't have any expiration date and I believe. If we put it, therefore, here even the labels will be different. We need to somehow Purge the cash up to some kind of a timeout, maybe like a month yeah, but only if it's not. Maybe there is a timestamp.

C

There should be kind of a timestamp when the cash is updated and if there is a week There's the last update which is Purge it. You.

B

C

B

It's interesting to note that if the query ever changes.

C

If the query changes yeah, it will change the cache too. There is also the whole part of the documentation about breaking schema changes and how it does attempt the cache on the Apollo cache persist.

B

Interesting wow, wow yeah, all right. It's fun.

C

Yeah, if it's a nice way to put it.

A

C

A

Be the most exciting thing, but once it's working it's going to be an absolute Game, Changer right.

C

A

And just just just think of the ego at the end right.

C

You just sound just like my senior em, because every single time I complained to him about like I hate. This feature, I don't want to work on it, even if, but think about, project tip managers that just opened these issues 100 times a day and how much time you will save them.

A

Yeah and I guess you've maybe got some. um What would you call it like key problem areas or something that you've got in mind already, but, as you start sort of rolling it further and further it's yeah, it's gonna gonna be huge.

B

So there's the the rolling further further is the thing that I think concerns both Natalia and I would be the stickiness of where it is and.

A

Yeah, you don't that that's you don't want to just switch it on for everything, because.

B

A

Elaborate quite specific, like verbose about where you do and don't.

B

Yeah, that's that'll, be that'll.

C

Be yeah I just want to put as many flags on it right. It's like. Don't, please, don't use this everywhere. This is the part of the code, the design specifically to solve this problem and please evaluate like 10 different. There is a question or like go through it and if the answer is no, at least for one of ten questions, don't use.

A

This yeah yeah like what you're saying before, like realistically, we should be figuring out. Why is the query so slow um or in this instance? We know why it is because it has to Traverse through some crazy hierarchy of groups, projects even.

C

In this case, uh I had a proposal and a known backend is looking into it, and this is basically a short circuit. Labels are returned by graphql in pages right. We have 100 entities and that's it if you want to overwrite this page size, it's very specifically designed on the back, but by default, 100 labels.

A

Is what you get.

C

Why can't we, while we're doing this huge operation of going through all the labels through the project? Why can't we just do a short circuit whenever we have 100 labels, we just stop the search and send 100 labels back to the user. It's still 100 labels. We cannot show more in this particular case. It will be maybe slightly but faster instances like github.com accumulating 100 queries will be definitely not 30 seconds.

A

B

Yeah as I every once in a while I'm on a really bad internet and I've, noticed things like labels and assignee lists and if I'm typing something hit. That.

C

B

Yeah things take forever at the same time, uh at the web ID we have one endpoint where we get all file entries of the main gitlab project, which is like 26, it's a list of like 26 000 strings or something like that, uh and it happens like three to four seconds which you would imagine we'd be able to get labels.

B

um So yeah there's something something is uh it'd, be nice to address the root problem for sure um yeah. Those this is uh thanks for thanks for talking about it. I think this is really good, um helping understand deeper into the workings of hollow cash and also brainstorming the specific problem.

B

um Let's get discussion appreciate it.

C

Yeah, thank you for bringing it up too. I definitely learned so many things. I didn't know about Apollo cash and working on that.

B

C

Elegant, it's still weird Elegance. It was more elegant for Apollo too, it's not as elegant for policy, but I. Just believe that we have so many brilliant developers to improve it and just like kick starting it, and then we have people just making it better with every iteration yeah.

B

But it's good yeah all right! Well, I'll catch! You all later have.

A

A nice weekend this.

B

Will be back on your plate, Monday for sure all right awesome. Thank you. Bye, bye,.