Transcript from the "Background Sync Q&A" Lesson
>> I was curious, the word sync is the event, the event that we're catching is sync, right? That I think maybe what I was wondering about when you alluded to this was, that seems to be an event that gets fired when a sync is successfully completed, not when one is attempted and then-
>> Is that right?
>> Yeah, you're complaining about the event name.
>> Yeah, well, yes, it's not quite as specific as some of the others.
>> Yeah, it's not. In this case, well, also push, what does it say? It's like push received, it's like push. And even I think it's using push as a noun, not even as a verb.
[00:00:48] So that's an event, it's kind of, what is that? Well, we need to add some context to the event name in the case of sync means, hey, I have an unprocessed sync operation, try now, try to sync now.
>> That's kind of the event. The event is for us to try to sync the data and fulfill that sync operation.
>> I see, so this data doesn't get pushed to the client or to the service worker with the sync event. The sync event is saying, server would like to sync and then it's on us to reach out-
>> Exactly, yeah, in fact, if you look here, I never said what the sync operation means, it's just a name, a label, the tag, it's a tag name, that's all.
[00:01:42] I didn't set if it's a request to the server or maybe it's a sync to a database.
>> Typically we do this with HTTP requests or we do that for HTTP requests but it can do anything. So maybe I wanna think something in my index DV database. I wanna parse something from index DV, I wanna take something from a database and create another database.
[00:02:10] Instead of doing that in the main context or in a worker attached to the main worker, I can ask the service worker to do that. Remember, have in mind this API is chromium only, for now. We don't know if Safari, or WebKit is going to implement that any time.
>> But conceptually, you could implement sort of the same thing with a push, or a website.
>> The problem with the push is that the push will notify the user.
>> And this will not?
>> This will not and requires permission. This will not. So the only alternative to these is to just send the message to a service worker.
[00:02:56] In a standard, like through a broadcast channel, you send a message to a service worker to actually do the sync. The only thing that so far is not going to do that in that case is retry in two hours if the connection is not working now.
>> Right, so it's on your application to manage a connectivity issue instead of allowing the browser-
>> It's up to you.
>> Queue them up.
>> For example, some service worker frameworks such as workbooks, they have a fallback. So they have its own internal algorithm to fall back to other mechanisms in case the sync API is not available.
>> I have a question. I'm trying to connect to a use case.
[00:03:50] I just wanted to check with you. For example, I have a browser that opens the UI, but I deployed with newer version in the server. So unless I do a hard refresh, I don't see the newer versions, the. Is there a way that sync works like, hey, I have a new version, the server gets sort of the push notification or something to see-
>> Well, you can do that with push, but there is no direct relationship between a push and a sync. So if a push message is waking up the service worker, the service worker can take advantage of that moment to update the data. You don't need to wake up the service worker and register a sync.
[00:04:34] I mean, you can, but you're already there so you can take advantage of that moment and download the new data at that moment when the push arrives. Unless the connection isn't working so in that case you can leave a pending sync for the future. So you can try again later, make sense?
[00:05:25] What I need is the button sync. So that is sending a sync operation. So I'm getting in my service worker an unknown sync with that Tag name. What are the other ways that we have for a server to unilaterally wake up your service worker and interact with it?
>> From your server, you say?
>> Yeah, I mean, is that-
>> From the server there's only one way, and that's with push with user's permission. If you want to wake up the service worker from the server, the only way you have is web push.
>> And does that require the user's permission once or every time?
>> But they get the notification every time.
>> But they can deny identification-
>> A notification every time.
>> Is a notification permission, it's the same dialogue as notification. So push notification is just one big umbrella, okay? But web sync API, the client is the one, so the web page client side is the one registering the sync operation.
[00:06:39] Yeah, you can trick these and you can have a timer, the registers sync every half an hour just to see if there is something new but yeah, it won't make any difference.