As my Ember chat started to grow, I became more and more unsatisfied
about how and where the application state was mutated inside the
app. Changes happened not just in different levels on the component
hierarchy but also inside the controllers. Additionally, there were
chains of mutations that were hard to debug.

For a long time I felt that for an app that doesn't use Ember data, a
systematic pattern to follow was missing. Ember 2.0 recommends the
data down actions up approach. I initially tried to implement that the
best I could but found two issues.

Passport is a popular
authentication middleware for Node.js. It has a plug-in system which
supports more or less all popular authentication services. For Google
it has
passport-google and
passport-google-oauth
plug-ins. Passport-google is OpenID 2.0 based and
passport-google-oauth is OAuth 2.0 based.

Google has
announced
that it terminates OpenID 2.0 support in 2015. If you are like me, you
have for a long time offered your users a possibility to sign-up with their Google
account using OpenID 2.0 behind the scenes. And are now forced to
upgrade to OAuth 2.0.

There are two ways to handle the upgrade without losing track of user
identities. The first, simple way is just to switch to OAuth 2.0 and
ask user's primary email address from Google as part of the OAuth
authentication transaction. You can then search the user from your
database using the received email address. For me this doesn't work as
my service allows users to change their email addresses. I'm not
forcing that they must use their primary Google email addresses. The
only thing I really know about them is their OpenID id, e.g.

If you are a mobile developer who would like to use web technologies
wherever possible, you probably want to find out whether
UIWebView
in iOS7 finally supports WebGL and includes WebKit Nitro JavaScript
engine. I tested exactly that today. The short answer is a disappointing no to
both questions.