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.

1. The PRPL Pattern for
Domino Web Apps
Keith Strickland – Red Pill Now

2. Our Amazing Sponsors

3. Keith Strickland
Co-Founder
keith@redpillnow.com
@keithstric
redpillnow.comwww
Atlanta, Georgia
keithstric.me

4. Challenge the way you think about Notes data

5. Change the way you approach your next project

6. Understand the potential of the prpl-pattern

8. The PRPL Pattern

9. What is the PRPL Pattern?
Push
Render
Pre-cache
Lazy-load

10. What is the PRPL Pattern?
The PRPL Pattern is just that,
a pattern which will result in
an awesome web app
experience

11. What is the PRPL Pattern
It’s really an idea around how
to use underlying technology
to produce a great web app
experience

12. PRPL - P is for Push
Push Critical Resources

13. PRPL – R is for Render
Render Initial Route

14. PRPL – P is also for Pre-cache
Pre-cache remaining
routes

15. PRPL – L is for Lazy-load
Lazy-load and create
remaining routes on
demand

16. PRPL Pattern in Use
We can skip some of the pattern
and implement what we need when
we need it

17. PRPL Pattern in Use
With the exception of
HTTP2 Push capabilities,
The PRPL Pattern works on
any platform using pretty
much any technology

18. Implementation

19. Implementing Push
• Because it requires HTTP2,
Push is not available on
Domino

20. Implementing Push
The server identifies the resources
required by each route and pushes
those resources to the browser
using HTTP2 push

21. Implementing Push
The server must be aware of
the application’s routes
(push_manifest.json)

22. Implementing Render Initial Route
Renders the app shell first,
then proceeds to render other
elements

23. Implementing Render Initial Route
Each page should have it’s
own URL

24. Implementing Pre-Cache
Decide up front before any
code is written what the
pages of your app will be.

25. Implementing Pre-Cache
polymer.json file defines your
bundles for each page to build
system

26. Implementing Pre-Cache
Your build process should
then make each of the page’s
resources into a bundle

27. Implementing Pre-Cache

28. Implementing Pre-Cache
sw-precache.json defines
bundles, images, stylesheets,
script files, etc to your service
worker to pre-cache

29. Implementing Pre-cache
The server and service
worker work together to
pre-cache the app’s
resources

30. Implementing Lazy-Load
Each page should load it’s
dependencies only once
when stamped into the DOM.
Preferably from the cache.

31. Implementing Lazy-Load
When the user switches
routes, the application
requests any required
resources that aren’t
cached

32. Putting it all together
A build system is needed
to split our resources into
bundles, concatenate and
minify files, and build the
service worker

33. Putting it all together
Service Worker should have
a Unique ID generated by
Build System

34. Outcomes
Minimal files are required to
load the application

35. Outcomes
Fast Loading due to pre-cache
and small bundles

36. Outcomes
We’re well on our way to a
Progressive Web Application

37. DEMO: Web Bundles

38. Progressive Web Apps

39. What is a Progressive Web App (PWA)?
Uses modern web
capabilities to deliver a
native app like experience
to users

40. Reliable
Loads instantly, even if offline
or with uncertain network
conditions

41. Fast
• Responds quickly to user
interactions
• Animations should be smooth
with NO JANK

42. Engaging
Should feel like a native app
and have the ability to be
added to the home screen

43. Secure
Your app should be served via
HTTPS with no mixed content

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

48. DEMO: Red Pill DIG

49. Technologies taking advantage of PWAs

50. Technologies required to produce a PWA

51. Exploring The Pieces

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

56. What Offline Isn’t
Offline is not a replacement
for old school replication

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

59. Engaging
• Responsive
• Ability to add our app to the
home screen

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

65. Demo – Domino App

66. Troubleshooting Tools
Chrome Developer Tools

67. Troubleshooting Tools
• Elements Panel
– See your app’s DOM
– Interact manually to see and
manipulate element properties

68. Troubleshooting Tools
• Console Panel
– Interact with your app, see logging
messages, etc.

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

72. Where we’re heading
The lines between native apps
and web apps are blurring

73. Where we’re heading
I think the future of mobile
applications are with web
apps

74. Where we’re heading
JavaScript is quickly becoming a
juggernaut and will be one of the
prime players in delivering
applications to any device.

75. Where we’re seeing JavaScript
Where we’re currently seeing
JavaScript being used

76. Where we’re seeing JavaScript
Backend architecture that
previously was the domain of Java,
Python, Ruby on Rails, etc.

77. Where we’re seeing JavaScript
Complex AI hardware like Alexa,
Google Home, etc.

78. Where we’re heading
APIs also make Arduino hardware
reachable via JavaScript

79. Questions