Differential Serving on Firebase Hosting (and moving to Medium)

Polymer 2.x/3.x brought the standards-compliant ES6 class-based syntax for defining Web Components. This works well for most modern browsers and ES6 has a lot of other nice features (like arrow functions) to make your JS code cleaner and more fun to write.

But if you need to support older browsers like IE 11 you will have to compile your code to ES5 which comes with performance drawbacks for modern browsers compared to running ES6 on them directly.

The ideal approach is to use differential serving to serve the ES6 version to modern browsers and a fallback ES5 version to older browser. prpl-server-node is a sample implementation of a Node server that uses this pattern. I took the ideas from this implementation and created a sample based on the polymer-starter-kit on how you can use differential serving on Firebase Hosting using Cloud Functions for Firebase for dynamically sending the right version to the user.

Since blogger has started to look quite old I'm currently testing Medium, so you will find the rest of this article there: https://medium.com/@scarygami/differential-serving-on-firebase-hosting-f83c33b83a8e

Polymer in Production / Part 2 - Building, bundling, lazy-loading

Continuing from my previous blog post about including web components and Polymer in a huge legacy web application, I want to focus on optimizing the performance of your web app using the Polymer CLI and at least the L part of the PRPL pattern in this post. There are several things you can do to improve the initial load time, even if your app doesn't follow the recommended app shell architecture.

Doing more with your Google Location History

With the discontinuation of the Google Latitude API several years ago some nice third party tools to visualize your location history disappeared, which at that time triggered me to look into what can be done with Google Takeout data. The result was the location_history_json_converter (or latitude_json_converter as it was called back then) which thanks to several contributions from the open source community has turned out to be a rather useful and powerful tool to prepare your takeout data for further manipulation and visualization.
Since I've recently used the tool myself again for a travel report (more about this below) and I never actively promoted or explained the tool, I've decided to put together this blog post to tell you about the tool and some samples of what can be done with it.

Polymer in Production

When I was tasked with including new functionality into an existing, rather big internal web application, I found myself in a bit of a dilemma.

For my own personal projects and several other internal projects I did at work, I have grown to love web-components using Polymer because of the ease of development and the natural way to structure applications into (re-usable) parts.

The existing web application in question had been mainly developed with a once (and still) very popular JavaScript library.

A full rewrite of the application was out of question due to time and budget restraints, but using Polymer would have a lot of benefits for the future as far as testability, maintainability and extensibility are concerned.

In this blog post I will go over some of the things I did and had to consider to make this work.

Polymer on Blogger

I've had some fun over the past few weeks to force Polymer to work on Blogger, or rather to force Blogger to work with Polymer, and here are my results, some of which might be more useful than others.

A quick disclaimer before we get started:
This post definitely falls more into the "because I can" category than in the "because you should" category, and would need some extensive testing and tweaking before being used out in the wild.

Preparing for Polymer 1.0 - hangout-app

It must have been shortly after the Chrome Dev Summit in 2013 that I first started looking into Polymer. A lot has changed since then and most of the code I had written for the early versions of Polymer looks completely different now and went through a lot of re-write stages, but that's what you get for living on the bleeding edge ☺

Now Polymer has reached beta state with the 0.9 release and 1.0 is expected to come out at I/O so the time of breaking changes is slowly coming to an end. Some of my projects will probably forever remain like they are now, but I thought it was about time to start updating some of my more important (imho) elements, starting with my <hangout-app> element, that makes developing Hangout Apps easier.

While migration is generally easy thanks to migration guide there are still some things I've stumbled over (mostly because I flipped through the migration guide too quickly...)

No inheritance from custom elements (for now)

When I first created this element I had the idea (which seemed brilliant and completely logical at the time) to let people inherit from the hangout-app element to create their own hangout apps, so they could depend on the loaded property of the parent element to know when the Hangouts API is ready to be used:

