Why Health Checks Matter0:00
So, the browser has the ability to let us know when it thinks it is offline. But is that enough? I believe that if we are writing a progressive web application, we owe it to our users to let them know when things may not be right. And by that, I mean when something can go wrong with our application. Because let's face it, we are completely dependent upon the network. And networks have issues, they have a lot of issues. One of those is connectivity. But you know, our application won't work if there's some kind of DNS issue. And it could be a global DNS issue or it could be isolated to an individual device.
But you know, our application won't work if there's some kind of DNS issue. And it could be a global DNS issue or it could be isolated to an individual device. So DNS, most issues are DNS. But you know, maybe there's a routing issue, maybe there's an issue with the server itself. There are so many things that can go wrong and I think that we owe it to our users to let them know when the application might not work like it should. So I want to do this. I want to add a health endpoint. This is something that we can pull ourselves. So that, yes, we can still rely upon Navigator Online to determine if the browser is online
This is something that we can pull ourselves. So that, yes, we can still rely upon Navigator Online to determine if the browser is online or not. But we can also do this. If we successfully hit this endpoint, then we can assume that everything is okay as far as everything else. And all we need to do here is just return a response. We don't need any content or anything like that. If we successfully make a request for our health endpoint, then great. We can think that our application is healthy.
Adding a Probe Method1:54
If we successfully make a request for our health endpoint, then great. We can think that our application is healthy. So let's go to our NetAlpine store because that's where we're going to do this. And we will have a probe method that we will use to try to fetch the health endpoint. And this is one of those cases where we don't want to cache anything. So we'll set cache to no store. And then we want to check for two things. We want to check if the request was okay or if the status is 204. Because if we are going to return no content, then we're pretty much going to get a 204 there.
Because if we are going to return no content, then we're pretty much going to get a 204 there. So we want one of these two states, but we also want to store this within a property. And we don't necessarily want to do anything with the online property because this is largely based upon Navigator Online. So let's do this. We're going to have a confirmed online property. We will initialize it with Navigator Online, and that way they start with the same values. But then from here, this confirmed online is now going to be our source of truth. So if we go to the online status view, instead of online, we will use that confirmed online
But then from here, this confirmed online is now going to be our source of truth. So if we go to the online status view, instead of online, we will use that confirmed online property. So that here, we'll set this confirmed online equals to res okay, or if the res status is 204. But if there's an issue making this request, then we'll just set the confirmed online to false because it's false. And really, that is it. Now, we can make this as complex as we want it, or we can make this as simple as we want. I like simplicity.
Polling Application Health3:44
Now, we can make this as complex as we want it, or we can make this as simple as we want. I like simplicity. So this is what we can do. Inside of init, we will set an interval, and we will have this function so that if we are online, we will probe. And that's going to be it. And we can probe, ideally, if we were going to push this out for anyone to use, I would want to probe of 30 seconds to a minute because we don't need right up to date information, but I don't want to wait that long. So we're going to have every three seconds, we're going to poll.
but I don't want to wait that long. So we're going to have every three seconds, we're going to poll. So if we are online, we are going to probe. If we are not online, so if the browser doesn't think that we are online, then we won't probe. And this is one of those places where we can start to add some complexity because in my mind, I'm thinking if we're offline, there's no need to even try to probe. But I can think of some situations of where I might want to do that. In which case, I would want a different set of intervals. If we're online, probe every 30 seconds to a minute. If we're offline, probe every two minutes or something like that.
If we're online, probe every 30 seconds to a minute. If we're offline, probe every two minutes or something like that. So we can add some flexibility here, but I think this is going to be fine. But I do also want to set this confirmed online based upon the value here. So whenever the navigator updates the online property, we update our confirmed online. But we also update it based upon our probes. And that should be it. We've already changed that. We have our end point set up. So we should be good to go.
Updating the Status Banner5:25
We have our end point set up. So we should be good to go. The only other thing I want to change is this text here. Because now it's not just we're offline. There appears to be issues with the application. Please try later, something like that. This is going to be fine. So we can go to the browser. And let's pull up the developer tools. Let's do a hard refresh.
Preventing Banner Flash5:49
And let's pull up the developer tools. Let's do a hard refresh. And really, let's go to the application, let's unregister. And let's do a hard refresh now. We get that flash of that message there, and I don't want that. So before we do anything else, we can come back here and we can say x-cloak. That is Alpine's way of essentially saying, hide this by default. But it doesn't work by default. We have to make it work by going to our CSS. And we have to say that for every element that has the x-cloak attribute,
We have to make it work by going to our CSS. And we have to say that for every element that has the x-cloak attribute, we will set the display to none. And that is important. So there we go there. So we've updated our CSS, which means that we need to re-register our service worker. Because remember, our CSS is part of the shell that's being cached. We want to re-cache the new CSS. So let's do a hard refresh.
Testing Offline and Errors6:43
We want to re-cache the new CSS. So let's do a hard refresh. I didn't see anything flash. Okay, so it flashed once, but every other refresh is going to do the same thing. So hard refresh, it's fine. So that looks good. Now, one thing, we don't need to be signed in in order for this to work. So we can just stay here on this page. Now, of course, we are going to see that polling because we are considered online. If we go offline, there appears to be an issue.
Now, of course, we are going to see that polling because we are considered online. If we go offline, there appears to be an issue. Let's clear our network requests. It's been three seconds, and we're not polling. It works, that's great. So if we go back to our application, and we go back online, then our banner goes away. We start to poll the health of our application, which is great. But let's do this. Let's go back to our route, and let's change this.
But let's do this. Let's go back to our route, and let's change this. The only way I know to make this work is to change our route so that it's not health, it'll be Heath. So now we should be getting a 404, which means, there we go. And if we take a look at the network tab, yes, we are getting 404s for that probe. So the probe is now alerting the user. There's an issue going on here. It's not catastrophic, at least in this particular case, but we can at least see that this works, and that's great.
It's not catastrophic, at least in this particular case, but we can at least see that this works, and that's great. But we need to change our route back so that our URL is correct, and our polling is going to return a 204. Yep, so we are good. So now our application can let the user know when there's an issue, and really any network issue. Because as it is, right now, we're not gonna get a 404. So if there's any other issue, it's gonna be network connectivity, it's gonna be DNS, or the thousand other things that can go wrong with the network.
So if there's any other issue, it's gonna be network connectivity, it's gonna be DNS, or the thousand other things that can go wrong with the network. And I think that's important for a progressive web app.
