Part of the project goal was to explore Firebase. From what I see right now:

• Firebase auth looks bolted on. I understand the main point is having different login systems (google, email, etc.) and the Firebase server generates a unique user id for new users, trying to regroup them across login system (e.g. email vs google account.)
• The pro is having a single user id regardless of the authentication method.
• The obvious cons is the secondary server authentication lookup to convert the googler user id into a firebase user id.
• Pros: not having to implement it using my own app engine instance + db.
• The "realtime" database seems to work as promised. However:
• User compartmentalization is done at the app level and by server-side rules. It seems fragile in the sense that a programming error or a design flaw could possibly expose all data to all users.
• All user data is visible as-is in the console, with a limit of 500 users or similar. Search can be done by user id. That seems like a potential PII issue and at the same time not sure how much it can really scale. What happens with 1 million users?
• How much "realtime" is the database? I wasn't even able to sign-in on a low cell phone connection (vacation).
• Pros: not having to implement it using my own app engine instance + db.
• I did not try "remote app settings". That seems like a generalization of the realtime db readable by all apps. Maybe that's the point and just enough.
• I implemented the firebase analytics but I can't see the results yet, the console is quite unresponsive over a low cell connection.
• I don't see anything obvious that is an advantage over pulling google analytics, except it's one less library and in theory it's tied to firebase user ids.

Overall I'll have to defer to see how this behaves with a better connection.

I do have my concern with the speed of the firebase requests.

The other thing not so clear is how does that scale.

Overall I guess the point of Firebase is having to avoid implementing an extra app-engine backend server. If it were used in an application that requires such a service, then the point seems rather moot.

For example I started a project with the idea of having both Firebase and App Engine. I thought I needed app engine for the storage of users ACLs, themes, and live instances but I see these could be replicated in the Firebase realtime db using denormalized storage & rules. The other reason I wanted app engine was to have all the processing on the server and the web site to be merely a "dump" presenter (using the MVP distributed pattern) .

Using Firebase, it makes more sense to have all the logic client side, with only storage on the server side.

⇒ It turned out to be disappointing. One issue is the login time on the Android app. It takes several seconds (10-20 s?) for the app to authenticate via google auth then via firebase before it can do any queries.

What I have at home is an RPi monitoring some status. The interesting properties of Firebase in this case are receiving notifications (aka GCM) and the use of the distributed "realtime" database. The question is how do the events get generated. Can a script running on the RPi send data to Firebase?

• "Firebase Notifications" are sent solely using the Firebase console web UI. Not adequate.
• "Firebase Messages" can be generated via an HTTP POST with an OAuth token; however this requires getting the registration tokens for each device that should receive, which doesn't seem practical.
• "Firebase Database" is a synchronized JSON store. There are many REST wrappers (Go, Python, or just curl) that seem appropriate for the RPi to generate data. Authentication rules are set in the database console. See https://firebase.google.com/docs/database/rest/start 

Interesting: Material Design Lite. https://getmdl.io/

Application could be interesting on the Trains pages. Find a way to inject in the gdoc-generated pages. [done]

Looking at the firebase tutorials for web / android…

Web:

• Uses nodes.js / npm for local testing + deployment.
• Google Cloud Whatever project with console for management.
• Firebase console seems to mostly cover deployment & database/files for web, not messaging or analytics. GA can be added separately anyway.
• Pros: authentication with a variety of platforms (G, Tw, FB, email).
• Overall interesting.

Android:

• Seems more refined with a variety of services: database, email app invite, GCM notifications, remote config values, analytics / crash reporting. And of course multiple auth providers. Also as admob support.
• Seems like a good value: reduce boilerplate for a bunch of things (auth, crash, ga, db, remote config.)
• Nothing about IAB, to be done separately.

From the Firebase tutorial, a good javascript ide is https://atom.io

• open source, free, runs js.
• using http://electron.atom.io to build "cross platforms apps using html+js"

Javascript not-quite-replacements:

• CoffeeScript: http://coffeescript.org … compiles 1-to-1 to vanilla JS.
• TypeScript: https://www.typescriptlang.org … also a compiler. More JS like, with decoration for types and access.
• - ES6: ...
• The high level summary is that CoffeeScript is Ruby/Python like and TypeScript is .Net like in their sugar-syntax addition/replacement.
• TypeScript seems to have a VS.Net add-on (confirm?)
• In terms of age: CoffeeScript < TypeScript < ES6.

