This website uses cookies to better the user experience of its visitors. Where applicable, this website uses a cookie control system, allowing users to allow or disallow the use of cookies on their computer/device on their first visit to the website. This complies with recent legislative requirements for websites to obtain explicit consent from users before leaving behind or reading files such as cookies on a user’s computer/device. To learn more click Cookie Policy.

Privacy preference center

Cookies are small files saved to a user’s computer/device hard drive that track, save, and store information about the user’s interactions and website use. They allow a website, through its server, to provide users with a tailored experience within the site. Users are advised to take necessary steps within their web browser security settings to block all cookies from this website and its external serving vendors if they wish to deny the use and saving of cookies from this website to their computer’s/device’s hard drive. To learn more click Cookie Policy.

Manage consent preferences

These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms. You can set your browser to block or alert you about these cookies, but some parts of the site will not then work. These cookies do not store any personally identifiable information.
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.
Cookies list
Name _rg_session
Provider rubygarage.org
Retention period 2 days
Type First party
Category Necessary
Description The website session cookie is set by the server to maintain the user's session state across different pages of the website. This cookie is essential for functionalities such as login persistence, ensuring a seamless and consistent user experience. The session cookie does not store personal data and is typically deleted when the browser is closed, enhancing privacy and security.
Name m
Provider m.stripe.com
Retention period 1 year 1 month
Type Third party
Category Necessary
Description The m cookie is set by Stripe and is used to help assess the risk associated with attempted transactions on the website. This cookie plays a critical role in fraud detection by identifying and analyzing patterns of behavior to distinguish between legitimate users and potentially fraudulent activity. It enhances the security of online transactions, ensuring that only authorized payments are processed while minimizing the risk of fraud.
Name __cf_bm
Provider .pipedrive.com
Retention period 1 hour
Type Third party
Category Necessary
Description The __cf_bm cookie is set by Cloudflare to support Cloudflare Bot Management. This cookie helps to identify and filter requests from bots, enhancing the security and performance of the website. By distinguishing between legitimate users and automated traffic, it ensures that the site remains protected from malicious bots and potential attacks. This functionality is crucial for maintaining the integrity and reliability of the site's operations.
Name _GRECAPTCHA
Provider .recaptcha.net
Retention period 6 months
Type Third party
Category Necessary
Description The _GRECAPTCHA cookie is set by Google reCAPTCHA to ensure that interactions with the website are from legitimate human users and not automated bots. This cookie helps protect forms, login pages, and other interactive elements from spam and abuse by analyzing user behavior. It is essential for the proper functioning of reCAPTCHA, providing a critical layer of security to maintain the integrity and reliability of the site's interactive features.
Name __cf_bm
Provider .calendly.com
Retention period 30 minutes
Type Third party
Category Necessary
Description The __cf_bm cookie is set by Cloudflare to distinguish between humans and bots. This cookie is beneficial for the website as it helps in making valid reports on the use of the website. By identifying and managing automated traffic, it ensures that analytics and performance metrics accurately reflect human user interactions, thereby enhancing site security and performance.
Name __cfruid
Provider .calendly.com
Retention period During session
Type Third party
Category Necessary
Description The __cfruid cookie is associated with websites using Cloudflare services. This cookie is used to identify trusted web traffic and enhance security. It helps Cloudflare manage and filter legitimate traffic from potentially harmful requests, thereby protecting the website from malicious activities such as DDoS attacks and ensuring reliable performance for genuine users.
Name OptanonConsent
Provider .calendly.com
Retention period 1 year
Type Third party
Category Necessary
Description The OptanonConsent cookie determines whether the visitor has accepted the cookie consent box, ensuring that the consent box will not be presented again upon re-entry to the site. This cookie helps maintain the user's consent preferences and compliance with privacy regulations by storing information about the categories of cookies the user has consented to and preventing unnecessary repetition of consent requests.
Name OptanonAlertBoxClosed
Provider .calendly.com
Retention period 1 year
Type Third party
Category Necessary
Description The OptanonAlertBoxClosed cookie is set after visitors have seen a cookie information notice and, in some cases, only when they actively close the notice. It ensures that the cookie consent message is not shown again to the user, enhancing the user experience by preventing repetitive notifications. This cookie helps manage user preferences and ensures compliance with privacy regulations by recording when the notice has been acknowledged.
Name referrer_user_id
Provider .calendly.com
Retention period 14 days
Type Third party
Category Necessary
Description The referrer_user_id cookie is set by Calendly to support the booking functionality on the website. This cookie helps track the source of referrals to the booking page, enabling Calendly to attribute bookings accurately and enhance the user experience by streamlining the scheduling process. It assists in managing user sessions and preferences during the booking workflow, ensuring efficient and reliable operation.
Name _calendly_session
Provider .calendly.com
Retention period 21 days
Type Third party
Category Necessary
Description The _calendly_session cookie is set by Calendly, a meeting scheduling tool, to enable the meeting scheduler to function within the website. This cookie facilitates the scheduling process by maintaining session information, allowing visitors to book meetings and add events to their calendars seamlessly. It ensures that the scheduling workflow operates smoothly, providing a consistent and reliable user experience.
Name _gat_UA-*
Provider rubygarage.org
Retention period 1 minute
Type First party
Category Analytics
Description The _gat_UA-* cookie is a pattern type cookie set by Google Analytics, where the pattern element in the name contains the unique identity number of the Google Analytics account or website it relates to. This cookie is a variation of the _gat cookie and is used to throttle the request rate, limiting the amount of data collected by Google Analytics on high traffic websites. It helps manage the volume of data recorded, ensuring efficient performance and accurate analytics reporting.
Name _ga
Provider rubygarage.org
Retention period 1 year 1 month 4 days
Type First party
Category Analytics
Description The _ga cookie is set by Google Analytics to calculate visitor, session, and campaign data for the site's analytics reports. It helps track how users interact with the website, providing insights into site usage and performance.
Name _ga_*
Provider rubygarage.org
Retention period 1 year 1 month 4 days
Type First party
Category Analytics
Description The _ga_* cookie is set by Google Analytics to store and count page views on the website. This cookie helps track the number of visits and interactions with the website, providing valuable data for performance and user behavior analysis. It belongs to the analytics category and plays a crucial role in generating detailed usage reports for site optimization.
Name _gid
Provider rubygarage.org
Retention period 1 day
Type First party
Category Analytics
Description The _gid cookie is set by Google Analytics to store information about how visitors use a website and to create an analytics report on the website's performance. This cookie collects data on visitor behavior, including pages visited, duration of the visit, and interactions with the website, helping site owners understand and improve user experience. It is part of the analytics category and typically expires after 24 hours.
Name _dc_gtm_UA-*
Provider rubygarage.org
Retention period 1 minute
Type First party
Category Analytics
Description The _dc_gtm_UA-* cookie is set by Google Analytics to help load the Google Analytics script tag via Google Tag Manager. This cookie facilitates the efficient loading of analytics tools, ensuring that data on user behavior and website performance is accurately collected and reported. It is categorized under analytics and assists in the seamless integration and functioning of Google Analytics on the website.

