Our Beta is Now Open to All Developers | Hacker News Reader

Our Beta is Now Open to All Developers

firebase.com

202 pointsjustinwi59 comments

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!

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

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

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.

[1] https://www.firebase.com/docs/security/security-rules.html

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

For anyone who isn't clear on what exactly this entails, but have some experience with AWS: it's a bit [a lot] like S3 bucket policies.

The Security Quickstart Screencast is superb, thanks!

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

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

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']

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.

Regarding #2, to register as a module you just need something like this:

https://github.com/umdjs/umd/blob/master/amdWeb.js

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!

I love Firebase! http://scratchpad.io wouldn't have been possible without it, and the team is super responsive to support requests.

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

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

Keep killing it guys!

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

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.

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

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?

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

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

Here are some GitHub projects that user Angular & Firebase

https://github.com/search?q=firebase+angular&ref=command...

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?

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.

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

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.

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.

Great work guys.

Any chance of creating Java and .NET clients?

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.

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.

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

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 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 :-)

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?

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

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!

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

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.

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

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

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

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

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

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?

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

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

Congrats guys! I love Firebase!

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

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

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.

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

Reply on news.ycombinator.com