I've been following this team, and the product, since pre-launch. They've made a great product by listening and being really responsive to users and building what we, developers, want.
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.
I said this last time Firebase was on HN, but I'm more than happy to say it again: if you're doing anything with real-time, you owe it to yourself to give Firebase a shot. We've been using Firebase for 8 or 9 months now, and I can't being to count how much time it's saved us, allowing us to focus on what makes our app unique rather than scaling a real-time communication server of our own.
Having built a bunch of real-time infrastructure before, I'm glad that there is now a better option than hundreds of hours of blood, sweat, and tears. (lots and lots of tears)
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.
If you want to write code instead of back ends, this is the tool for you. Don't waste a minute dealing with servers and databases and real-time technologies. Just get Firebase and build your product.
Semantics. Back ends are coded; it's just boring code. In any case, I can see this being useless for a lot of commercial projects if there is is no way to avoid data travelling outside your network. Or at least, that might make businesses apprehensive about using it.
You are being sarcastic right? There are some incredibly complex systems out there where a huge part of the business logic is handled by these boring "servers and databases and real-time technologies" and where it would be inconceivable to try to offload this work to the client/browser. If you really serious, then you are also extremely naive. If you're just building an online collaborative text editor, then yeah, you can safely do away with this boring backend stuff.
As a side note, I think that firebase is an amazing piece of technology and I can't wait to use it.
I think it would be helpful to explain how this compares to using Pubnub, Pusher, SignalR, etc for real time communication? What additional features does this have, etc
[Firebase founder here] We talk about this briefly in our FAQ [1]. Here's the quote:
"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."
There may be a bug in the signup process for those who were on the mailing list. I went to signup for an account, it said I had already registered, so I went to login, couldn't figure out my password, clicked forgot password, entered my email and it says Invalid login credential.
UPDATE: They do have password reset available if anyone else runs into this issue, but I did not see this option on the login page, they had to email me a link.
Written some node.js + socket.io applications in the past. I like that you packaged storing info in the database. This is a great tool for a hackathon but if you are doing anything more complicated I think you would want to write you own back-end. Good idea guys keep innovating.
Agree with you. Sounds nice to throw a quick prototype or small apps (btw http://scratchpad.io is awesome) for someone who dont know scalable/parallel technology such ar Erlang or Node.JS. If you are creating a startup and planning to charge customers, I suggest you invest in your backend.
This is great news.
One thing I can't get my head around, I actually spent some time yesterday evaluating using Firebase, cloned the FireFeed demo app and browsed it, but I still have one thing I guess I'm missing completely.
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?.
I had this exact same question when I saw it. This is handled by Security Rules [1]. You define these rules using JSON - basically read/write access to objects on a per-user basis. Seems like a good solution, depending on how flexible the validation style rules are (seem to be very flexible at a glance).
I'm pretty impressed by the product, looks like it may even be a game changer for doing quick web apps.
Great question! The key to our security model is our Security Rules system. Security rules are authored by the developer and stored as part of their Firebase. Firebase then executes them automatically to validate all reads and writes of data.
1. The API was designed pretty carefully to ensure we wouldn't box ourselves into any corners that would limit our real-time or scalability capabilities. So we've intentionally avoided advanced querying for now. You may see features along these lines in the future, but right now we recommend denormalizing your data during writes to match how you want to consume the data (which is a pretty common nosql practice). Firefeed is a good example of this, actually.
2. RequireJS is on our radar. I don't know too much about it, but if developers want it, we'll likely end up adding it. :-)
Transactions have to be done at the common ancestor of the data being modified, so it's best to use them for data that's nearby in the Firebase data tree. You /can/ do a transaction on a large chunk of data (e.g. the entire user list), but the client would need to sync the entire data and there'd be a greater chance of contention.
If you need atomic bidirectional friendships though, you can do it if you structure your data a little differently. To turn a friendship between a pair of users on and off, you could set /friends/user1/user2 to true iff user1 and user2 are friends. Then you can write security rules that are based off of that to allow and deny access to the users' data.
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?
Absolutely. Our Node.JS Library[1] and REST endpoints[2] are for exactly that. So you can still keep all the benefits of Firebase (real-time data synchronization between all clients of your app) while augmenting it with server-side code specific to your needs.
Firebase persists all data permanently (and we back it up, etc.), so your data is "saved" just by using Firebase.
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.
Is it possible to use Firebase with Ember for instance? Technically, I know it's possible, but I mean, is it a viable option? Or, say, there would be a lot of redundancy between both?
66 comments
[ 3.5 ms ] story [ 146 ms ] threadI'm excited to see their product mature.
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!
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!
As a side note, I think that firebase is an amazing piece of technology and I can't wait to use it.
I wish I had thought of it :-)
"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."
[1] https://www.firebase.com/docs/faq.html
UPDATE: They do have password reset available if anyone else runs into this issue, but I did not see this option on the login page, they had to email me a link.
Demo: http://beta.plnkr.co/edit/?p=preview&s=FirebaseInBeta
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?.
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
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
2. RequireJS is on our radar. I don't know too much about it, but if developers want it, we'll likely end up adding it. :-)
If you need atomic bidirectional friendships though, you can do it if you structure your data a little differently. To turn a friendship between a pair of users on and off, you could set /friends/user1/user2 to true iff user1 and user2 are friends. Then you can write security rules that are based off of that to allow and deny access to the users' data.
https://github.com/umdjs/umd/blob/master/amdWeb.js
Keep killing it guys!
Are there any other BAAS providers that have something similar?
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?
[1] https://www.firebase.com/docs/nodejs-quickstart.html
[2] https://www.firebase.com/docs/rest-api.html
https://github.com/reproveme/firebase-comments
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.
[1] https://github.com/firebase/backfire
Update: There's a user-built binding for Ember here: https://github.com/maiah/emberfire
https://github.com/search?q=firebase+angular&ref=command...