Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Firebase, a scalable real-time backend (firebase.com)
526 points by jamest on April 12, 2012 | hide | past | favorite | 137 comments

I used Firebase to build thereelbox.com, and enjoyed it thoroughly. It took 2-3 hours from starting into the documentation to completed/nobugs/pushed to production. Credit for that speed goes entirely to Firebase.

TheReelBox uses Firebase as a sort of API caching layer. This protects against rate limiting on the Rotten Tomatoes API, decreases request time by caching queries to the Fandango-via-YQL API, and eliminates an extra request per movie for Youtube trailers.

At the beginning, this system made it possible to host TheReelBox on my public dropbox folder, which made for really fast development. Since launch I've moved the static html and js to a micro AWS instance, but Firebase cleanly and transparently handles all the data.

Definitely recommend it.

Wow !! As a movie buff myself I think I'll be vising you site almost everyday now. This is what I used to do before:

  - Go to www.imdb.com
  - Click on 'See more movie showtimes' at the right.
  - On the next page, click on the 'Favorites' tab to choose a theater.
  - Go to maps.google.com and plan the route to the theater.
This is definitely going to save me at least a few hours every week while I check which movie is playing at what location.

And its got TRAILERS too !!! I'm addicted !!

Your comment makes me very happy, please enjoy!

You can also type 'movie showtimes' into google and there is a nice interface with maps which shows movies and which theatres they're playing at.

Any reason you don't host those static files on a public 'web enabled' ec2 bucket? We do that for http://www.incubatebang.com and it costs us like $1.40/year for hosting

That's a cool idea, Dropbox and S3 both seem like good ways to get started with Firebase really fast.

The AWS micro is free :) and it gives me a bit more flexibility to do things (in the future) like track outbound clicks to Fandango through a redirect that hits a real server.

I love the design of your site! Did you have it done in-house?

Yeah, I'm an owner of http://www.isotope11.com and our designer threw it together in a couple of days. He's awesome, and he's leaving shortly, and we'll miss him :(

Just out of curiosity. Are you aware that all your data is fully editable through the admin panel? Or is it just a toy project and it doesn't really matter?

yes, side project. my real focus is http://segment.io

Still though, somebody could delete all the movies and showtimes in a couple of clicks. I presume you have the JSON backed up but it's still going to get annoying if somebody decides they want to be a dick.

true [backs up data]. the system will also auto-recover by falling back to the RT/YT/YQL APIs if someone does that, though pages will load significantly slower and Rotten Tomatoes will throw a bunch of rate-limiting errors until Firebase is repopulated.

I'll be honest, it's kind of fun to go to [REDACTED URL] and delete the list of movies and watch them repopulate as people load the site...

Sorry, I'll stop.

Seriously though, this is a neat toy/prototyping platform, but they desperately need to add some security for it to be really useful.

This was also a concern after browsing trough the tutorial. how do we secure the data if it's available to everyone ;)

Just a quick thing - for places that aren't so densely populated (like Tucson) it says there's no information. It'd be nice if you would expand your search a bit outside densely populated areas.

Awesome dude. Great idea and execution for 3 hrs of work! Minor suggestions:

- Sort by (name, start time, rating, distance)

- include video playback controls, useful info such as time of preview, buffering, etc..

- X out or remove videos from my personal view, this would be KILLER to allow me to narrow down my choices as I watch videos

Your app actually reminds me of a movie version of my app. Kudos!

Might I recommend incorporating some sort of mechanism to help people figure out a movie to watch?

Hey, I like your app! I would use it again if I could expand the map to make it larger. Would be the perfect tool for finding a movie.

Really nice site! I love the UI. But please make it available for other countries too (me: Switzerland!)!

dude. your site is dope!

That's quite useful! I hope you're making money from it.

FYI, hangs on buttering popcorn in Opera.

Nice. The Hunger Games is a rickroll? Is that something you did?

Haha; see nigma's earlier comment about the open admin panel.

Seems slightly misleading with the pitch about "no servers". More like, "proprietary Javascript framework locked to proprietary hosted cloud service, no information about pricing".

Not that I begrudge anybody the chance to make some money, but along with Meteor I feel like there's a slightly deceptive nature to this kind of thing where the home page is emblazoned with "look, it's all free!" when in fact there's an unknown price to pay down the line.

Firebase is not really super complicated. It's just a database with a REST Api. I can not think of much more things they could add to lock you in more. I think if this becomes a thing, someone will make an opensource clone sooner or later.

About Meteor: There might be a lot of things wrong with Meteor (insecure by design), but this is not one of them: it's opensource and has a command which makes a self containing tar.gz bundle for you to deploy on your own server.

Firebase is a lot more than a database with a REST API. It pushes changes to you live, as they happen, in a way that is fast enough that you can use it for real-time gaming, collaborative whiteboards, and other apps could never work with a polling architecture.

It also does the work of managing distributed state of data across all of the clients and the server, and merging that data as needed to prevent conflicts in a distributed network like this. In fact, it allows you to run operations atomically across this distributed system -- operations that are latency-compensated, and work even in offline mode.

And finally, it can scale, with no work from the developer.

Yeah sure!

Suddenly there is a solution to distributed always consistent real time fully scalable reliable easy to use inexpensive database :)

