I didn't dig deep in to the docs - just played with the demos - but if all data is exposed as 'just' a URL - what implications are there for security? Can someone mod the JS to grab someone else's data associated with my app? They probably have answers for this, but it wasn't apparent in the demos I looked at.
I don't really get the benefits. You don't need servers, but you need to host the JS/html5 application somewhere, even if you don't need to configure the database server etc.<p>It is nice technology, but I don't really see if it is worth the price (vendor lock-in, technology lock-in, etc.)
This could be incredibly useful for full stack developers that need to do mockups quickly, or have clients that are constantly calling them and asking questions like, "Can you build me something like $data_driven_webapp_dujour".<p>If your client just needs something small, you could host it on Firebase.<p>I also like the possibility of hosting an entire data driven application on Amazon S3 or Rackspace Cloud Files.<p>Looking forward to giving it a try.
From the How It Works page: "Developers include a JavaScript library in their application which gives them access to a shared data structure (your Firebase). Any changes made to that data structure are automatically propagated to all other clients and to the Firebase servers....If a user modifies a piece of data a callback will be triggered on every client allowing it to respond to the change."<p>It sounds like every client gets a full copy of the entire database. You wouldn't exactly want to run reddit on this.<p>Or am I missing something?
The actual Firebase website is at <a href="http://www.firebase.com" rel="nofollow">http://www.firebase.com</a> (there didn't seem to be a link in the article).
How does this work with Meteor? They said it was complimentary. Is there going to be a Firebase Smart Package for Meteor?<p><pre><code> Michael Lehenbauer
11:51 AM
Potentially! Meteor supports a pluggable backend, so we're working on plugging Firebase in as the meteor backend. So you get the client-side help that meteor provides and the sophisticated, scalable backend of Firebase.</code></pre>
Sounds pretty cool and is in line with the trend of app logic moving to the front-end. I'm naturally reticent to put all my data eggs in one vendor's API basket, however (assuming this won't be open sourced). App Engine was supposed to scale too and those who bought into that ran into a lot of problems.
I'd love to see the host-proof scheme that ZeroBin uses, so users can store sensitive data without having to trust Firebase. <a href="http://news.ycombinator.com/item?id=3832269" rel="nofollow">http://news.ycombinator.com/item?id=3832269</a>
So, I've wanted to do a number of things in the iOS / Android space that would require some real time communications and a server. In my quick skim I didn't see a mention of mobile APIs.