Lazy Sync, Proxy, & Middleware Patterns

[00:00:00]
>> Maximiliano Firtman: Lazy sync, the problem is that syncing data to the server takes time. It's not always possible, because maybe the connection is down, the server is down, things like that. So lazy sync, it has other names as well. The solution is make all the sync to the server asynchronously and detached from the UI.

[00:00:20]
For example, I think the first web app that I remember that was using this technique was Facebook, when Facebook was the coolest social network, okay? So, 2006, something around that. It was the like button, actually, when you were liking a post. It, at that time, was a surprise to see how fast the like was.

[00:00:46]
So you was pressing like and the icon was changing to blue immediately. So you went, this is really fast. But actually, it wasn't waiting for the server to accept the like, it was detaching the syncing that like to the server from the actual UI. The next one that was doing something similar was Gmail.

[00:01:11]
You were sending an email and it was gone, and you said, I'm done. But if you don't have connection, I'm sure it happened to you, after a few second, a message will appear, you know what, we couldn't send the message. So it was a reality. Okay, you thought that the message is gone, it's out, but actually, it was not.

[00:01:31]
And that's lazy sync, we detach the UI from syncing the data to the server. Use cases, save data, save analytics, downloading news, so then when you open the app, it seems already fresh and updated, and update the app's components in the background. It's also interesting. This has to do, for example, to uploading the assets, downloading new assets, new versions of the logo, the CSS, when you're doing PWA, progressive web app, things like that.

[00:02:06]
This is a use case. Another link to another Frontend Masters' course, is you can check the JavaScript in the background, Frontend Masters, of course, where I explained how to implement this API with service workers and the background sync API. There is a background sync API that will let you do the sync in the background, even if the user is not using your app.

[00:02:30]
So you can be in a web app doing some stuff. You can be saving that stuff locally, and maybe there is no connection at that time. So the user will get out of there, and it takes, I don't know, the underground somewhere else. At some point in the future, the device restores connection, and in the background, with the browser in the background, your code can take action, can wake up, can be woken up and say, yeah, there is something else I need to sync, let me try now.

[00:03:02]
And you can see that in the background, okay? So check the JavaScript in the background core for more ideas. The proxy pattern, actually, the proxy pattern is one of the classic patterns from the Gang of Four, but with time, it got more complicated, actually. But the idea of the problem is that we don't have always control on the access to an object, including to detect when some value changes.

[00:03:28]
So we have an object, an array, a configuration object, whatever, and how can we control who access the data and if it change the value, if the value is valid or not, because anyone can go and change the content? So the solution is to create a proxy to the option.

[00:03:49]
So fortunately for us web developers, we have the proxy design pattern implemented in modern ActionScript. Actually from, ES6, we have the proxy available. Use cases for this, reactive programming. What's reactive programming? It's more than a design pattern, it's more of a programming paradigm, where you write some code and you expect the code to change things in the future.

[00:04:28]
Let me get out of here for a sec. Let me try to explain this. So if I have a variable a, this is pseudocode, not real JavaScript, okay? Forget about Javascript. So I'm saying something like this, var a =5, then I'm saying b = a+2. And then you change a.

[00:04:49]
If I do console.log(b), what's the result? 7 or 12.
>> Student: 7.
>> Maximiliano Firtman: 7 or 12. 7, right? But actually, if it's JavaScript, it's 7, because JavaScript is not a reactive programming language. But there are some languages using reactive programming where the answer will be 12, because what I have just said here, it's not a static, but it's reactive programming, it's just a + 2.

[00:05:27]
When you access b, it's a + 2. If a is 10 now, it's 12. I know that for some of you, it doesn't make any sense, but it's just a different paradigm, okay? It's a completely different paradigm of programming languages that gives me 12 instead of 7. Well, you can implement some of these ideas of reactive programming using the proxy, okay?

[00:05:49]
Not exactly that syntax, but the idea, okay?
>> Maximiliano Firtman: Another use case is adding a security layer on top of objects to check who is accessing, how the data is changing. For example, if there is a cross-site scripting problem going on, now in the near future, that browsers will implement local AI models, LLM models that you can run locally.

[00:06:18]
You can use this to actually pass the data through LLM locally and see if the LLM is finding anything weird or anything to worry about that change that might involve a security risk or things like that. Also to logging all access to important objects. This is useful for debugging.

[00:06:38]
Every time you make a change, you log, who changed the data, what's the previous value, what's the current value, what time, what's the call stack, wherever? Okay, and you can end up with a proxy that happens automatically, even without the user's intervention. That's part of the deal of a proxy, that you talk to an object, or you think it's the object and you don't know that it's going through a proxy.

[00:07:04]
It's like someone in the middle ,okay? For more information on the topic of proxy, check the Vanilla JS You Might Not Need a Framework, a workshop where we cover also proxies with more details in ECMAScript, and also how to use it for reactive programming.
>> Student: With the promisified data pattern, we talked briefly about how there's just such a marginal performance overhead that it usually doesn't hurt to implement it everywhere.

[00:07:34]
Is there something analogous for the proxy pattern where like, yeah, it doesn't hurt, just use a proxy for everything cuz you might need it later, or is it-
>> Maximiliano Firtman: Well, you do have a performance penalty because you will have two objects now instead of one, and every call, every getter and setter goes through something.

[00:07:52]
Of course, if you're calling an LLM model for every change, yeah, it will take time. Is it separate power that's going on? Of course, so you do have. So, yeah, you don't wanna implement the design pattern on every variable, on every object that you have. So that's why we need to remember to implement design patterns if it's solving a problem and if the context matches with my current context.

[00:08:21]
So you will apply a proxy only on some special parts of your app that make sense. You don't wanna apply a proxy everywhere because it doesn't make too much sense
>> Student: That makes sense, thanks.
>> Maximiliano Firtman: Okay, and another one is called middleware. It's a standard design pattern that probably you have seen before.

[00:08:46]
Mostly if you are a Node.js developer and you're using Express.js, there are a lot of middlewares there, but that's not the only place where this design pattern was implemented. The problem to solve is handling tasks that affect multiple parts of the application, logging, security checks, error handling. Authentication is difficult, and it's also difficult to remember, hey, remember that every time you need to go to the network, you need to check if we do have connection.

[00:09:13]
You need to check if the token, the user authentication token, is not expired. You need to check that the user is not trying to send weird characters that can lead into SQL injection or wherever. You need to check, you need to log. So you need to remember that every time that you call an API, you need to remember all those tasks.

[00:09:34]
So remembering those things and reinforcing those things is complicated. So to solve the problem, to avoid forgetting about all those rules, the solution is to insert layer of processing between the initial request and the final response. So I wanna call an API. If you implement the middleware pattern, you just call the API processor, nothing else.

[00:10:00]
Someone has said middlewares in the middle. Middlewares are objects in the middle that each one is taking a request, doing stuff, and making a response with the same type of the initial request. So it's like the request is processed, that creates another request that is processed, creates another request that is processed.

[00:10:20]
Everyone in the middle is maybe changing the request, upgrading, decorating the request, and so on. That's kind of the idea of a middleware. Use cases, API access, database access are the pretty common scenario here, okay? So those are, again, just some design patterns for data management, not all of them, because there are hundreds of them.