Month: June 2020

Oracle have released the core of their Coherence in-memory data grid (IMDG) product as free and open source software.

By Ben Evans

Article originally posted on InfoQ. Visit InfoQ

The book Learning Progressive Web Apps by John M. Wargo explores the benefits and importance of progressive web apps (PWAs) and how developers can leverage PWAs to enhance user experience on multiple devices. The book deals in detail with web manifests and service workers, the latter providing the core capabilities that differentiates PWAs from mere web applications. The book contains plenty of code samples and runs the reader through creating three PWAs, each of which illustrates specific PWA features.

InfoQ readers can download a sample chapter of the book here.

InfoQ interviewed Wargo about the book.

InfoQ: Can you tell our readers about yourself? What drove you to write this book?

John M. Wargo: I’ve been involved with software development for a long time (more than 30 years) and I’ve had many roles as a developer, product manager, consultant, etc.

For the last 15 years or so, I specialized in mobile software development (building apps for mobile phones). I’ve never been a very good native mobile app developer, but as I experimented with different development approaches, I discovered I liked best the approaches that allowed me to leverage my web development skills. I ended up spending many years in the Apache Cordova community and ultimately wrote four books on the topic. The Cordova community always set as its goal making themselves obsolete; saying that when browsers offered most of the capabilities required by mobile applications, then the Cordova project would no longer be needed. Over the years, the browser, and especially the mobile browser, got a lot more capable – delivering native-like capabilities in the browser. With that in place, the last few things needed to make the web a first class citizen on devices are the capabilities provided through service workers and web app manifests – the core capabilities that make a PWA a PWA.

So, essentially, this book is just the natural extension of many of my previous books – the natural progression for the Apache Cordova developer. However, the book also allowed me to target a wider audience since the technologies that make a web app a PWA are very powerful capabilities for any web developer to use to make their web apps more app-like.

InfoQ: Some analysts identify three options for developers targeting handheld devices: native apps, web apps, and PWAs. What distinguishes a PWA from a regular web app? What do they achieve that regular web apps do not? What can native apps achieve that PWAs cannot? What make PWAs progressive?

Wargo: Actually, I used to be an analyst at Forrester Research, and when I was there, I wrote about a lot more options for mobile developers.

The biggest issues for mobile developers are that native mobile development is hard, really hard. Especially when your app must target multiple device platforms (Android and iOS for example) since each platform uses a completely different set of technologies from concept to delivery. Because of this, the market over the years looked for ways to make this easier for developers and companies to deliver mobile apps.

The market (community and software companies) delivered a lot of different approaches for delivering mobile apps. The ones you listed, although I’d argue it should be only native and web apps as a starting point (a PWA is just a web app with some extra code in it, and I’ll explain more later), plus things like JavaScript-driven native (Appcelerator Titanium, React Native, NativeScript, etc.), adjacent native apps (Flutter, Xamarin, etc.), and hybrid apps (Apache Cordova, Adobe PhoneGap, Ionic Capacitor, etc.).

There is even a whole other class of tools available called mobile application development platforms (MADP), which provide special tooling to make it easy for developers (or even non-developers) to build mobile apps using a special design tool that spits out native apps using the technologies listed in the previous paragraph.

All of this is stuff that consumed most of my career for the last 15 years.

PWAs solve a problem most of those other solutions can’t (although MADP does solve many). If you’re building an app, especially a non-enterprise app, that targets mobile users, you’re likely going to build an app the user installs on the device plus a web app customers/users can use when they don’t have the app installed. Web users can bookmark apps on their device, but how many of you ever use bookmarked pages in a mobile browser? I never do. Users can also copy a web app icon to their home page, but, as I show in the book, that’s a subpar user experience.

There are two views on this, but for me PWAs are essentially web apps with some additional capabilities in them that make them act more like native mobile apps.

The use of “progressive” in the name is a shout out to the progressive enhancement approach to web development popularized in the early 2000s. In this context it means that a web app is progressively enhanced based on how much of the technology is supported in the browser. When your PWA runs on an older browser, one that doesn’t support all or any of the PWA capabilities, it works just like any non-PWA. However, when the browser supports the core PWA technologies, additional capabilities unlock in the app depending on what code you have therein.