Point of view: CoffeeScript is different enough that it's a new habit to learn. TypeScript is JS plus some sugar so can be used to decorate existing JS stuff. ES6 is the way to go but what about support? Compatibility chart here: ES6 supported in V8 since Chrome 42 (so also in Node.js). Mostly there in recent Firefox and MS Edge.

Bottom line: don't bother with CS/TS. Go with ES6 where possible.

One more thing to give a try: Firebase.  firebase.google.com.
What does it do, or doesn't? Why would I care?

It's apparently based on top of the google cloud platform. Key features include analytics, database, storage, hosting, authentication, and cloud messaging.

Idea would be to use the central monitoring and the AP projects to test it.

• Authentication: SDK has drop-in UI for auth, with several providers (G, FB, Twitter, email).
• "Realtime Database" is actually connected clients with a network-synchronized offline-persistent db. This is similar to one of my homebrew projects (except it's already done.)
• "Remote Config" seems very similar, but with values that can be fetched yet not activated.
• "Storage" is to be able to upload user-generated content. Files are accessible via the Google Cloud Platform SDK too e.g. for server-side operations.
• "Notifications" seems to be all about manually sending messages to users.

⇒ Try the web tutorial.

https://www.polymer-project.org/0.5/
Version 0.5 with core-scaffold (generic web site template), core-toolbar.

https://www.polymer-project.org/1.0/ 
With material design elements.

"Look at https://github.com/PolymerElements/app-layout-templates for a few simple scaffolds.

You should be able to copy one of those templates to replace core-scaffold in your application.

If you want a more comprehensive starting point for an app, you can also look at https://github.com/PolymerElements/polymer-starter-kit"

Example in use: http://google.github.io/dagger/ 
Code behind it: https://github.com/google/dagger/tree/gh-pages 

Also interesting: Material Design Lite. https://getmdl.io/ 

What should the next "new" project be?

Would be nice to have something with a server side component in Go and an Android part..

• A Go-based AppEngine server.
• Use Google/Android user authentication.
• A client/server MVP model (as much logic server side as possible.)
• Lua scripting for the gameplay.
• Short-range NFC exchange.

Note about JS stacks:

• Angular -- v1 vs v2
• ReactJS -- the cool new thing?
• this comparison and this one for a comparison with pros and cons. Seems to indicate to go with ReactJS.
• My take: looking at the source code being their respective home pages, the Angular one is impossible to read, the ReactJS is simple and natural. Go with the latter.

So there's the usual MVP -- Model / View / Presenter pattern, exploded in a distributed fashion. A server sends data, and the client has a bunch of presenters for that data. That makes the client somewhat "generic" in the sense that it just presents whatever data it is given.

MVP : model → presenter → view.

The view is "dumb" and only displays stuff. It's a ViewHolder essentially.

Model has all the data and no logic.

All the logic is in the presenter. The presenter is notified of view changes and updates the model and the views.

For a distributed server-client system, we want all the logic server side.

So really what we have is:

        Server model → server presenter (logic) → client proto → view renderer.

where proto is naturally a Cap'n Proto for example.

The difference between MVP and MVC: in MVC, the model has part of the logic (it dictates what gets sent to the View) and the Controller accepts the input and updates the model. In MVP, the view and the model are dumb, and the presenter embeds both the logic to go from M-to-V and the logic from the Controller (to go from V to M.)

Thinking ahead in terms of a game. Interaction cannot only be handled server side. Otherwise it would mean every user action would have a huge network delay impact. That prevents offline usage at best, and of course implies lag, at worse.

That means part of the model/presenter needs to be on the client:

        [Server + Client model] → server presenter → | → [Client model] → [presenter] → View.

The client presenter handles the immediate interaction and at the same time pushes back some updates to the server.

For offline play, that's all we need. For live server-backed play, that has 2 frequent issues:

Server needs to sanitize / validate inputs from the client. They cannot be trusted. Otherwise it encourages cheating by simple MITM techniques.

Server pushes updates to client regularly which are more trusted than local updates. That can create magical warping when there's a lag.

https://capnproto.org/ 

This seems like it could be a good match for Nodes and potentially other projects.
One obvious goal is cross-platform serialization without having to reinvent it myself.

For Nodes it could be used at the inter-nodes layer, to structure packets between nodes.
Nodes server should not care about their payload, with the exception that ideally as a service nodes should provide both a byte stream and a packet/message oriented stream.