The document discusses an HTTP fallback approach for handling situations where push notifications are unavailable or blocked. It describes storing build results in a restaurant entity database and polling from the client to retrieve updates via GET requests. The polling code makes an initial GET request and then schedules repeated requests until the value changes, at which point it cancels the timer and returns the result. While not ideal, this provides an alternative to push notifications by periodically checking for updates over HTTP.

1. Push Http Fallback
Push is fragile and can be blocked by the user. In order for the app to work properly we need to properly handle the situation where push isn’t available and we can do
that with a fallback implementation. I have two such implementations, I will start with the http based implementation.

2. The async build code needs a place where it can deliver the message sent back to the client. The restaurant entity is pretty convenient for that…

3. We can store the result from the build process in the last result entry within the restaurant entity.

4. You might recall the BuildAppService class where we send the build async call using a POST method. We can just return the response by using a GET method to fetch
the entity. Database transactions take care of the rest and all we need to do now is poll from the client for this update

5. In the client side the build app method sends a build to the server. Here we have the polling fallback code to see how the connection is working.

6. If we have a push key we don’t need polling as push will take care of this. But if we don’t have it then polling needs to kick in

7. The polling code is pretty simple lets review what we have here… First we have a request to the build app URL again. This time however, we pass false instead of true to
the second argument. That means we are making a get request instead of a post request.
We wait for the response and check if it’s valid.

8. We then schedule a timer that will keep polling as long as the value hasn’t changed. Once that’s done we cancel the time and return the value with onBuildResult.
This isn’t ideal and normally we try to avoid http polling. Check out a better approach demonstrated in the websocket version

9. Thank You
Thanks for watching. I hope you found this informative