The PRPL Pattern
Download as PPTX, PDF2 likes937 views
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.
Ad
More Related Content
What's hot (20)
Similar to The PRPL Pattern (20)
Ad
More from Red Pill Now (20)
Ad
Recently uploaded (20)
The PRPL Pattern
- 1. The PRPL Pattern for Domino Web Apps Keith Strickland – Red Pill Now
- 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
- 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
- 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
- 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
- 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
Editor's Notes
- #20: Domino does not support HTTP2 Push. Proxy requests handled by: NGINX Apache Apache Tomcat node-http2
- #22: When a route is visited, the server will push dependencies to the browser Requires an application server NodeJs Apache Tomcat Liberty etc
- #23: 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
- #25: For example for a typical domino app. Each view will be a page and each document type will be a page
- #27: 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
- #29: 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
- #31: 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.
- #35: (1 for each route essentially and any external dependencies)
- #40: GPS Access for location services Camera Access Gyroscope Access (Version 60 of Chrome) Bluetooth
- #41: 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
- #45: However, if web components are used, this can be built into your components
- #48: 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)
- #50: Web components / Polymer AngularJS, Ember, React, Backbone/Marionette Any modern frontend framework
- #51: 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
- #53: 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
- #55: 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.
- #56: 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)
- #58: 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
- #59: 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
- #60: 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
- #61: A requirement for http2 push, service worker and offline access
- #64: No User API No way to tie in backend workflow, sending of emails/notifications Learn about and use the OpenNTF Domino API (ODA)
- #65: No User API No way to tie in backend workflow, sending of emails/notifications Learn about and use the OpenNTF Domino API (ODA)
- #74: Most phone hardware functionality is available to browser APIs and that list is growing