Do you know this saying? "Nobody can give so much as I can promise you."

> it's opensource

Under a license that does not permit you to easily use it for commercial projects, unlike, say, Django, Rails, Node.js, etc... etc.... etc....

That is not true. It's released under the GNU GPL, which does not make a difference between commercial and non-commercial projects afaik. It only says if you distribute the binary, you also need to give away the source code and others may redistribute and modify it. That does not mean, however, that you can not run it on your own server and keep the source code for yourself.

But it's all bundled up, so you're linking: you need to give your code away. That's my understanding at least. If it were purely server-side, you'd be correct, but it isn't from what I can tell.

Also, the fact that they talk about commercial licenses is indicative that they may be thinking along similar lines.

As davidw says, you are distributing the "binary", because you are sending it to people's browsers in the form of javascript. Under GPL you are not permitted to do that unless you also make available to them the full source of your application.

Meteor is open source, and with one command you can bundle your app into a self-contained node.js app which can, of course, run anywhere you can run node.js.

We make no claim that the service will be free. It won't be. We'll charge based on usage, in the same way other PaaS type providers do.

Here's my big concern: If my entire app is client-based JavaScript, wouldn't that make cloning my app as simple as copying all of the JavaScript and other asset files and then associating them with another firebase account -- perhaps modifying them some so they dont't get banned?

It seems like it lowers the barrier to competition a bit too much for me.

I think that is a valid concern, but it doesn't really apply to all apps.

As one example, for a lot of businesses, the value is not so much in the app itself but in the data the app interacts with. In those cases, giving your competitors the source code to your app does mean they could copy anything they want from your app, but that doesn't do them much good if the real value is in the data.

I think you're thinking a little too short-term here. It seems like a jump in technology that could completely change the way people build apps.

Glad to see interest in the idea. It's not much different from what people have been doing with projects like http://couchapp.org or http://unhosted.org/ for some time.

Once you have a basic HTTP database API, you can do most of an app in client-side JS. Security is the hardest part to get right. In CouchDB we've tried to follow the web security model when it makes sense (single origin policy, oauth, etc).

CORS and WebSocket are both changing the web model, so it's not surprising to see the idea of a simple data API catching on as the web gets more power. Can't wait to see where this goes.

You should work in their marketing department.

You could say that just about any software development platform. If it makes building software easier, it makes competition easier. And if building apps is easier, it really doesn't matter what stack your app uses - it's going to get easier to "clone", so you may as well use whatever platform gives you the best results.

Other than that, you could either make your business, rather than your technology, more competitive, or make your technology ever more sophisticated than what "commodity" development tools allow.

It's not that client-side applications are easier to reverse-engineer. If the application is all client-side, it can literally just be downloaded and reused by a would-be competitor.

which violates your copyright.

Microsoft Word is entirely client-side so it too can literally just be downloaded and reused by a would-be competitor.

Downloading Microsoft Word does not include all the source code in addition to the application.

Neither does obfuscated and minified javascript.

Yes, it does. Where do you think the source code is?

It may not be at the same level as disassembling binary code w/ IDA or what have you, but un-minifying or un-obfuscating JavaScript is not a trivial exercise by any means.

(If I were in a nitpicking mood I would also point out that the source is what is fed into the minifier or obfuscator, not what comes out.)

un-minifying javascript is very trivial. you just copy and paste it into an online javascript beautifier. you won't get the original un-obfuscated source with original comments, but you'll get readable javasript that you can easily parse visually.