PWAs allow you to register a chunk of JavaScript code called a service worker (SW) that runs in the browser context (as opposed to the app context). With a SW in place, your web app can do things a normal web app (a non-PWA) can’t. Things like receive push notifications, enable an app to work while offline, even sync updated data with the server in the background when the app isn’t running. SWs, along with a web app manifest file, also enable a more streamlined, app-controlled approach to installing the app on the user’s desktop or home screen.

As I said, PWAs make a web app work more like a native mobile app, but there are still a lot of things native apps can do that web apps just can’t. Over the years, the mobile browser got more and more native capabilities – like the ability to interact with the device compass or accelerometer, file system, geolocation, local storage, etc. – and its the addition of these capabilities that ultimately made Apache Cordova obsolete. Native apps can just do more – true background processing, access local APIs the browser can’t, deal with more on-device events, and more. 

InfoQ: You say in the book that “this is a book about service workers”. What are service workers, how do they relate to PWAs and why did you choose to focus on them?

Wargo: A service worker is a block of code a web app registers with the browser and runs in the browser’s context (until its deactivated). This in-browser context lets the code do things a web app can’t do very well.

It enables web apps to register for, and process, push notifications. It also enables the web app to efficiently cache resources (like HTML, CSS, JavaScript files) so the web app has access to them when the browser loses network connectivity. If the web app updates some data while offline, a SW can queue up the data and deliver it later when the device reconnects to the network. These capabilities are things native mobile apps can do all day, but only work in web apps because of SWs.

I chose to focus on them because they’re core to what makes a PWA a PWA. You can’t have a PWA (although some would argue against this) without a service worker.

InfoQ: The book takes the user through understanding and writing PWAs with three concrete sample web apps. I liked the fact that none of those applications are overly fancy, nor require any framework knowledge. Focus is kept on the PWA side of things rather than the application features or framework particulars. Can you run us quickly through what those applications are and what each application is designed to teach the reader?

Wargo: Yeah, this was a different approach for me. In my earlier mobile development books, I spent all my time talking about the technology, tools, and how to use each API/capability. For this book, I decided to take a more code-based approach – skipping any discussion of tooling (until the very end) and getting as much code in there as possible. I originally planned to focus on a single app, and progressively enhance the app as we progressed together through the chapters. As I started writing, I quickly realized that I could deliver higher impact by splitting the single, monolithic app into smaller parts.

Thank you too for noticing that the apps are deliberately focused on core technologies (HTML, JavaScript, and CSS, which I never talk about). I didn’t want to obscure the core content by implementing the framework of the day, or a lot of tight but confusing JavaScript code. I made the examples as simple and as clear as I could, and I think readers really benefit from that.

Most PWA books and articles cover app installation at the end of the content, digging deep into service workers before finally getting around to how to use them to install the app on the user’s device. Since I wanted to go deep into service workers, I decided to get installation out of the way early, and I needed a very simple single-page app to use for this purpose. So I quickly coded up a small, simple tip calculator app and my friend Scott Good made it beautiful with some artful application of CSS. In the book, I use the app to illustrate how to write the code to manage the installation process. Since the app is so small, and has very little JavaScript code in it, it’s really easy to see the code I want you to see as you’re working through the chapter.

The app’s online today, so you can see it in action as you compare what I have against your code as you work through the chapter. The app is available online.

The second app is the PWA News site located here. The chapters that use this app cover resource caching and caching strategies, so I needed an app that had lots of files and data to cache. For this, Scott and I created a simple news site that pulls PWA articles from the Internet using the free Bing Web Search API – the app works while online or offline, demonstrating the core capabilities of service workers. I also use the Feedback area of this app/site to demonstrate how to use the background sync capabilities of PWAs to upload data to a server when a device comes back into network coverage.

For the last app, I needed something to demonstrate how to register for and process browser notifications (push notifications). I originally planned on adding some lame register for notifications option to the PWA News site. As I started thinking through it, I realized that approach was too contrived, that nobody would ever want to receive notifications from my news site and I didn’t want to pay for the server processing to manage it. Instead, I decided to create a simple two-part app that cleanly and simply demonstrates everything you need to know about how to register for, send, and process browser notifications. It’s a clean, simple, and concise way to show just the code you need here and nothing else.

I also discovered that this last sample app was the perfect app to use to demonstrate how to send messages between a web app and a service worker. In the book, I demonstrate how to make a change in one browser window and use a service worker to update all other windows running the same app. It’s an amazing demo.

