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.
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.
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.
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.
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.
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.
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.
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.
Firebase powers the realtime syncing in SlideScroll. I've also used it on several of my smaller project. It's easy to set up and way more stable than trying to roll you own socket implementation.
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."
[Firebase founder] I would caution against comparing our pricing to S3 or any other non-realtime storage service. Firebase's use case is primarily for serving structured data (the type of data that lives in a database). For most apps, this is a small piece of overall data usage. Your site probably spends most of its bandwidth usage on downloading static content -- HTML, CSS, images, videos, etc -- which you don't need to store in Firebase (you can, but if you're looking for a cheap way to store big video Files, Firebase is not the answer).
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.
I wasn't comparing Firebase to S3 (etc) so much as to what bandwidth actually costs service providers.
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).
Keep in mind that most of our costs are also not bandwidth. Our primary costs are the servers, our CDN, backups, and operations. Bandwidth is just one small piece.
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!