as I said above, de-obfuscating a large javascript app that's been obfuscated/minified by proprietary tools is virtually impossible to decode. Try running some of google's code - gmail, docs, take your pick - through your beautifier ;)

I don't know if anybody uses proprietary tools to minify and obfuscate their javascript. We all use the same minification tools, with different features selected. Seems like most people use YUI compressor, or one of the others listed here http://compressorrater.thruhere.net/. I assume Google is using their closure tools (which I've never played with myself).

It's a lot easier to reverse-engineer the site than to build it from scratch yourself. You won't get all the comments, and some of the names of functions and variables and whatnot may lose their semantic meaning in favor of shorter names. But yes, it is trivial to unminify the source and work through it. If it's 10k+ lines of code, that's never trivial to understand and get it all in your head, but the concern is absolutely valid. If you think minifying/obfuscating is securing your code intellectual property, you're fooling yourself. It's like security through obscurity... it's not really offering you any protection.

That doesn't sound right to me. People will rewrite code that already exists as open source because they don't want to take the time to understand someone else's code. But you're saying that some will reverse engineer a JS app from minified code rather than just rewrite it. Are there any examples of this actually happening?

I'm a curious guy and have deciphered small-ish amounts of minified and/or obfuscated JS before. It is absolutely not trivial. Especially if it's obfuscated.

I'm mostly responding to your comment here.

"un-minifying or un-obfuscating JavaScript is not a trivial exercise by any means."

I think you mean that understanding obfuscated code is not trivial. Un-minifying is certainly trivial. There are tools to do it for you. There's no such thing as un-obfuscating, if you consider that you can't get the original comments or all the semantic naming back. So I'll concede that it's more difficult to read through this obfuscated code than the original. But the original comment in this long thread seems valid to me... that an entirely client side app puts you at much greater risk for cloning than an app with a significant portion of code in back-end, just because your javascript is out there for all to see.

have you ever looked at code obfuscated by proprietary tools? By your logic it's easy to reverse-engineer and copy Gmail - good luck with that

Are you saying you don't think Gmail has a backend...?

Of course it has a backend, but so do the Firebase apps that this entire thread is talking about. Referring to a JS app as "client-side" doesn't imply that there's no backend logic.

My point is that you can't just de-obfuscate a primarily client-side JS app and replace the Firebase (or whatever) endpoints. Proprietary obfuscation is more than just variable name munging and minification..

The Gmail backend isn't available in the same way as the Firebase backend.

I keep wondering this myself. On my resident JS-only app, the only thing that I can think of that's keeping someone from ripping off my code and duping the site is that nobody cares enough to try.

Or using your paid repository to story their own app data. The authentication credentials are running on the client. I'm wondering how I keep a troll from writing a billion things to my firebase.

When the multi-player asteroids story was published, people were talking about Firebase, and having never heard of it, I started googling and found this: http://www.cubeia.com/index.php/products/firebase A scalable real-time game server with a html5/javascript front end. I still don't know which Firebase that game was built with. You guys have trademark issues.

MMOasteroids.com links to firebase.com

If I understand right: instead of having to worry about calling a REST API for a back-end data store I can just have JS objects persist automatically and synchronize between clients.

Dropbox for JS objects.

If I've got that right, I think this is totally awesome for front-end web devs and the most exciting backend-as-a-service out there.

Another great step in the right direction.

That being said, I do believe the hardest part of all these attempts to abstract backends is authentication and security models. It seems to me that most of these services launch before figuring out that critical part of the puzzle.

