

Our Beta is Now Open to All Developers - justinwi
https://www.firebase.com/blog/2013-02-13-firebase-opens-beta-to-all-developers.html

======
ibdknox
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.

Congratulations guys!

~~~
aria
Thanks Chris, I'll look into it based on your recommendation!

------
eranation
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?.

~~~
mikelehen
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.

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>

~~~
eranation
Few more questions if I may:

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

~~~
mikelehen
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. :-)

~~~
tristanz
On the denormalization front, is it possible to do transactions without
locking / syncing the entire tree. I'm thinking friendship modeling like:

    
    
      user1.friends = ['user2']
      user2.friends = ['user1']

~~~
mikelehen
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.

------
thisischris
Disclaimer: I did contract work for Firebase.

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
I love Firebase! <http://scratchpad.io> wouldn't have been possible without
it, and the team is super responsive to support requests.

~~~
craftman
Did not know this tool. Great stuff you created there!!

------
ianstormtaylor
Awesome product. Built socrates.io on it and plan to use it for all my other
similar projects

Keep killing it guys!

~~~
endgame
Oh god that "blinking cursor" in the socrates.io tab is annoying.

------
ivolo
Firebase allowed us to build socrates.io over one weekend. We didn't have to
write a backend, plus we got realtime for free.

I'm excited to see their product mature.

------
mminer
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.

[1] <http://cloud.exitgames.com>

------
josephlord
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.

~~~
mayop100
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.

------
d0m
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?

~~~
mayop100
Yes! Absolutely. A number of people are doing this already. We don't yet have
an official binding for Ember, but we do have one for Backbone [1].

[1] <https://github.com/firebase/backfire>

Update: There's a user-built binding for Ember here:
<https://github.com/maiah/emberfire>

~~~
marquis
An example with AngularJS would be fantastic, if anyone has something to
share. I'm doing some teaching at the moment with AngularJS.

~~~
jamest
Here are some GitHub projects that user Angular & Firebase

[https://github.com/search?q=firebase+angular&ref=command...](https://github.com/search?q=firebase+angular&ref=commandbar)

------
firdaus
I found this particularly interesting -
<https://www.firebase.com/docs/security/custom-login.html> \- since it allows
you to integrate with existing apps.

Are there any other BAAS providers that have something similar?

------
katowulf
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.

~~~
Maascamp
Curious, what do back ends consist of if not code?

~~~
snowmiser
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.

------
streeter
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.

------
VexXtreme
Great work guys.

Any chance of creating Java and .NET clients?

------
Rinum
It seems like Firebase removes the backend completely. It just pushes data
sent to it to all clients. This means data is always handled client side.

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
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.

~~~
Rinum
Awesome! I guess I'll be giving Firebase a try then, thanks for clearing that
up.

------
silverlight
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.

------
donkeybandit
Firebase is such a massive time saver! It seems every JavaScript developer I
introduce to it love it instantly.

I wish I had thought of it :-)

------
DigitalTurk
Looks interesting.

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
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.

[1] <https://www.firebase.com/docs/nodejs-quickstart.html>

[2] <https://www.firebase.com/docs/rest-api.html>

------
LAMike
The tutorial on the website is pretty cool, any other ones I can check out?
Good luck with Firebase it's off to a great start!

------
yesimahuman
Congrats James + team. I'm super excited to get this into Codiqa, I think the
rapid development aspect is hugely valuable.

------
pkandathil
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.

~~~
craftman
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.

------
gbadman
Just added real-time cursor/selection synching on Plunker using Firebase. It
couldn't have been much easier to integrate.

Demo:
[http://beta.plnkr.co/edit/?p=preview&s=FirebaseInBeta](http://beta.plnkr.co/edit/?p=preview&s=FirebaseInBeta)

------
reproveme
Here's a rough threaded comments example made with Firebase and Knockout. I'm
sure there are better ways to do this.

<https://github.com/reproveme/firebase-comments>

------
jenkinsj
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.

------
spo81rty
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

~~~
mayop100
[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."

[1] <https://www.firebase.com/docs/faq.html>

------
anandkulkarni
So glad to see it out of beta. Can't wait to start using it!

------
pacomerh
Looks very useful, what do you guys think of the pricing? seemed a little
expensive to me, maybe 1000 connections at a time are enough?

------
yksong
I was thinking about something like this could be really handy last night.
Great work!

------
mrmch
Congrats James & team! I'm looking forward to building something rad on
Firebase.

------
rmanalan
Congrats guys! I love Firebase!

------
thisisrobv
Great team, amazing product, really excited about where they're headed.

------
jccodez
Could this be used for updating windows live tiles in an app?

------
adventured
I can't get over how radically expensive their bandwidth is.

1tb for $2,000? Wow, breathtaking bandwidth costs. That's at least ten times
higher than I would have expected.

It makes Firebase completely unusable for any service that needs scale, unless
you've got more money than you know what to do with of course.

~~~
mayop100
[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.

~~~
adventured
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).

~~~
mayop100
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.

