mayop100

The details here are a little off-topic for this HN thread. Could you open a thread on Stack Overflow and tag it "Firebase", or shoot us an email (support@...)? We support all of these use cases.

Good questions! Security is a top priority for us, and we can handle all of the use cases you mention.

One thing to note is that you don't put your auth credentials into the HTML (this would be very insecure!) -- you rely instead on a trusted service to do the auth and generate tokens for you. We provide a means of doing this called Firebase Simple Login, but you can do this yourself if you want as well. We then use these credentials in addition to a security rules language to define the operations a user is allowed to perform to the database. The security rules are very flexible. We have a video here that explains this: https://www.firebase.com/docs/security-quickstart.html

If you want a full example of security rules in action, check out our Twitter clone Firefeed: http://firefeed.io

Collaborative text editing generally requires a bit more than a simple transaction to work well (Operational Transforms are generally involved). You can use transactions as a basis for this though. We've got some examples coming out soon to show how to to do this. Stay tuned...

(Shameless plug) Firebase is an alternative to iCloud for many apps. It's built as a database, rather than a file store, so it's ideal for storing structured data. Conflict resolution is something we've been thinking hard about from day 1, and we think we have a pretty solid story [1].

We launched native iOS support a few weeks ago [2]. You can also access your data from JavaScript or from a REST API. Android and other platforms are in the works. We're a platform-independent service, and since you (the developer) is paying for the storage, we have the right incentives to give you maximum access to your data (unlike iCloud), and a good developer experience.

We've also put a ton of work into making it easy to learn and easy to use. See, for example, our quick tutorial [3].

If you've used Firebase as a substitute for iCloud, we'd appreciate your thoughts in the comments!

1. https://www.firebase.com/docs/transactions.html

2. https://www.firebase.com/blog/2013-03-20-new-firebase-ios-sd...

3. https://www.firebase.com/tutorial/

With SSL it's quite reliable (without it's pretty bad). Fortunately we always use SSL...

Firebase is a hosted service designed specifically for building real-time, collaborative applications. As a hosted, API-driven service it's easy to get started with and it handles scaling automatically. We're especially focused on keeping the API clean and easy to use. You won't need to worry about the mechanics of connecting to servers, long-polling, websockets, etc. Just drop in the library and go.

Real-time is at the core of Firebase -- it's designed to sync data fast enough that it's suitable for a whole new class of applications: multiplayer games, collaborative whiteboards, location services, and messaging apps.

Firebase is also designed for use across platforms and devices. Our JavaScript library supports the full featureset of our iOS and server libraries, so you can build apps that can communicate easily in real-time between the web and native mobile.

1. This is a complex topic, but basic ideas is that we clearly define the behavior of the API in conflict situations. Most writes are "set" operations, which is simply last-write-wins. Well-structured apps can use this for the vast majority of features. For cases where you need multiple clients to modify the same data, we provide a Transaction operation, which ensures the write happens atomically. See:

https://www.firebase.com/docs/transactions.html

2. The service is ready for production apps now, and we have many already (Twitch, Klout, TED, BitTorrent). We have a rigorous test suite, comprehensive, redundant monitoring, data replication, and backups in place. At this point the Beta label is largely there because we haven't built the infrastructure to handle payments yet. You can expect that label to come off in the next few months.

On iOS we don't use long-polling. On the web we use Websockets when possible, but fall back to long-polling if necessary. We only use HTTPS though for security reasons.

It's a general-purpose tool, so we expect to see all kinds of things built.

I'm especially excited about location services -- our SF Live Bus example in the blog post is one example, but in general there are tons of applications for notifying others of the locations of things in real-time (Uber, Postmates, Lyft, etc). I'm also very excited about multiplayer gaming on mobile, which is still in it's infancy. Some of the more interesting ones use phones in new ways. Gempad (in the post) uses your phone as essentially another input device. There are a bunch of other cool things you could do here as well.

We're really excited to be able to bring the ease-of-development and real time updates of Firebase to a new platform. Please let us know what you think!

It's just using Firebase, so you can write / read directly from Firebase using the Node.js lib / Web lib / REST API. https://magnets-hn1.firebaseio.com/.json?print=pretty

The code's on Github, and the data is all publicly-exposed through Firebase. Go nuts!

That's not the built-in behavior. Someone wrote a script to do that.

The original commenter is correct -- this is intended to run fully-client-side.

We provide a set of security rules and authentication that allow you to control access. Authentication tokens should always be generated on a trusted servers, either ours (in the case of Firebase Simple Login), or yours if you want to generate custom tokens, or a third party service like Singly.

Our billing structure is very similar to a CDN, where you are being charged for actual usage on a multi-tenant architecture.

It's not the stability of the node.js code itself that was the issue -- it was the stability of the protocol used to communicate with our servers. We didn't want to put it in the NPM before we were ready to support that version of the protocol going forward (once it's live on our devs servers, it could be there a very long time).

The wire protocol is solid now, so we're making the commitment to be backwards compatible from this point onwards.

When you're ready to step up your game I'll tell you about the cheat codes that let you choose Twinkie. : )

Most startups I know add analytics of some kind to their products before they launch them, but they almost never allocate time for analysis after the fact. I think this approach of deciding in advance why you're adding the analytics, and what decision you're trying to make is a good one. Analytics are useless if they don't result in a real change to your product at some point.

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.

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

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

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.

[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

Firebase can do this for you. It has a very flexible expression-based permissions model. You can set your rule to:

".write":"!data.exists()"

And people will be able to write only new items.

Yeah, that's gonna get pretty annoying : ) That "global sync" option is only for that one slide deck though (for demo purposes). If you upload your own deck, only the uploaded gets to control the slides.

I challenge you to find a way to use fewer servers... WebRTC depends on them for signaling. We're just providing a tool to make that easier.

See: http://www.html5rocks.com/en/tutorials/webrtc/basics/

"In the real world, WebRTC needs servers..."

We'll have a free plan, but in general, no it's not free. Neither is DNS though (it's free for the end user of course, but not the developer, just like Firebase).

[Firebase founder here] We weren't trying to be disingenuous with the title. Keep in mind that basically any web technology, including P2P ones, do actually use servers. If you're using a domain name, for example, you're probably going to use a DNS server. If you're using Google Analytics or any other addon in a web page, you'll be using their servers. If you're on a 3G connection your data is probably being proxied by a server somewhere. Even BitTorrent has trackers. The list goes on...

Our point is that you don't need to run a server. You can treat Firebase like you treat DNS -- a service that is there for you to use but that you don't need to operate.

Congrats to Jeff and the team!

This is a technology demo. We wanted to demo our real-time tech rather than show a bunch of sign-up workflow code. Facebook auth lets us save a bunch of boring code.