PWAs are websites

I recently saw this article in SD Times by Frank J. Ohlhorst which was describing the PWA approach to a new audience. Whilst I'm glad that Frank wrote the article I felt it had a few significant technical inaccuracies or misunderstandings.

It initially starts strong with lots of elements taken from Alex Russell's original blog post. The author then correctly points out that Alex's post didn't tell people about the app shell model or explain service workers. Then he makes a few errors.

Firstly PWAs don't work like websites, they are websites.

As a result they don't require frameworks. Here's the code to a PWA: https://github.com/GoogleChrome/gulliver that was built without using a framework. And this is Huffduffer. It's one of my favourite PWAs. It also doesn't use any frameworks. That doesn't mean I think frameworks are bad. Just that whilst frameworks and libraries can help with building great web experiences (like my favourite interface to Hacker News) they're not essential.

Another misunderstanding is the claim that PWAs can't support single-sign-on and cross-application logins because "PWAs are unable to independently collect and store that login information." This is incorrect. PWAs like Google+ already support single-sign-on. Try visiting it in an incognito window, signing-in then visiting another Google property. You'll stay signed in. This is possible because PWAs are just websites.

Another misunderstanding is the idea that PWAs lack hardware support. PWAs are only limited to the hardware features that browsers can access on each platform. Since browsers are just native apps like any other the true constraints are in the APIs they choose to expose to web sites. That means cameras are supported and so is GPS and so are biometrics. You can try the latter in Stripe's Apple Pay demo.

There are certainly caveats that should be applied. For instance many of the web APIs for hardware aren't standardised or aren't available in all mainstream modern browsers or aren't as good as the equivalent native APIs. Many of them also don't iterate as fast as the equivalent native APIs. At the same large numbers of people use these capabilities every day in web apps like Facebook, Instagram and Google Maps.

Finally there's a misunderstanding of Safari's support for PWAs. It's true that Safari currently doesn't support Service Workers or web app manifests or push notifications but that misses the point of PWAs. The P stands for progressive as in progressive enhancement. That means that a good PWA will still be a good experience on Safari but will be progressively enhanced to be a better experience on browsers that have more features.

I'm biased since my team at Google built it but I think that a great resource for looking at hundreds of examples of PWAs is our PWA Directory. I would also suggest that people take a look at our PWA Checklist and my colleague Owen Campbell-Moore's Google I/O 2017 talk to get some tips on how to build a great PWA.

Awkward questions for those boarding the microservices bandwagon

Why isn't this a library?
What heuristics do you use to decide when to build (or extract) a service versus building (or extracting) a library?

How do you plan to deploy your microservices?
What is your deployable unit?
Will you be deploying each microservice in isolation or deploying the set of microservices needed to implement some business functionality?
Are you capable of deploying different instances (where an instance may represent multiple processes on multiple machines) of the same microservice with different configurations?

Is it acceptable for another team to take your code and spin up another instance of your microservice?
Can team A use team B's microservice or are they only used within rather than between teams?
Do you have consumer contacts for your microservices or is it the consumer's responsibility to keep up with the changes to your API?

Is each microservice a snowflake or are there common conventions?
How are these conventions enforced?
How are these conventions documented?
What's involved in supporting these conventions?
Are there common libraries that help with supporting these conventions?

How do you plan to monitor your microservices?
How do you plan to trace the interactions between different microservices in a production environment?

What constitutes a production-ready microservice in your environment?
What does the smallest possible deployable microservice look like in your environment?

Why do we bother with APIs?

Sometimes people wonder why we bother building APIs since it seems they can end up being used in ways that compete with our own products.

There are idealistic reasons for building APIs, as outlined by Jonathan Rosenberg, but there are also commercial benefits even if you don't share that philosophy. The main one is that APIs reduce the friction involved in making your services more valuable. They make it easier for other people to add data to your services. 

They also attract more users to your services by effectively advertising them on other people's sites. As well as increasing your visibility APIs also ensure that users are more likely to try your services since the risk of lock-in is reduced. If you have at least a CRUD API potential users know that there will be a  mechanism for extracting their data if something better comes along or if your services change in ways they don't like.

The other benefit of APIs is that they lower the cost of experimentation and increase the set of potential experimenters. These experiments can serve your users in two ways. Firstly they can handle niche use cases without cluttering the user interface of the application. Secondly some of these niche use cases may turn out, after a period of refinement, to be useful for mainstream users or for attracting completely new sets of users.

Another thing we've learned the hard way is that if you don't give people an API or you give them an insufficient API they'll resort to screen-scraping and hacking in order to unlock the value in your product. This can create dependencies on things that were never meant to be stable or it can lead to the emergence of widely-used but unofficial APIs. 

That behaviour can harm your product, your developers and your users. For example it can lead to a mismatch in expectations when some developers believe they're using an official API with established deprecation and change management policies. You also have to ensure that the APIs you create don't damage the product, for instance, by making it very easy to spam or game your system.

Providing an API, no matter how good, is just the start. The next challenge is to make something valuable enough that developers will use it in the absence of some extrinsic compulsion.

Firstly this involves making something that's easy to experiment with. So it should be easy to copy-paste a personalised URL into a browser and see a pretty-printed dataset.

Then you have to offer a path from there. The path starts with letting people play even if they don't understand your service all the way to the point where they understand your abstractions and the specifications you're using.

People should be able to go from playing in the browser to playing at a terminal with curl/wget to playing with an OAuth-enabled HTTP client to playing with your specialized wrapper libraries for your API to building businesses upon your platform.

But you can't just stop there. If you want to go from merely offering an API (typically a set of CRUD operations on your product's datasets) to building a viable platform you need to solve some difficult problems:

• how does your platform, as opposed to your product, generate revenue or value for you?
• how does your platform generate revenue or value for those who build upon it?
• how do you respond to and/or incorporate the innovations that will be built upon your platform?
• how do you nudge developers into creating more value than they capture from your users and your platform?
• what happens to this surplus value? Is it being re-invested in the platform or siphoned off?

Even if you solve all these problems you don't have any guarantees of long-term success. The transition from API to platform to ecosystem is difficult and most APIs don't make it. However APIs can still help developers create new possibilities along the way.

The Google+ Sharelink Endpoint: doing it right

If your site has a Google+ sharing feature that uses this URL: https://plusone.google.com/_/+1/confirm?url= then you're doing it wrong. You're using unsupported and undocumented functionality. Don't.

You should be using a sharing URL that looks like this: https://plus.google.com/share?url=

That's our official sharelink endpoint. It is supported, monitored and maintained. The URL you're using right now is an internal part of our +1 button's Javascript API so it's subject to change because we don't expect anyone else to be depending on it.

The documentation for the sharelink endpoint is here: https://developers.google.com/+/plugins/share/#sharelink-endpoint It even offers a set of standard graphics that you should be using for consistency with the rest of the web.

In short: don't be like the guy in the photo below.