Meteor dev here. You're absolutely right that authentication is one of the hardest parts. What's happening is that the web is moving from a model analogous to mainframes and dumb terminals (where there is a central authority directly driving everyone's screens), to a distributed model where there are a lot of different actors, with different levels of trust for each other.

Figuring this stuff out is hard. Usually for questions that come up in this shift, we have a good model we can look at, which is the client/server desktop applications of the late 80s and early 90s. But in the case of authentication and security, they tell us not so much, because in those days most software lived inside private corporate silos. These days, our software not just technologically distributed, it's politically distributed.

In the case of Meteor, it's designed from the ground up for security. In fact, it's a second generation security model, designed after reflecting on lessons learned from Asana's Luna platform (I worked on Luna at Asana for a while in 2010.) It just isn't exposed in a user-friendly way in the Tuesday release.

But people dug into the code, found it, and are using it anyway, whether we like it or not. Briefly, 'meteor remove autopublish', use Meteor.publish to define what data clients can access, use Meteor.subscribe to control what data a particular client is getting, use Meteor.methods to define what writes clients can do, and see the following Stack Overflow question to disable the 'newbie mode' insert()/update()/remove() that let you do arbitrary writes to the database.


We're using authentication in our Firebase app and it works wonderfully. Although all data is visible on the Firebase backend, we simply put pointer ids in Firebase, so no identifying data is publicly visible.

Care to elaborate? Firebase's FAQ seems to suggest that they're still working on a solution.

I believe they are working on a fully documented and stable auth solution; we're running something custom for now. Our whole Firebase namespace is read-only, so all our writing happens with a private key from our server. I think when the Firebase admin panel has more protection we can store more sensitive/identifiable data in there.

What level of control do you have for authentication? I didn't see much info on this on the website.

Write control was most important for us; all the readable data are simply id's to our internal DB

This is cool. But can someone explain how data is secured in Firebase or Meteor?

From the Leader Board sample:

// Use setWithPriority to put the name / score in Firebase, and set the priority to be the score.

userScoreRef.setWithPriority({ name:name, score:newScore }, newScore);

How about I just change newScore to 100,000 in the debug window?

Good catch : ) We mention this briefly in our FAQ. We actually do have security in place (notice you can't enumerate other people's data for instance in our own tutorial), but the API is far from complete and we have no docs yet. There will be a full-fledged security model coming over the next few months.

That's only true until they launch a public product: at that point you can get access to or modify their data. It is downright irresponsible to launch a service like this that encourages people to use an insecure design for their service: security should be built in from the beginning, not tacked on afterwards, and even at the level of "this is a tutorial" it should be clear to the developer what they need to do to make it secure (not thrown into the advanced level of documentation, for example, like some companies do).

Highly interested in what you plan to offer for authentication options and security (both data and transport).

This sounds like Model-as-a-service from the MVC pattern.

Thanks. It will be interesting to see how you guys do that.

Great website BTW.

Hey Ian, Meteor dev here. I posted a comment earlier in this thread about how data is secured in Meteor:


Can't people find an alternative to the word "real-time" that hasn't already been used for 30 years to mean something entirely different? (As in, real-time systems, real-time operating systems, etc.)

I'm not trying to put down Firebase, I imagine it's great.

Sorry - I think "real-time web" is already in our lexicon.


Just make sure people say web after they say real-time and there should be no confusion.

I don't think that it's a lost cause. Mainly because calling these things "real-time" is technically incorrect. Real-time computing is already formally defined and well established.

Given the definition of real-time, one could actually create a real-time web or a real-time search. So there is still cause for confusion--or, at least, technical incorrectness--if one uses that terminology.


I'd like to see a term that emphasizes that what web developers consider real time is "so fast it looks instant to humans," rather than guaranteed low latency that another system can rely on (or whatever you consider the true definition of "real time" to be).

So maybe something like "blink speed." (Then we'd have blink speed apps on retina displays.)

Low-latency seems kinda descriptive if I have understood the 'real-time web' concept correctly.

I've heard "auto-synchronizing" suggested, but I think that's probably too wordy to catch on. How about "immediate"?

Is this your stock response for any article that mentions real-time? You made an identical comment yesterday about Meteor; only the name differs: http://news.ycombinator.com/item?id=3825728

No, I've never brought it up besides yesterday and today (as far as I recall), and I'm not planning to keep bringing it up and making it a crusade. I try to be a good community member.

Interstingly, I got much more feedback this time, probably due to catching the article soon after it was posted. It's also intersting that you noticed that I'd posted an identical comment yesterday and called me out on it; I was wondering if anyone would.

I hadn't given it much thought, but if making the same comment twice bothers anybody, I apologize.

Meteor dev here. I share your frustration. It's tough to find words to explain these systems that most people will understand. We managed to keep "realtime" off of the meteor.com page :) but we let it slip into the HN story title. That's because some smart people told us that readers scan HN headlines for keywords, and that "realtime" was the word that they were mostly likely to pick up on. I hope that soon we have an appropriate set of words for these new systems.

Interestingly, most of the core Meteor team has worked on systems that you might consider "actually" realtime: I wrote machine vision software that watches a few dozen cameras and tracks objects moving between them, Nick wrote software defined radio code that runs inside rural cell towers, Matt wrote kernel drivers for high performance IO interconnects.

Looks very nice.

But just like meteor, doesn't have any authentication or authorisation, which sadly makes them just toys for now. Looking forward to both projects becoming usable.

I'd love to see the host-proof scheme that ZeroBin uses, so users can store sensitive data without having to trust Firebase. http://news.ycombinator.com/item?id=3832269

Wow, im excited what people are doing out of this (especially in combination with other new tools like Meteor).

Seems there is a huge development ongoing to reflect new development and scaling practices...

EDIT: REALLY like the RT-Chat on the site - that is showcasing as it should be (and not just another "Demo" button).

Everyone has been building their own real-time solutions for the past few years and re-inventing the wheel over and over again. We saw ourselves doing it too, so we thought maybe we should do something about it! We think Meteor is really exciting as well, and should enable faster / better development of the types of apps that Firebase powers.

Meteor dev here. We're really excited about Firebase -- the time has come for realtime databases. Every Meteor app needs one.

Tools used (from the chat):

Mongo for storage backend

Node.js client is Faye

Scala + Netty backend

custom JS client supporting "IE7+, Opera 10+, Safari / Chrome (recent versions), FF3.0+"

Thanks for sharing this! Too busy in chat to keep up with all the HN comments : )

