Architectural patterns and caching strategies

Let's talk about the first step after enabling HTTPS: adding caching to the app. How we cache the app will depend on whether you're rendering it on the server, or using a single-page app that renders on the client

TABLE OF CONTENTS

1. Introduction to Progressive Web apps

2. Why Progressive Web Apps?

3. Objective of the Project

4. Advantages of Progressive Web App

5. Advantages of PWA over Native Apps

6. Benefits of Progressive Web App

7. Use Cases

8. The Future of PWA

9. Software Requirements

10. Reference

11. REQUIREMENTS GATHERING

12. Introduction to PWA Architectures

13. Introduction to PWA Architectures

14. Using libraries to code service workers

15. Add to Homescreen

16. Push Notifications

17. Payments and Credential Management

18. Recommended patterns for PWAs

19. CLUSTER AND OUTLINE OF PAGES

20. Code Base

21. Serve the app shell from the cache

22. Automate development tasks

23. Creating a package.json

24. Customizing the init process

25. Managing dependency versions

Architectural patterns and caching strategies

Let's talk about the first step after enabling HTTPS: adding caching to the app. How we cache the app will depend on whether you're rendering it on the server, or using a single-page app that renders on the client

Server-Side Rendering (SSR)

● Server returns a complete page

● Page loads CSS, JavaScript, and all content

● Page updates reload the DOM

Server-Side Rendering is a familiar technique used by many developers where the server builds the whole page. This includes content-driven sites using a CMS.

This is a difficult scenario to make work efficiently offline, since the server returns the whole page.

Client-side rendering (CSR)

● Server returns "template page" with CSS & JavaScript

● JavaScript makes request to get content, adds to page

● Page updates reload only the dynamic content

Client-Side Rendering is also a familiar technique, normally written as a single-page app. In this case, the server has a static page with the content template and the client-side code. JavaScript running on the client makes requests to get data and display it on the page.

This can be a very good fit for the app shell model. The app shell also separates content from presentation, though you may need additional code to cache data for offline use.

Caching SSR

● Cache common files: CSS, Javascript, common images

● For offline use

○ If server renders static pages, cache them

○ Add code for offline mode

Caching server-rendered apps is simple: cache the static parts that you can. That normally includes your CSS files, JavaScript frameworks, and some images. If your server is rendering a small number of unchanging pages, you could cache them, though any forms will need logic to detect if the app is offline and disable the form.

Detecting offline use

We can detect if the browser is on or offline by checking the navigator.offline property. We can also listen for online and offline events on the navigator,

In any case, we should check our network requests for errors and fail gracefully. This will handle both offline access and unreliable networks.

Caching CSR

● Cache core code, CSS, and template page

● Add code to:

○ Cache data using Cache API or IndexedDB

○ Detect when app is offline and save user actions for later replay

Caching client-rendered apps is also fairly simple.

Single-page apps have a core that always lives on the client, so cache that. But they also depend on dynamic data, so we need to add code to handle that. The general idea is that things with a URL go in the cache and non-URL data goes in the database.

One nice feature is to detect when the app is offline and remember user actions. For example, you could let the user build a shopping cart while offline and send it when they are online.

Where does the data live?

Many initial efforts to build a Progressive Web App *always* retrieve files from the network *or* from the cache. But we can use combinations of the cache and the network to improve our app.

Combined strategies

● Cache first, Network fallback

● Network first, Cache fallback

● Network only

● Cache only

In a Cache First strategy, the service worker looks for a file in the cache and uses the network if that fails. Server-rendered apps might use this if they are also caching rendered pages and the app sees a new URL.

On the other hand, a Network-First strategy tries to get the file from the network and uses the cache if that fails. Use this strategy when you need the latest content, such as stock prices or the weather, but are willing to fall back on the cache when offline

Special cases

● Cache first, Network fallback

● Network first, Cache fallback

● Cache-Network race

● Network only

● Cache only

In some cases, we may want to ask the cache and the network at the same time. In most cases, the cached data loads first and that is returned directly to the page. Meanwhile, the network response updates the previously cached entry. This is useful for assets that change infrequently, but that we want to keep up to date, such as user icons. The next time the user loads the page, they will see the updated asset.