How to build a Progressive Web App with React & Apollo Client

  • 26993 views
  • 9 min
  • Jan 02, 2020
Dasha D.

Dasha D.

Copywriter

Vladislav V.

Vladislav V.

Ruby/JS Developer

Share

This guide is for developers who want to make a web application that looks and behaves like a native app.

In this article, we’ll show how to build a progressive web app (PWA) using React and Apollo client. Our PWA will launch from the home screen, run in a separate window, send push notifications, and even work offline.

What’s a PWA?

A progressive web app is a modified website that looks like and gives the feel of a native app. These apps are called progressive due to their broad functionality and features such as fast response times, offline capabilities, and cross-platform compatibility. This makes development and maintenance much easier, as you don’t need to register a PWA in app stores (though you can if needed). Not surprisingly, big and famous corporations like Starbucks, Twitter, Uber, Pinterest, Spotify, and others choose PWAs over native apps.

The key characteristics of a PWA make up the acronym FIRE:

  • Fast. Data exchange is fast, and a PWA’s UI is smooth and responsive.
  • Integrated. PWAs feel natural to users and look like any other app.
  • Reliable. A PWA launches fast and always displays content, even when the network connection fails.
  • Engaging. The user experience is immersive and comfortable.

PWAs are gaining popularity due to a long list of benefits. Let’s dive deeper into the matter to learn about PWA’s advantages and disadvantages.

Advantages of progressive web apps

They’re fast

As a PWA caches resources, PWA pages load at a glance, affording a considerable advantage for any company. Users will definitely come back for such an experience. Moreover, using an app shell, web app manifest, and service worker, PWAs tend to have the speed of native apps.

They’re affordable

Any user with any device can access a PWA via a URL. PWAs download onto a device quickly, and they don’t need as much storage space as apps do. 

PWAs are also cheaper and faster to build than native apps. All that a developer must know is HTML, CSS, and JavaScript.

They can work offline

Your users will never get a no connection error, as PWAs can use a service worker API that keeps pages cached for offline use. So if users don’t have an internet connection, they’ll still see your app’s content.

Disadvantages of progressive web apps

Despite a long list of benefits PWAs provide, there are also some drawbacks you need to be aware of.

They lack app features

Due to their limited functionality, PWAs have restricted access to device hardware and user data (calendars, contacts, alarms, social media profiles). 

They’re difficult to track

As PWAs work offline, it’s hard to monitor and evaluate their performance and metrics. This may lead to halts in PWA maintenance and operations.

They conflict with iOS

Unfortunately, push notifications fall into the category of PWA features that are not available to iOS users. In addition, iOS limits the amount of storage space available to PWAs, so cached files for offline use are available for only two weeks.

Challenges

In our case, we faced three challenges: we wanted our PWA to look like a native app, be able to work offline, and be able to send push notifications. To solve these challenges, we decided to create a progressive web app with React and Apollo Client. Let’s take a look at the advantages of this choice.

Why Apollo Client?

Apollo Client is the best option when integrating React apps with GraphQL APIs. When you finish writing a GraphQL query, Apollo Client will start requesting and caching the data as well as updating the UI of the PWA. With Apollo Client, you can add sophisticated features hassle-free. 

When building a progressive web app with React, Apollo Client lets you:

  • Fetch declarative data 
  • Enjoy useful tools for developers: TypeScript, Chrome DevTools, VS Code
  • Benefit from brand-new React features such as hooks
  • Add Apollo to a JavaScript app
  • Share your knowledge and life hacks with other developers in the open-source community

#1 How to make a PWA look like a native app

In order to get rid of the browser-looking UI, we’ll use the web app manifest. This is a JavaScript Object Notation (JSON) file, an open and lightweight data interchange format for storing and transporting data. It will tell the browser how to behave when the PWA is installed on the user’s device.

Typically, a basic web app manifest includes:

name – The name of the app that users will see in the request to add the PWA to the home screen 

short_name – The short name of the app that users will see on the home screen

background_color – The color of the splash screen when the user launches the PWA

display - Customizes the browser UI (We opted for standalone, which means that our PWA opens in a new window, changing the standard browser UI and hiding the address bar.) 

scope – Gathers the set of URLs and helps you understand when the user has left the app

start_url – The URL that loads when the PWA launches; directs the user to the starting page, not the page where they added the PWA to the home screen 

theme_color – Defines the color of the toolbar

icons – The set of icons that are used on the home screen, app launcher, task switcher, and splash screen

The result

As a result, we get the following web app manifest for our PWA:

Let's look at how the application looks in a browser:

How to build a PWA with React & Apollo Client
Here's how the app looks in a browser

Next, we get an app that is functioning on a phone and looks like a native app with the icon:

How to build a PWA with React & Apollo Client
Here's how our PWA app looks saved on a phone

#2 Offline first

Offline first, or cache first, is a famous strategy for delivering content to users. This is how it works: if a resource is cached or available offline, we’ll try to get it from the cache. If the resource is not cached, we’ll download it from the server and add it to the cache.

