Can someone explain this: is there any way to have a secure app with only HTML JS and no back end at all? I assume you must at least have something on the server to add your secret key, right? Or is there some magic way to ensure no one else is writing or reading to/from your Firebase acount. I'm sure it's documented, but if it does, it's not that clear to me, seems there has to be at least one small server layer for you to make it really work, did I miss something?.
You can check out the rules for Firefeed here: https://github.com/firebase/firefeed/blob/master/rules.json
And be sure to check out our Security Quickstart Screencast, walking you through the system: https://www.firebase.com/docs/security-quickstart.html
1) indexing, didn't see any options, I assume it's planned in the future along with more complex query language?
2) self register as a RequireJS / AMD module, is this planned?
Again, this is great. thanks
I'm pretty impressed by the product, looks like it may even be a game changer for doing quick web apps.
[1] https://www.firebase.com/docs/security/security-rules.html
As a side note, I think that firebase is an amazing piece of technology and I can't wait to use it.
[1] https://github.com/firebase/backfire
Update: There's a user-built binding for Ember here: https://github.com/maiah/emberfire
So instead of (Client)->[Your Server]->(All Clients), Firebase replaces your server so you effectively get (Client)->(All Clients).
This means if you wanted to save something you would have to make the (Client)->[Your Server] request separately.
If you want to access the data from your own servers, we recommend actually having your servers talk to Firebase directly. So the data flow becomes (Client) -> (Firebase) -> (Other Clients and your servers)
We provide a Node.js client and a REST API to make this easy.
1tb for $2,000? Wow, breathtaking bandwidth costs. That's at least ten times higher than I would have expected.
It makes Firebase completely unusable for any service that needs scale, unless you've got more money than you know what to do with of course.
Also keep in mind that for most apps, 90%+ of infrastructure costs come from running servers, not bandwidth. So while we may seem more expensive than other services, we eliminate your costs for servers and backups. The only thing you pay is the per-bandwidth/storage price. Also keep in mind that Firebase apps can often use less data per-user than traditional apps, since they push data only when it changes, rather than polling.
The vast majority of the apps on Firebase today will fit nicely in our free plan.
The only rational explanation I can come up with for the high cost is that it's a means of throttling use until you can acquire greater scale.
I've tracked Firebase with great interest since first hearing about it on HN. I'm disappointed by the cost, but I'm willing to give it a try and see how the value proposition ultimately stacks up.
In my use case, bandwidth is the primary cost concern with Firebase, but it's all text data (constantly dumped, so storage requirements are modest).
Firebase is a neat take on what a world of real-time for "free" could be like. If nothing else, I dare you to find a faster experience for prototyping that can subsequently scale into your production app. :) I also know several of the guys there - all of whom I would work with in an instant if I had the chance. The beta is a big step for them, but I can guarantee you even greater things are to come from that team.
Congratulations guys!
Keep killing it guys!
I want to add synchronisation to my lists app (http://human-friendly.com/software) but I'm not sure that there is a solution that always gets it right without nasty user interventions or throwing away data in some scenarios. My fear is continually pushing it down the priority list for development.
The idea seems to be that Firebase is all the server back-end you need. I can see how that could work for many applications.
On the other hand, as applications grow I can also see how you might arrive at a point where you do want to run code on a server. Is it possible to access a Firebase database from the server-end of things?
"PubNub and Pusher are both great services that provide simple real-time messaging for applications with a “publish / subscribe” model. Firebase takes a broader approach and provides real-time updates, data synchronization, and data persistence as one unified service.
This unified approach allows for simpler application development. Developers who build their software with Firebase will automatically handle real-time updates, and their products will work in “off-line mode”, both without any extra work from the developer. More importantly, Firebase can serve as a complete backend for most applications—completely eliminating the need for developers to manage servers and write server code."
First off, the Firebase team is beyond incredible. The dedication they show to their users and their product vision is unparalleled.
Second, the product is awesome. I can barely throw together a static HTML file without help and now with Firebase I've been able to mash together all kinds of neat little interactive WebGL demos.
As I spend more time developing my programming skills I'm happy knowing that Firebase will be there to help me grow.
Awesome release guys! Congrats!
I'm excited to see their product mature.
Are there any other BAAS providers that have something similar?
Any chance of creating Java and .NET clients?
I wish I had thought of it :-)
