An introduction to Google's PRPL pattern that can be used to implement Progressive Web Applications. Delivered at MWLUG 2017 in Alexandria, VA by Keith Strickland.
44. PWA: Other Considerations
Accessibility â There should
be some accessibility aspects
to your application. This is a
whole subject unto itself
(Attend Royâs Session Tomorrow at 9:00 âWeb
Accessibility and the Lawâ)
45. PWA: Other Considerations
âą Best Practices
â Avoid WebSQL Databases
â Use HTTP2
â Avoid using deprecated APIs
â Avoid Render Blocking CSS
46. Why you should care?
Because you want to delight
your users!!
âą Fast, I mean really fast
âą Works offline
âą Looks and behaves the same
no matter the device
47. Why you should care?
âą Because you want to learn
and work with the latest
technologies
52. Modern Web Capabilities
Over the years APIs have
been built around all the different
capabilities of a
mobile device
53. Modern Web Capabilities
For a full list of Web APIs visit:
https://developer.mozilla.org/
en-US/docs/Web/API
54. Offline
âą Adding a service worker
allows you to:
â Deliver content even if there is no
network
â Background Sync
â Push Notifications
55. Offline â Network Handlers
âą Network Only
âą Cache Only (not recommended
for dynamically generated
content)
âą Network First
âą Cache First
âą Fastest
57. What Offline Isnât
POST, PUT, PATCH, DELETE
There is no means of storing
these requests and then
sending to the server once
the network is available
58. Fast
âą Small web bundles
âą If possible pre-fetch the data then
render
60. Secure
All web apps should be
delivered via HTTPS. This
ensures a secure experience
for the user
61. How does this apply to Domino?
While people really donât like
the notes client, the
application data is still useful
and stored in an awesome
document database
62. How does this apply to Domino?
Put old apps on the web,
available from any device at
any time (even offline)
63. How does this apply to Domino?
âą Can surface data without any
backend/java experience using
DDS
â While this is functional to a point
not recommended
64. How does this apply to Domino?
The PRPL Pattern still
applies, itâs just a
recommended pattern
69. Troubleshooting Tools
âą Application Panel
â See service worker information
â See whatâs in the cache, local and
session storage
â See the manifest.json settings
70. Troubleshooting Tools
âą Lighthouse Extension or
Chrome Canary
â Test your app for PRPL Pattern
and PWA adherence
â Performance Test
â Accessibility Test
â Best Practices Test
71. Where weâre heading
âą The lines between native apps and web apps are
blurring
âą I think the future of mobile applications are with web
apps
â Most phone hardware functionality is available to
browser APIs and that list is growing
âą JavaScript is quickly becoming a juggernaut and will
be one of the prime players in delivering applications
to any device.
âą Where weâre currently seeing JavaScript being
used:
â Backend architecture that previously was the domain
of Java, Python, Ruby on Rails, etc.
â Complex AI hardware like Alexa, Google Home, etc.
â APIs also make Arduino hardware reachable via
JavaScript
â ES6 brings more OOP style programming to
JavaScript along with a lot of syntactical sugar
Domino does not support HTTP2 Push. Proxy requests handled by:
NGINX
Apache
Apache Tomcat
node-http2
When a route is visited, the server will push dependencies to the browser
Requires an application server
NodeJs
Apache Tomcat
Liberty
etc
The app shell is just the layout (i.e. Header, Footer, Sidebar, Content Area, etc)
Unfortunately since most of your site is defined here, dependency management is critical
For example for a typical domino app. Each view will be a page and each document type will be a page
Each bundle should only include the minimum dependencies so that the element can be placed in the DOM as quickly as possible.
All other dependences should be requested on demand once the element is registered with the browser and stamped into the DOM
The service worker will then pre-cache these files for quick retrieval if they arenât already cached or the fileâs UNID has changed
When the page is registered with the browser and stamped into the DOM it should request itâs dependencies or those dependencies should be pushed to the browser via HTTP2 Push.
(1 for each route essentially and any external dependencies)
GPS Access for location services
Camera Access
Gyroscope Access (Version 60 of Chrome)
Bluetooth
This is where our next dragon lives, offline access can be easy to implement, however picking the correct paradigm is sometimes tricky and isnât realized until real world use or with extensive testing
However, if web components are used, this can be built into your components
Modern JS frameworks and libraries, Web Components
Service Workers
Different from Notes/Domino (But that doesnât mean you canât surface Domino Data from an NSF)
Web components / Polymer
AngularJS, Ember, React, Backbone/Marionette
Any modern frontend framework
Frontend framework of some kind
Gulp or some other build system
Web Bundles
Service Worker Generation
Automated Testing
Service Worker
Offline
REST Service of some sort (doesnât really matter here, any REST service capable of servicing your appâs needs will work)
Data layer
GPS
Camera
Gyroscope
Bluetooth
etc
The Web Animation API is also a great API for delivering modern performant animations. However CSS Transform is also a good tool but a bit more tedious
Uses the Cache API
Is unaware of the Frontend UI
Think of it as a proxy server
Intercepts all requests being made from the browser to the network. If the request url is stored in the cache, deliver that. If itâs not in the cache, get from the network, update the cache and deliver the network response.
Fastest â Make 2 requests: 1 to the cache and 1 to the network. Whichever comes back first wins and the cache is updated from the network request. (Recommended strategy, however does have some dragons to slay. The most complex strategy due to testing effort)
Idea: Since a Service Worker continues to run even after the app is closed (to service push notifications), it may be possible to cache the requests and monitor for the network to return and then submit the requests. However, consideration must be taken to ensure workflows, notifications, etc. would still continue to work.
Would require you to custom roll your own service worker which is not entirely that complicated
we no longer deliver HUGE payloads that contain the entire application in a single file. We now have smaller payloads made up of only the things we need for each route/page. Everything else is fetched when needed.
Deliver from the cache
Pre-Cache the routes and App Shell
Lazy Load any other dependencies when theyâre needed
Modern web applications should adapt to what device theyâre being displayed on and shouldnât require a different version for each type of device (i.e. Android, iOS, Browser, etc)
We should be able to add our application to the home screen of our phone or tablet
This gets rid of the address bar and produces a cleaner more engaging experience
It should be well designed and easy to use.
Icons placed too close together makes things harder to touch and be confident you are touching the right thing, so be aware of your touch targets
Depending on your design criteria, colors should be bold and images should be high-def. But should be optimized for the web.
Functionality should be grouped in an easy to understand, intuitive manner, not scattered all over the screen (Web Components address this very nicely)
Animations should be a confirmation of what the user did and should be smooth with no jank
A requirement for http2 push, service worker and offline access
No User API
No way to tie in backend workflow, sending of emails/notifications
Learn about and use the OpenNTF Domino API (ODA)
No User API
No way to tie in backend workflow, sending of emails/notifications
Learn about and use the OpenNTF Domino API (ODA)
Most phone hardware functionality is available to browser APIs and that list is growing