Show HN: Firebase, a scalable real-time backend

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.<p>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.<p>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.<p>Definitely recommend it.

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?<p>It seems like it lowers the barrier to competition a bit too much for me.

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: <a href="http://www.cubeia.com/index.php/products/firebase" rel="nofollow">http://www.cubeia.com/index.php/products/firebase</a> 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.

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.<p>Dropbox for JS objects.<p>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.<p>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.

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.)<p>I'm not trying to put down Firebase, I imagine it's great.

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

Wow, im excited what people are doing out of this (especially in combination with other new tools like Meteor).<p>Seems there is a huge development ongoing to reflect new development and scaling practices...<p>EDIT: REALLY like the RT-Chat on the site - that is showcasing as it should be (and not just another "Demo" button).

Tools used (from the chat):<p>Mongo for storage backend<p>Node.js client is Faye<p>Scala + Netty backend<p>custom JS client supporting "IE7+, Opera 10+, Safari / Chrome (recent versions), FF3.0+"

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!

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.<p>Once you start playing with it you realize that there are so many apps that can be built.<p>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.<p>A very simple guide to make a very simple, understandable web-app would be the killer feature for me.<p>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.<p>So much potential.

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

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..<p>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!<p>(Absolutely loved the interactive tutorial. Brilliant way to show off the service!)

Seems slightly misleading with the pitch about "no servers". More like, "proprietary Javascript framework locked to proprietary hosted cloud service, no information about pricing".<p>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.

A real-time client-side library that ties in to their database hosting service, basically.<p>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.<p>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?

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

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.

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.<p>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: <a href="http://planscope.io/blog/2012/03/25/rails-is-more-than-an-api/" rel="nofollow">http://planscope.io/blog/2012/03/25/rails-is-more-than-an-ap...</a>

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!<p>Well done, thank you.

It's been a good week for the real-time-web.<p>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?<p>What kind of browser compliance is there?

Congrats on the launch of Firebase and absolutely love the code demo; it hooks you in.<p>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.<p>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!!

Great!

I think it's overrated. :/

This is cool. But can someone explain how data is secured in Firebase or Meteor?<p>From the Leader Board sample:<p>// Use setWithPriority to put the name / score in Firebase, and set the priority to be the score.<p>userScoreRef.setWithPriority({ name:name, score:newScore }, newScore);<p>How about I just change newScore to 100,000 in the debug window?

Looks very nice.<p>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.

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.