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.
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?.
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.
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.
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.
This looks like a fantastic service for game developers (indeed, one of their examples is multiplayer Tetris). Building backend infrastructure to facilitate realtime communication and features like leaderboards, and making them scale when the game becomes a hit, is difficult. Anything that lets game designers get back to developing the gameplay itself is hugely beneficial. For certain types of games it'll probably make more sense to use a dedicated service like Photon Cloud [1] that focuses solely on realtime multiplayer, but for simpler web games, Firebase looks promising.
I see they have a transaction system to manage conflicting edits. How does that handle nested data? If a parent is renamed or moved in the order is an offline edit to the child element rejected?
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.
We definitely allow you to manage lists in a consistent manner. Can you email me directly with your exact use case and I can help you get started? andrew at firebase dot com.
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?
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.
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'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.
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.
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.
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.
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.
[+] [-] ibdknox|13 years ago|reply
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!
[+] [-] aria|13 years ago|reply
[+] [-] eranation|13 years ago|reply
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?.
[+] [-] mikelehen|13 years ago|reply
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
[+] [-] RyanZAG|13 years ago|reply
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
[+] [-] thisischris|13 years ago|reply
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!
[+] [-] nbashaw|13 years ago|reply
[+] [-] craftman|13 years ago|reply
[+] [-] ianstormtaylor|13 years ago|reply
Keep killing it guys!
[+] [-] endgame|13 years ago|reply
[+] [-] ivolo|13 years ago|reply
I'm excited to see their product mature.
[+] [-] mminer|13 years ago|reply
[1] http://cloud.exitgames.com
[+] [-] josephlord|13 years ago|reply
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.
[+] [-] mayop100|13 years ago|reply
[+] [-] d0m|13 years ago|reply
[+] [-] mayop100|13 years ago|reply
[1] https://github.com/firebase/backfire
Update: There's a user-built binding for Ember here: https://github.com/maiah/emberfire
[+] [-] firdaus|13 years ago|reply
Are there any other BAAS providers that have something similar?
[+] [-] katowulf|13 years ago|reply
[+] [-] VexXtreme|13 years ago|reply
As a side note, I think that firebase is an amazing piece of technology and I can't wait to use it.
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] Maascamp|13 years ago|reply
[+] [-] streeter|13 years ago|reply
[+] [-] VexXtreme|13 years ago|reply
Any chance of creating Java and .NET clients?
[+] [-] Rinum|13 years ago|reply
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.
[+] [-] mayop100|13 years ago|reply
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.
[+] [-] silverlight|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] donkeybandit|13 years ago|reply
I wish I had thought of it :-)
[+] [-] DigitalTurk|13 years ago|reply
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?
[+] [-] mikelehen|13 years ago|reply
[1] https://www.firebase.com/docs/nodejs-quickstart.html
[2] https://www.firebase.com/docs/rest-api.html
[+] [-] LAMike|13 years ago|reply
[+] [-] yesimahuman|13 years ago|reply
[+] [-] pkandathil|13 years ago|reply
[+] [-] craftman|13 years ago|reply