If a developer builds a Javascript web app without any servers, how do you know what to charge them for bandwidth? The developer cannot store auth tokens in the client code because anyone could see it. If someone steals the auth tokens, then they can spoof the developer and the developer ends up being overcharged. Or am I missing something?
The original commenter is correct -- this is intended to run fully-client-side.
We provide a set of security rules and authentication that allow you to control access. Authentication tokens should always be generated on a trusted servers, either ours (in the case of Firebase Simple Login), or yours if you want to generate custom tokens, or a third party service like Singly.
Our billing structure is very similar to a CDN, where you are being charged for actual usage on a multi-tenant architecture.
Okay, but that does not answer my question. How would I protect my auth tokens in plain-text, client-side Javascript code without an auth server? Do you provide such an auth server? I only see end-user login which is pretty cool, but usually there are portions of a website which can be seen without the end-user being logged in. In the scenario where the end-user is not logged in, how do you correctly calculate my bandwidth and charge appropriately while still protecting my auth tokens if there is no auth server? Who generates the auth tokens is not relevant to my question.
I'm excited to try this out next time I start a new project. the allure to only having to write a backbone app and no server is pretty interesting to me.
It's not the stability of the node.js code itself that was the issue -- it was the stability of the protocol used to communicate with our servers. We didn't want to put it in the NPM before we were ready to support that version of the protocol going forward (once it's live on our devs servers, it could be there a very long time).
The wire protocol is solid now, so we're making the commitment to be backwards compatible from this point onwards.