InfoQ: Chapter 1 traces the origin of PWAs back to the iPhone and developers lobbying Apple for more power than that offered by just the browser. The book tells the story with interesting details that I discovered for the first time and enjoyed reading. The chapter also explains the growing market share of PWAs and the existing options to package them for distribution on the same application stores as native apps.

Chapter 2 deals with web app manifests and explains how they are a necessary but insufficient part of the cocktail that enables offline installation. The reader will get acquainted with the criteria used by a browser to decide whether an app is installable and the properties in the manifest file that define what the app looks like when it’s installed, runs, and more. The reader will get important tips for troubleshooting and tooling. The reader will also install the first of the three PWAs used in the book: the tip calculator. Did I forget anything?

Wargo: No, not really – I think you captured it. In Chapter 1 though, I make the case that Apple failed dramatically to understand what developers wanted. Even today, Apple lags far, far behind other browsers and OSes in support for PWAs.

InfoQ: In Chapter 3 to Chapter 7, you introduce in earnest SWs and their use cases. You use two PWAs to showcase service workers: the PWA News, available online, is used in Chapter 3 to Chapter 5 and a third PWA serves to showcase push notifications and communications between the service worker and the application core. The aforementioned five5 chapters are the main part of the book. What will the reader be able to do with SWservice workers after completing these chapters?

Wargo: You’re right, those chapters are the core and they really contain everything I think you need to know to build your own PWAs. Developers who understand SWService Workers and everything they can do will be able tocan do amazing things in their web apps.

InfoQ: The last two chaptersThe chapters 8 and 9 conclude the book and deal with the assessment, automation, and deployment of PWAs. WTalking about the future, what is the outlook for PWAProgressive Web Applications? What challenges remain to be overcome? Distribution? Platform differences? Native APIs not available in the browser? Performance? Business model?

Wargo: Aaah, yes! Those are very important questions.

I deliberately moved the tooling chapters to the end of the book since I write my books in chapter order and I knew the tooling would change and I wanted the most up- to- date information in the book. Google ha’s enhanced their PWA installation UI and releaseds the BubbleWrap CLI, which enables Android developers to more easily package a PWA into a Trusted Web Activity (TWA). Microsoft’s PWA Builder started work on a PWA Starter project making it easier for developers to get started coding PWAs.

As I mentioned in the book, aAnalyst firm Gartner predicted a while back that 50% of consumer-facing apps would be PWAs this year. We’re almost halfway through the year and I’m seeing evidence of this. For example, Microsoft (my employer, although I’m moving to GitHub July 1st) released PWA versions of OneDrive and Outlook. Those are BIG apps, built by big teams. That should easily solidify anyone’s view that PWAs are useful, stable, and capable of doing both big and small things.

This isn’t edge or rising technology, it’s here now.

The future looks like this: Google and most of the other browser vendors will continue to innovate and add new, native-like capabilities in their browsers. Count on it and get onboard now. Apple will continue to lag in their support for PWAs; mostly, I think, because they don’t like others telling them what to do.

Tooling will continue to improve, making it easier and easier to turn web apps into PWAs. I don’t see that slowing down for a while.

Challenges? It’s so easy to progressively enhance your web apps to make a PWA that you should just do it. On non-capable browsers, nothing changes – so your users won’t know the difference. The biggest challenge I see is that support for PWAs on iOS and macOS is dismal. Apple even recently changed the way it manages local storage in a way that could impact PWA users negatively. I’d like to see them get onboard, it will make the world a better place.

Readers may find all of the source code for the sample apps on GitHub. Book readers also have additional online resources available.

About the Book Author

John Wargo is a professional software developer, writer, presenter, father, husband, and geek. He’s been writing code and teaching others for more than 30 years. For the last 15 years, he’s focused on building web and mobile apps. He’s an author of six books on mobile development, including four on PhoneGap/Apache Cordova, and has been a contributor to the open-source Apache Cordova project. He loves writing code and building hardware projects based on Arduino, Particle Photon, Raspberry Pi, and more. He’s currently a product manager at GitHub.

During this year’s digital Build conference, Microsoft announced several new incremental updates to its private and hybrid computing offering Azure Stack Hub. The public cloud vendor will add various significant features on Azure Stack Hub in private previews such as an Azure Kubernetes Service (AKS) Resource Provider, and Fleet Management.

Azure Stack Hub formerly known as Azure Stack is one of Microsoft’s hybrid cloud offerings and is an extension of the Azure platform. It allows customers to run apps in an on-premises environment and deliver Azure services in their datacenter. Currently, the company is further enhancing the capabilities of the service, such as container support, and improvements in management, operations and hardware.