This is the way to do demos - easy enough for a non-coder to use, but it explains and shows the internals for more experienced developers. Nice work!

Thank you! Glad you like it!

I was part of the beta and really enjoyed working with Firebase it was like working only in the browser, i could forget there was a backend.

Once you start playing with it you realize that there are so many apps that can be built.

the team has a few things to work on, and trust me many of us in the beta flushed a lot of those out. they have their work ahead of them. what's there is polished and ready for use. give it a try. use this as a chance to explore what can be done when you can forget about the backend.

I'm a non-coder.

A very simple guide to make a very simple, understandable web-app would be the killer feature for me.

There is a tutorial for a chat-app but that's way over my head(I of course get how to put in the code, I just don't understand it (REST, roots, references etc). If I could be shown how to make something insanely simple, and I actually understood how it worked, it'd lead me on to the next thing. A collaboration with codecademy might be the thing.

So much potential.

I'm the same way and have thought about this concept... I'm not even completely sure exactly what Firebase is but it sounds similar to that idea just requires more coding experience.

What is the difference between this and let's say 'Meteor'?

Good question. Meteor is an application framework, like Ruby on Rails. Firebase is a database, like MySQL.

We both think that application development is going to radically change in the future and we're both building products that promote a new way of developing apps. We're stoked about Meteor and see our products as very complementary.

Good answer :)

