Just for Fun — Progressive Web App on Google Cloud Free Tier Hosting
I just finished up a new project. And as always, I like to learn new stuff, and roll that into the essence of the project as I go. Software development is really about learning new stuff. Change is constant (think about that for a moment..) The tools, the language, the techniques… there’s always something new coming along. Nobody programs in Cobol or Fortran with punchcards anymore. And nobody uses Visual Basic anymore either. ha. But I digress.
Its an information application for an unusual small business group. The group has a lot of personnel turnover, and communications among the team is critical. The application provides detailed job description task sheets, a phone directory for the working facility land lines, key references / users guides and a complete business group team directory complete with users photos, phone contact, text page and email references. Until now, the group has published an annual 30 page paper pocket guide. Ugh. Where’s the fun in that? Hey guys, everybody in your organization has a mobile cell phone, let’s use that. We really want to take advantage of mobile browser links href=”tel:+1…” and href=”sms:+1…” and href=”mailto:[email protected]” … Check out the attached screen shots of the phone directory. Included is a photo popup of each individual on demand.
The basis for this application are the general tools used in the phone directory project.
- jQuery Mobile for the presentation framework
- Google Sheets API v.4 for team roster data store
- Phone authentication via Google Firebase
- AJAX calls to server to protect content
- NodeJS with Express to serve both static content and API calls
- Private Git repo at Gitlab
And of course, we’re going to stretch into some new arenas as well.
- Google App Engine at Google Cloud for Nodejs hosting
- Progressive Web App, primarily for native app like performance, and simple icon startup from users mobile phone.
Free Tier at Google cloud.
Google Cloud has a very generous free tier. The two tools I’m interested in are the Google App Engine and Google Compute Engine. A whole lot of what I’ve been doing lately (full stack) involves NodeJS / Express servers.
- 28 instance hours per day
- 5 GB Cloud Storage
- Shared memcache
- 1000 search operations per day, 10 MB search indexing
- 100 emails per day
Google Compute Engine free tier includes:
- 1 f1-micro instance per month…
- 30 GB-months HDD, 5 GB-months snapshot
Wow. Pretty cool. I ended up working with Google App Engine, Standard Environment. After all, my application has a customer base of less than 100 folks. Its not ever intended as a public facing website. The whole process worked pretty well, kinda sorta. Develop application on local host. Push to git repo. Login to Google Cloud, create project. Open App Engine, use GCloud command line interface, pull content from git repo. Push. Repeat. One note: I did initially have a terrible time updating the app engine content. Turns out that using the same Google project for multiple processes wasn’t clever. I had a job stopping error. Issue corrected by using one project for Google Firebase authentication, a second project for Google Sheets API v4 and a third project for Google App Engine. The tutorials on using the app engine from Google are pretty easy to understand.
Eventually updates are as easy as push to git on laptop, login to GCloud console, pull from git, then
$ gcloud app deploy And hey, for anybody working on this stuff, I found this posting particularly helpful.
A couple of notes here. Using the free tier app engine may not be totally free. When you use the app engine, it deploys to the address “https://your-custom-application.appspot.com”. If you want to point a real URL to that location you will have to utilize the Google Cloud DNS service. I pursued that, the cost for minimal use would be only $0.60 / month. Because of our intended use case, the customer was perfectly happy with the provided free xxx.appspot.com url.
Next note: The App engine deployment is now totally SSH secured and free. Yowza. Many thanks Google! Why does that matter, really? This is the lead in to the next point.. Progressive Web Apps. One of the requirements there is SSH for everything.
Progressive Web App
I’ve been really interested in Progressive Web Apps (PWA) lately. Er. so what’s a web app, anyway?
- Responsive – fits any form factor (Mobile / Tablet / Desktop)
- Progressive - Work for every user, regardless of browser choice
- Fast – Content served immediately from cache as appropriate
- Reliable – Content served, even if user is offline
- App-like - Feel like an app to the user with app-style homepage icon, interactions and navigation
- Fresh - Always up-to-date thanks to the service worker update process.
- Safe - Served via HTTPS to prevent snooping and ensure content hasn’t been tampered with
- Linkable - Easily shared via a URL and do not require complex installation.
Special requirements include the requirement for HTTPS server, manifest file, service worker. The hardest thing to get there is the HTTPS server, but that’s done now, ThankYouGoogle! For a great example of a fun little Progressive Web app, check out the breaklock app at https://maxwellito.github.io/breaklock/ (git hub repo…)
In my case the whole PWA thing was a pretty good experience. We’re totally able to share the link and install the “app” as an icon on the users mobile phone home page. The app works well. We’re able to authenticate via Google Firebase, and protect content via AJAX call to server. And for most things this is pretty cool.
There is however one use case that is problematic. And that is what happens if the user goes offline? With a static website, this is a total no-brainer. All of the site’s components are stored in cache according to the manifest file. Per service worker code the cache content is immediately available for offline display.
But in our case, we’re deploying protected “dynamic” content via an AJAX call after the site is initially generated. Purely as a test, I thought it would be interesting to take a snapshot of the site after all the dynamic content is loaded, and store that in cache for display when the customer is offline. And that works great… on Android in the Chrome browser. But alas, totally fail on iOS mobile using Safari browser. Sigh. It seems Safari is not totally compliant with the browser specifications where access to cache is concerned. So.. I’m still working on this, trying to evaluate other options for “secure” offline access.