With inheritance from custom elements not being supported (for now) I had to rethink this idea and I think the new solution is actually much clearer. You can now include the hangout-app element anywhere in your project and either wait for its ready event to fire or bind to its loaded property. Alternatively you can also include any of your markup as content of the hangout-app element and this content won't be rendered until the Hangouts API is ready to be used.

Conditional templates

The old <template if="{{condition}}">...</template> implementation removed/added DOM elements completely when the condition changed, which could have a negative effect on performance if used excessively, and I have to admit that I used it way too much in my projects, simply because it was easy to use and made the code somewhat clearer.

As I wrote a while ago the much better solution in most cases is to simply hide/show by conditional attribute binding to the hidden attribute: <div hidden$="[[!condition]]">...</div>

In the case of the hangout-app element I wanted to make sure that none of the content that might depend on the Hangouts API is part of the DOM until the API is ready, e.g. when using the hangout-shared-state element which tries to called the Hangouts API as soon as it is attached. For that reason I used the new implementation of conditional templates in the form of dom-if.

<template is="dom-if" if="[[loaded]]">
  <content></content>
</template>

This new implementation by default adds the content the first time the condition becomes true and afterwards only shows/hides the elements as necessary.

Layout attributes > Layout classes

I completely missed this part of the migration guide and was very surprised when my layout didn't look the way I expected it to.

The change from attributes to classes is easy enough though, just make sure to include PolymerElements/iron-flex-layout in your dependencies.


That's it for now, more coming as I upgrade more of my elements ☺

Google Sign-In 2.0 - Server-side

There have been a couple of questions lately about server-side access when using the new Google Sign-In functionalities, so I've put together this article to cover some possible use-cases.

User verification

Probably the simplest case is when you only want to verify on the server-side who the currently signed-in user is, e.g. to load user-specific data/settings for them. For this you can use the most basic sign-in implementation, securely send the ID token to the server and use one of the Google API Client Libraries to verify the token and get user information from it.


On the client side you wait for the sign-in success event to trigger, get the id_token from the authenticated user and send it to your server. You should always send the id_token via HTTPS for security reasons. On the server side (in this case using Python with Flask) you use the Google API Client library to verify the id_token and then use the information you get in what ever way you need. Please note that in this case you won't be able to make calls to Google APIs on behalf of the user. Here's the information you can get about the user from the id_token: I would highly recommend to read this article about ID-Tokens.

Optional server-side offline access

If you offer a web-service that will do something on behalf of the user while they are not online, I would recommend to make this an opt-in service after the user has signed-in.

E.g. if your service offers sending news to a user via the Google Glass Mirror API, they could sign-in to your website first, pick the news categories they are interested in and then "flip a switch" to enable "offline access".

For this you would have the normal basic sign-in flow on the client-side. You can then use the ID token as before to check if the user already has offline access authorized (i.e. you have credentials stored for their user ID already). If there is no offline access yet you can display an extra button to go through the grantOfflineAccess flow to get a one-time code which can be exchanged for access and refresh tokens on the server side. On the server-side you can then use the client-library to exchange the code for credentials that can be stored to act on behalf of the user at any point. grantOfflineAccess will always cause a pop-up to show for the user requesting offline access. This is the only way to get a refresh token, also in case you lost a previous one.

Necessary server-side offline access

If your service won't work without offline access (would be curious to hear your use-cases here) and you don't want your users to go through two sign-in steps, things get a little bit more difficult on the client-side (while you can still use the same server.py as above). You can't use the default sign-in button for this, since this flow always runs without granting offline access. Instead you have to use your own custom button (make sure to create it following the branding guidlines) which calls grantOfflineAccess.

For "old" users that come to your website again calls gapi.auth2.init will initalize an immediate sign-in flow which you can catch with the isSignedIn listener to check for existing credentials as before (just in case you lost them). For "new" users the grantOfflineAccess flow will return a code which you can exchange as above, and at the same time authenticate the user on the client side as well (calling your isSignedIn listener).

I hope this answers some of the questions you have, feel free to comment if you have more :)