Introduction - University of Edinburgh



centercenterRichard GoodIS Applications Division??- UNIVERSITY OF EDINBURGHAPI027 Myed progressive webapp Summary Report8820090900Richard GoodIS Applications Division??- UNIVERSITY OF EDINBURGHAPI027 Myed progressive webapp Summary Report TOC \* MERGEFORMAT 1Introduction PAGEREF _Toc470182420 \h 32Executive Summary PAGEREF _Toc470182421 \h 42.1Service workers and progressive enhancement PAGEREF _Toc470182422 \h 42.2Browser support PAGEREF _Toc470182423 \h 42.3The prototype PAGEREF _Toc470182424 \h 42.4MyEd PAGEREF _Toc470182425 \h 43Browser support PAGEREF _Toc470182426 \h 64Progressive enhancement PAGEREF _Toc470182427 \h 75Service worker PAGEREF _Toc470182428 \h 76CORS PAGEREF _Toc470182429 \h 77The prototype PAGEREF _Toc470182430 \h 87.1The Angular app PAGEREF _Toc470182431 \h 87.2Service worker push PAGEREF _Toc470182432 \h 97.3Service worker offline support PAGEREF _Toc470182433 \h 97.4The Microservices PAGEREF _Toc470182434 \h 117.5Prototype walkthrough PAGEREF _Toc470182435 \h 138References PAGEREF _Toc470182436 \h 18IntroductionThis document is a summary report of the API027 MyEd Progressive Webapp Prototype innovation fund project. To quote the brief of the project:Native apps are costly. They require particular skillsets, such as iOS development or Android development which are not currently core to what we do. In addition, they often require us to develop multiple versions of the same app for specific device types.Progressive Web Apps instead use modern web capabilities to bring features we usually expect from native apps, without having to cater for specific devices. This can remove the requirement to build multiple applications which do the same thing, and requires a skillset most if not all of our web developers already possess.Progressive Web Apps enable the following features:Add to Home Screen allowing mobile app users to have a MyEd icon just like a native appInstant loading using offline cacheNative push notifications allowing us to deliver integrated features for mobile phones and desktopsLocation awareness to deliver relevant content based on the user’s current locationOffline/limited network capability allowing us to deliver a consistent experience to students regardless of the quality of their internet connection?Using these modern techniques, we can deliver a better, engaging experience for students using MyEd.This innovation project would produce a prototype application which delivers on the key features identified above. This project is linked to the User Centered MyEd digital transformation proposal, essentially reducing the technical risk by proving key technical concepts. The next section contains an executive summary of key points learned and considered during the production of the prototype. Following sections go into more detail.Executive SummaryService workers and progressive enhancementService workers and progressive enhancement are a very powerful way to gracefully introduce native features into a web application. It can allow push notifications, and reduce bandwidth requirements by introducing local caching to allow a site to still render with no network, which is especially useful for mobile devices which may have limited data plans, and variable network speeds. Caching content in this way can also help reduce the traffic going to servers and thereby reduce load.Browser supportFull browser support is mainly centered around Firefox and Chrome currently, although Edge is implementing full support, and Safari via WebKit has service workers under consideration currently. In time I would expect all modern browsers to support this.The prototypeThe prototype successfully demonstrates the power behind using a combination of service workers and AngularJS to deliver a flexible powerful client side running application.The prototype is stored in Gitlab at: MyEdIn terms of how we could introduce this to MyEd, we currently have an HTML front page which all users hit prior to accessing uPortal. It would be entirely possible to gradually enhance this front site with service worker/angular support so that we could begin the gradual move towards a more client-side based portal implementation. Essentially the prototype is just HTML and JavaScript, there is no back-end DB required if it can get all the information it needs via APIs. Having a feature by feature release where we add to Angular and remove from uPortal would allow us to transition from one to the other over time, rather than do a big bang transition. That would have the added benefit of also allowing us to monitor the new app and reduce risk of failure.The University of Wisconsin/Madison has implemented an Angular based portal () which follows a similar line, they did a soft launch production release at the end of December 2014, and are gradually adding more content into the angular front-end.Browser supportWeb push notifications are in their relative infancy. The following chart shows the support for service workers across the main browsers:Figure 1. Service worker browser supportMost of the modern browsers provide at least basic support for service workers. Internet Explorer does not, as Microsoft has moved to adding new features to Edge. Safari uses WebKit, and Service Workers is currently marked as Under Consideration (see ). As a result, Safari push notifications are not possible at this stage. If push notifications to iOS devices are required, then either an app would have to be created, or we would have to wait for WebKit to be updated to support the push specification.The key thing though about progressive web is that it should gracefully enable on browsers which support it, and as support grows, browsers which update to include support will automatically gain that feature on a site which uses it.NOTE: For a more detailed technical list of support for service worker features see Progressive enhancementThe idea behind progressive enhancement is to essentially introduce a base level of functionality, and gracefully upgrade to greater functionality if the browser supports it. In this way, you can introduce advanced features without compromising the minimum functionality of the site. As mentioned in the previous section, this prevents older browsers from experiencing errors when interacting with the site, more advanced features will be unavailable but the site will perform as intended.Service workerIt is worth mentioning what a service worker is, and what it enables. Service workers are essentially JavaScript event listeners which can work independently of a site in a browser to deliver and perform various tasks. This means that the browser site does not have to be open for site actions to take place, which is a powerful mechanism.A service worker is essentially a small JavaScript file which sits at the root of the site, and is loaded by the website dynamically, in our case by adding the following code into the angular app.js file. Note that the code will only register the service worker if service workers are supported (that’s what the if (‘serviceWorker’ in navigator) part is checking.Figure 2. service worker intialisation checkNOTE: The service worker javascript file must be placed at the root of the site to have the necessary permissions to perform all actions.CORSCORS, or Cross Origin Resource-Sharing, is a mechanism by which domains can authorize other domains to access their resources. This is important in a microservice architecture where the microservice may not sit on the same domain as the application. Essentially, when a browser makes a request, it sets its origin in a header, and the resource then via CORS can indicate which domains it will accept requests from. For example, myed.ed.ac.uk may access resources on notify.ws-apps.is.ed.ac.uk if the notify domain accepts requests from *myed.ed.ac.uk. The prototypeThe prototype was built using an HTML mockup produced by Marissa Wu in Learning Teaching and Web division. From the basis of the prototype the following were introduced:An Angular app and controllersService worker support for pushService worker support for offline cacheA Node web server to easily deliver the prototype contentThe basic premise of the prototype would be to:Introduce a basic login using OAuthGet user information from a Central Auth microserviceGet notifications from the Notification Backbone microserviceAllow users on supported browsers to subscribe to push notificationsAllow users to receive push notifications in near real-time when notifications are created in the notification backboneThe prototype is stored in Gitlab at: The Angular appAngular is a powerful client side framework which makes it easy to template functions, use APIs and asynchronously deal with content on the page. As such it’s ideal for building client side heavy applications and works well with service workers.For the prototype, the angular app handles:The loginWhich HTML template to displayData access to the microservicesRegistration of the service workerPush subscribe and unsubscribe eventsService worker pushIn order to implement push notifications, the service worker has to define a push listener. It will accept data from an event, and can then show a notification to the user.See the following example from service-worker.js, where we define a new push event listener, use the JSON provided from the notification backbone and call showNotification to show it to the user (giving the user the University of Edinburgh logo so they have a visual cue as to who it’s from):Figure SEQ Figure \* ARABIC 3. Push service workerService worker offline supportOffline support using local storage has three important benefits:Allow pages to render when network connection is poor/absentReduce load on servers by avoiding network traffic for cacheable resourcesSpeed up render of pages by avoiding network latencyIn order to implement offline support, the service worker is modified to make use of the install and fetch events. First we use the install event, to get local resources and add them to a local storage cache. See the following example from the service-worker.js file where we set up an array containing the files to cache, then use an install event listener to store them in a named cache:Figure SEQ Figure \* ARABIC 4. install listener, caching static filesThen, you need to create an event listener which will intercept fetch requests and respond with items in the cache. As the fetch is essentially being intercepted, you need to also make sure non cache hits perform a fetch passing any credentials which may be set (such as an OAuth bearer token in the case of the microservices).Figure 5. fetch listener, returning cached items for cache hitsFinally, you need to create an activation listener which will check for old caches and remove them. This prevents caches cluttering up your browser storage, and essentially allows you to version the cache and introduce or remove items from it. Any change to the cacheName variable referenced in Figure 1. Would trigger cache removal on activation.Figure 6. activate listener, looking for old caches and removing themThe MicroservicesIn order for the prototype to work with the microservices, CORS (see Section 6) was enabled on both the Central Auth and Notification Backbone microservice so that they would accept requests from the prototype domain.In addition, in order to allow push notification support, the notification backbone microservice was modified to allow the browser to POST a push subscription to it, which essentially contains the URL endpoint the notification backbone will talk to when sending notifications back to the users browser. The JSON packet for a push subscription looks like this:{ uun: "rgood", endPoint: "", key: "BH+kB3w4pULBUA2+gRh4xRFd0mKF1OPh9le81w1dAvx+UyQWzCAUucHwQLRDIGYZjrGVSTZPl+BsLSms=", auth: "WLSA0qLRRunT9GQ6w1CDmA==", gcmApiKey: "AABCW5i0E7Pg528HQ_dk9b0uU1mokG15UJG00jdmwXkPBWYHBtckWg"}uun is the user for whom the push subscription applies.endPoint is android. for Chrome based browsers, Firefox for example is updated.push.services.. Key and Auth are required in order to authenticate/authorize calls to the endpoint.gcmApiKey (Google Cloud Messaging) is for chrome only, and is the api key for using the firebase cloud messaging endpoint (see ).The following diagram illustrates the interaction between the client and the browser via the push endpoint. The client passes a push subscription to the notification backbone, the notification backbone then pushes a notification to the cloud endpoint when a new notification is created for that user.Figure SEQ Figure \* ARABIC 7. Push subscription diagramPrototype walkthroughThe user first sees a login screen.Figure 8. Prototype login screenThen when they sign in, the application bounces them through the OAuth server to get a client token authorizing it to use the central auth API and the notification API (read only) and bounces back to the application, where the angular app receives and stores the OAuth bearer token in memory. The user is then presented with the initial screen, and the angular app calls the Central Auth microservice to get the user details, then the notification microservice to get the user’s current notifications.Figure 9. Homepage, showing notification badge and logged in userThe user can go to the notifications page to see all notifications:Figure 10. Notification screen, showing all notifications and subscription buttonOr the user can click the notification icon to see the latest notifications in the slide-out menu.Figure 11. Slideout menu showing latest notifications.When the user clicks subscribe to push notifications, the angular app registers the push event with the service worker, which causes the browser to ask the user whether they want to receive push notifications.Figure 12. Browser push notification permission popupIf the user accepts, the angular app then receives a callback endpoint, and calls the notification microservice to subscribe the user to receive push notifications via that callback. Then when the microservice saves a new notification, it goes through the list of push subscribers and checks whether it’s relevant to them, and sends a push event to the callback endpoint in the following format.The user sees the notification then as a push event:Figure 13. Push notification on OSX desktopPush notifications will be sent if the browser is running, the user doesn’t have to be visiting the site at the time. The receipt of messages are handled by the service worker, which runs in the background.Finally, as the service worker is caching all the main static content in local storage, when the user is offline (no network access) they can still receive content:Figure 14. Content with network disconnected.If the user has logged in and drops out of network, they can still navigate around the screens with the cached content.Figure 15. Logged in and disconnected.References - AngularJS - An introduction to service workers - The offline cookbook - Building offline first progressive web apps (Jake Archibald) - Cross Origin Resource Sharing definition - Angular JS) - WebKit service worker status - Google Cloud Messaging - Firefox Push API - Edge push notifications ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download