Cache 

To open a PWA while offline, we need to have its files cached: JavaScript, HTML, CSS, images, etc. This is when a service worker can help. We’ve applied a service worker to add files to the cache and show them to users when needed.

What we used

We used create-react-app with a built-in service worker. To make everything work, we changed serviceWorker.unregister() to serviceWorker.register() in index.js. After this, all files will be cached, so we can use the PWA without an internet connection and browse static pages. 

Offline queries

In order for users to see previously loaded content while they’re offline, we also need the cache. But this time we’ll deal with server responses, not PWA files. The thing is, Apollo Client already stores responses in its cache. However, if you reload the page, everything will disappear. To work around this, we used apollo-cache-persist to save the cache in local storage. Now, when the PWA launches, the cache from local storage initializes the Apollo cache. In this way, users will see the app’s content when they don’t have an internet connection.

We decided to add a loader that users will see while the local storage cache initializes the Apollo cache.

Offline mutations

It looks like everything already works fine, but what if a user wants to post something or add a task to a to-do list while offline? Using Apollo, we can trick users and show that their post or task has been added offline. However, the real request will be sent when the connection is re-established.

We used an optimistic response in Apollo Client to make it look like a post or task has been added. The user is shown a fake optimistic response before the real response comes from the server. When the internet connection is re-established, Apollo will update the cache with the actual data.

Here’s how it works:

The code above shows the optimistic response to the user, but we still need to send the request. To fulfill this goal, we used a set of libraries:

  • apollo-link-retry to send the request one more time in case something goes wrong
  • apollo-link-queue to queue all offline requests
  • apollo-link-serialize to use along with the apollo-link-queue when two mutations — for instance, adding a task and deleting it in offline mode — will be executed simultaneously, which can lead to errors

This is what we get as a result:

We want to record the offline mutation data in local storage and use, create, and execute new mutations based on the initial mutations when the user is online again.

Here’s the custom link for that:

We need to add the link above to this chain:

After that, we get the mutation data while initializing the component. We add it straight in the root component:

#3 Push notifications

The last thing we’re going to do is implement push notifications. We decided to do that via Firebase. We created a separate service worker firebase-messaging-sw.js and placed it in public.

Here is the result:

After that, you need to initialize Firebase in index.js.

Finally, we requested permission to send notifications to users when it’s most relevant. We aren’t going to send them at the start, as it’s irritating and users simply decline the request. The best practice is to send a request after the user has performed some action in the PWA and gotten positive feedback. At this point, the user is pleased and is ready to accept the request to send notifications. Alternatively, you can add a possibility to turn notifications on in the application's settings. 

Summing up

A progressive web app built with React and Apollo client is a good alternative to a native app, especially when the native features of the web platform and browser API can cover your functionality. The outstanding advantage is that a PWA is still a web app, so we still can transform it into a mobile app hassle-free without rewriting the client part. Additionally, you can add your PWA to the App Store and Google Play Store if needed.

CONTENTS

Authors:

Dasha D.

Dasha D.

Copywriter

Vladislav V.

Vladislav V.

Ruby/JS Developer

Rate this article!

Nay
So-so
Not bad
Good
Wow
16 rating, average 4.69 out of 5

Share article with

Comments (3)
Facu Siracusa
Facu Siracusa almost 5 years ago
Nice article!!! The only problem i have is that if i turn off wifi, the mutation stucks anyway... it seems that apollo is waiting for network, am i missing something ??
Reply
Vladislav V.
Vladislav V. over 4 years ago Facu Siracusa
Hello, Facu. Thanks for your feedback) You have a point. In the article I didn't provide any Wi-Fi tracking logic. Currently demo code closes queue only on offline events. But an offline event is not fired when you turn Wi-Fi off. I think we can archive needed behavior using a change event from Network Information API.
Reply
Juanele
Juanele about 2 years ago
excellent article... my question is how can I update only the cache in v3 of apollo with hook when it is offline
Reply

Subscribe via email and know it all first!