Source: https://docs.microsoft.com/en-us/azure-stack/operator/compare-azure-azure-stack

With the AKS resource provider, customers can easily create and manage Kubernetes clusters on Azure Stack Hub. It is the same resource provider that allows deployment and management of Kubernetes clusters in Azure and offers the same user experience, CLI and APIs. Next to the resource provider, Microsoft also brings Azure Container Registry (ACR) capability to create secure, private container registries on Azure Stack Hub in private preview.

Dino Bordonaro, Microsoft Azure MVP, said in a tweet:

My customer Knowledgepark brought their first Microservice on #K8s as well as #Docker to #AzureStackHub. With the medical #FHIR messaging standard, they bring FHIR as a Service to hospitals and clinics. Lift, Shift and then Transform.

One of the other new features in private preview with regards to management and operations improvements is fleet management, which will provide customers with a single view and management method for all their Azure and Azure Stack Hub deployments. Moreover, administrators will have a single pane of glass to view alerts and take actions such as rolling out software updates across their Azure Stack Hub fleet directly from a central location in the cloud. Furthermore, ManagedIQ, formerly known as CloudForms for Azure Stack Hub, is now in a public preview – and allows customers a way to manage their resources on Azure Stack Hub using the RedHat technical tooling.

Kenny Lowe, Azure MVP and Senior Principal Azure Stack Specialist EMEA at Dell told InfoQ:

Some of the announcements for Azure Stack Hub at Build are incremental and necessary core additions or enhancements – for example, Fleet Management, the ability to manage and monitor multiple Azure Stack Hub environments from a single interface. Other announcements, in particular AKS on Azure Stack Hub, have a more profound impact on the product, how customers will use it, and even more importantly, how Microsoft can leverage it to deliver value to customers. 

And he continues:

Having AKS as a fully managed PaaS offering on Azure Stack Hub delivers a lot more than just the ability for customers to run their container workloads on it in an Azure consistent way. In my opinion, it now provides the foundational platform that Microsoft can now use to bring more PaaS offerings to Azure Stack Hub, and significantly accelerates the time to value not just for customers running their workloads, but for Microsoft to deliver new value to Azure Stack Hub customers. The power of a fully managed Azure consistent Kubernetes environment coupled with the power of Azure Resource Manager, all running on-premises, is super exciting to be able to leverage. 

As Azure Stack Hub stands today, it hasn’t onboarded all of the Azure platform capabilities. Rik Hepworth, CCO at Black Marble and Microsoft Azure MVP, shares his experience on that with InfoQ: 

We are engaged in an Azure Stack project which really would have been too complex to deliver without it. The shared development model with Azure meant that we needed no time to upskill and could deliver value for our customers immediately. One thing to bear in mind though when embarking on hybrid projects is that Azure Stack lags behind public Azure in terms of API and SDK support.

Lastly, Azure Stack Hub together with other Microsoft hybrid cloud offerings Azure Arc and Azure Stack Edge form the companies Hybrid 2.0 strategy, which was laid out during Ignite November 2019. It’s the public cloud vendor’s answer to competitive offerings from Amazon such as AWS Outpost and Google’s Anthos.

Lowe told InfoQ with regards to the Hybrid Cloud solutions in the market:

It’s interesting to look at this space because in many ways Microsoft has led this market. Azure Stack Hub has been GA and in the market for almost three years now, while its direct competitors have been out for much longer, and are not as mature in either operations or capabilities. Most critically, with both Anthos and Outposts, the control plane still resides in Google Cloud and AWS respectively, while in Azure Stack Hub it resides inside the Hub itself. This enables a raft of hybrid capabilities not otherwise possible, for example fully disconnected or air-gapped solutions, which we see a large uptake in for Azure Stack Hub. 

And also, Lowe states:

This is still an emerging and maturing market, and each of the big three continue to push and nip at each other’s heels, and we’ll continue to see new hybrid capabilities launched from each, which can only be a good thing for customers. The hybrid space is a really exciting place to work in in the IT industry just now, and the arms race to hybrid supremacy is really still in its infancy. Azure Stack Hub has provided Microsoft a solid foundation to build on and around, and it’s always exciting to see what new scenarios and capabilities get lit up for our customers as it and its hybrid family continue to evolve.