One minor quibble.. I like to think of Meteor as an "application platform" rather than a framework, because we're trying to take on some problems that web frameworks don't always tackle, like packaging and deployment. Also, we don't require you to use a particular strategy for generating HTML. For example, it makes sense to use backbone.js with Meteor, if that's your thing. At the end of the day, Meteor is about how you make all of the pieces fit together in a distributed cloud application. (For better or worse, that's what websites have morphed into, when you think about all of the APIs and services they use.)

Could Firebase be used as a database for Meteor? (i.e. replacing Mongo)

yes. There is a node.js library for Firebase that uses websockets as a transport layer.


Meteor dev here. If you're writing a Meteor application, you need a realtime database. Otherwise, Meteor can't make the page update in realtime, because it can't find out about database changes in realtime.

Firebase is a realtime database that you could use with Meteor. The database we use in the Meteor video is MongoDB with Meteor's 'mongo-livedata' package, which adds some realtime glue to Mongo. But there are many potential advantages to using a database that is designed from the ground up to be realtime, and we're very excited that the smart guys at Firebase are taking this on. We predicted that this would happen eventually, but we had no idea it would be so soon.

(If you don't like the word realtime, please s/realtime/reactive/)

Would you say that Meteor is a functional reactive programming platform like Flapjax or FrTime, but over the wire? Distributed FRP?

Yes, except that we have tried to massively simplify FRP to make it more accessible and more familiar-feeling, and to break the system into pieces so it's not one monolithic blob.

I used to work at Asana, where I worked with Luna, which is Asana's inhouse framework and is a distributed FRP system very much like a future-alien-technology version of Flapjax.

This looks awesome -- a better option than an api-only Rails backend. Realtime pub/sub is also a big plus. Security is a concern with any 3rd party storage, but most uses I can think of wouldn't store missile launch codes in here anyway..

It's also worth pointing out that Firebase grew out of Envolve which supported millions of users, so you know these guys can handle scale.

This looks really good. It seems to be very similar to the Hydna app that was on HN yesterday. For the rest of us, that has to be a win. Can't wait to see how things develop with both companies now!

(Absolutely loved the interactive tutorial. Brilliant way to show off the service!)

A real-time client-side library that ties in to their database hosting service, basically.

Also, if you want to have any non-realtime parts of your web app that do server-side processing of data then it looks like you have to use Node.js to talk to Firebase, as there's no REST API for it that I can see. I guess they don't mind because they're trying to get you to do all data processing in the client anyway.

Definitely need security and permissions. How do I make sure only registered users of my site can access chat? How do I make sure only admin users can create new chat threads? From my brief reading it looks like all clients can see everything in the database and modify it all. Am I wrong?

You can find our REST API docs here: http://www.firebase.com/docs/rest-api.html

We're definitely working on security full speed. We have some basic security but it's not ready yet. If you'd like to beta test it, please email us: beta@firebase.com

You can check out our FAQ for more info: http://www.firebase.com/faq.html

There are ACLs for handling security concerns, but it's fairly early in their conception so they aren't really documented yet.

Also, there is a rest API and I believe they're working on clients for other platforms so that nodejs isn't the only player in town.

on a sidenote: I wouldn't do business with or trust my data to a company that hides their actual address behind whois protection

Good point. This was on while we were in stealth. I've removed the whois protection.

I don't think they are trying to hide anything per se, the company grew from envolve.com. Seems to be pretty open here http://www.firebase.com/about.html

They'll probably remove the whois protection once they fully launch.

Firebase, Burn your servers, you don't need them any more. Firebase is for app developers that don't want to worry about building real time scalable back ends.

Random aside, but when I first saw this comment (it was originally downvoted, IIRC), it sounded like an incoherent insult directed at Firebase for catering to "noob" developers; I only realised that you meant it as a potential marketing line after reading a bit of your comment history :P. I think a colon in place of a comma at the start would have been more clear.

What are the main differences between this and Meteor? What a strange coincidence that two nearly identical platforms launch within days of each other.

I just asked them twice on their chat to describe their infrastructure and they won't do it, at least yet.

I realize this is in beta, and it's early, but am I the only one who would not trust my data to a service where I can't get at least some idea of how they're actually functioning behind the curtain?

A few weeks ago, I wrote about (and presented at RubyNation) on why I think a "dumb backend" is a really bad idea: http://planscope.io/blog/2012/03/25/rails-is-more-than-an-ap...

Phenomenal. I've been waiting to try this for months! It looks terrifically easy.

What I like most about Firebase so far compared to Meteor, is that I can actually read about Firebase and its excellent documentation from any machine with any web browser!

Well done, thank you.

It's been a good week for the real-time-web.

We might need a snappier name though, because this sort of real time is a lot more real time that the type of real time people are already used to.


I couldn't find any (easily accessible) info about what it actually uses to communicate. Is it long-polling, websockets, something else?

What kind of browser compliance is there?

It uses a variety of techniques, depending on what is available on the client. When possible we use web sockets in the browser, but have other methods we can use when they're not available.

Congrats on the launch of Firebase and absolutely love the code demo; it hooks you in.

At the end of the demo you are asked if you'd like early access. Definitely.

For those interested in this kind of service there are a variety of others, including our own (spire.io), as well as Pusher, PubNub, and others.

Really interesting idea, look forward to giving it a whirl in a moment.

Quick question, are you affiliated with firebase.co? They seem to be in a similar field.

This should play beautifully with client-side JS web app frameworks like AngularJS where the JSON models are 2-way bound to the views.

Fantastic job. This looks phenomenal, James! I can't wait to find an awesome project to put this to good use. Cheers!

"real-time" has a very specific meaning when it comes to software, don't dillute it please.

This is going to revolutionize the way apps are built.

Looks similar to what Meteor was trying to achieve?

Firebase will turn into a chat company :p

congrats, james. i'll whip something up for teamly soon enough:)

Simply Amazing!!


I think it's overrated. :/

Can someone explain what kind use-cases there are for a database where the client can read and write directly against the database? CouchDB could do this (via CouchApp), but I bet not many people do this because it's bad from security and scaling standpoint and I think there aren't that many types of apps that can be created without a proper back-end.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact