Today, we are happy to announce AngularFire: Firebase bindings for AngularJS that will make it even easier for developers to write rich, real-time web applications using the two technologies. Check out a live demo - we updated the Angular example from todomvc.com to be real-time. We also made it so you don't need a server for your Angular app, all in just a few lines of code!

Firebase + Angular.js = unimaginable developer bliss

— Mark Nutter (@marknutter) February 21, 2013

Why we built AngularFire

Firebase handles everything about data synchronization elegantly, but the other half of building a web app is rendering the content. A lot of our developers were already using frameworks like Backbone, Ember, and AngularJS to help them build their front-end. Angular naturally piqued our interest, and we have been very impressed with all the great things developers have to say about it - like the elimination of DOM manipulation code and the 2-way data binding. We faced some of these same issues while writing our sample apps. When we built Firefeed, the bulk of our code was applying data changes from Firebase to the DOM. Without some structure, the code could get ugly rather quickly. We had a feeling that Firebase and Angular would go really well together, and many from the Angular community agreed. We also noticed that several folks, such as Plunker, were already using Firebase to power the backend of their app and using Angular to build the frontend - so building first-class bindings was a no brainer for us. Angular's History When we first learned about Angular we were surprised to discover that its original intention was to be a cloud JSON data store, very much like Firebase. Here's a quote from Wikipedia:

“ AngularJS was originally developed in 2009 by Miško Hevery and Adam Abrons as the software behind an online JSON storage service, that would have been priced by the megabyte, for easy-to-make applications for the enterprise. ”

It was not surprising then, that we found it remarkably easy to integrate Firebase with Angular. We're pleased to say that the two technologies fit together very elegantly.

How does AngularFire work?

First, you'll need to include the AngularFire JS include, as well as Firebase:

<script src="angularFire.js" type="text/javascript"></script>
<script src="https://cdn.firebase.com/libs/angularfire/0.5.0/angularfire.min.js" type="text/javascript"></script>

Then, declare the 'firebase' module as a dependency for your app:

var myapp = angular.module('myapp', ['firebase']);

Finally, bind a Firebase URL to a model in your controller:

myapp.controller('MyCtrl', ['$scope', '$firebase',
  function MyCtrl($scope, $firebase) {
    var ref = new Firebase('https://<my-firebase>.firebaseio.com/items');
    $scope.items = $firebase(ref);
  }
]);

Now, any changes made to the model referenced by $scope.items (a regular JS array) will automatically be synchronized to Firebase - and therefore also show up on all your other clients. That's it!

We also have another mode of operation for cases where you want to be more explicit about when to sync model changes to Firebase. Check out the AngularFire website for more information.

Thank you!

These bindings would not have been possible without the help of Peter Bacon Darwin. Peter is an active member of the Angular community and had written the first ever Firebase/Angular integration library. We look forward to continuing working with him on making AngularFire ever better!

We'd also like to thank Benny Lichtner, Tom Saffell and Geoff Goodman for their invaluable feedback on early versions of AngularFire. The Angular community has also been immensely helpful to us, and we look forward to working with you all!

Join our Firebase + Angular Google Group to share your feedback or ask questions, and check out AngularFire on GitHub to file issues and pull requests!

---

[1] AngularJS Development History, Wikipedia

On March 21st, at the UserVoice Summit 2013, we were the proud recipients of an award for the highest "kudos" rate of any company using UserVoice for customer support. We received a gorgeous ribbon that states: "First Place in giving a #@%! about their customers".

As a product primarily focused on developers, high quality customer support is something we are very focused on. Many support requests we receive are unique to the developer sending them in, which is why every ticket is personally handled by one of our engineers who tailor a specific response. We believe customer support is the responsibility of the entire organization, and it is crucial for our developers to understand how our customers are using our product and what problems they're having with it.

Our success depends on the success of developers building on our platform. Firebase is a unique product, which is why we're more than happy to engage in a discussion about whether Firebase is suitable for your particular project, help you architect a great solution, as well as debug any issues you might face while using our product.

Please don't hesitate to reach out to us through one of many channels:

• Posting questions tagged 'Firebase' on Stack Overflow.
• Posting to our community Google Group.
• Sending a tweet our way.
• Sending us a good old email.

We look forward to providing you the level of support you expect and deserve for many years to come!

This is the first in a series of blog posts on Architecting your application with Firebase.

Firebase isn't just any ordinary database. As a real-time, scalable backend, we provide the tools you need to quickly build rich, collaborative applications that can serve millions of users.

In this blog post, we’ll take a look at the considerations you’ll have to make while trying to decide where Firebase can fit into your application. We’ve seen three common patterns of Firebase powered apps, and we’ll discuss each one.

Pattern 1: 100% Firebase-powered apps

Many Firebase-powered apps consist of only client code, and don’t need anything other than Firebase and a way to distribute your app to work. They’re ideal if:

• You’re developing a brand new application, or rewriting an existing one from scratch.
• Your application needs minimal integration with legacy systems or other third party services.
• Your app doesn’t have heavy data processing needs or complex user authentication requirements.

In this architecture, your app only consists of static content and assets, and all your dynamic content and user data is stored and retrieved from Firebase.

For example, on iOS you can simply package up all your resources into the app itself and post it on the App Store as you normally would. On the web, you can serve your files from any web server, a CDN, or if you want a quick way to get online - check out Github Pages and Harp.io.

With 100% Firebase-powered apps, user authentication can be handled by our Simple Login service which supports Facebook, Twitter, Github and Google; in addition to a regular email/password login scheme. Simple Login eliminates the need for you to write your own server-side authentication code.

Update (October 3, 2014): Firebase Simple Login has been deprecated and is now part of the core Firebase library. Use these links to find the updated documentation for the web, iOS, and Android clients.

We built such an app called Firefeed as an example. Firefeed is a Twitter clone - it lets you post messages and have other people following your stream receive those messages in real-time. You can do pretty much everything you can do on Twitter, all without any server code. We highly recommend checking out the code for Firefeed and reading the about page if you're considering going down this route.

Another example is multiplayer games - Firebase is great at propagating data in real-time across all your clients. Depending on your game logic, you may also be able use our security and validation rules to ensure clients don't write data in ways that your logic doesn't allow, without requiring a server to ensure game state.

Check out our case study on Roll20, a 100% Firebase-powered App.

Pattern 2: Firebase-powered app with server code

In some cases it’s not possible to get away with only client code. Let’s look at a few examples:

• You want your app to integrate with third party APIs (like Twilio to send an SMS, or SendGrid to send an email).
• You have advanced authentication requirements. For example, LDAP integration, or authentication against a service not supported by Simple Login or a Firebase third party partner (like Singly).
• Your app has computationally intensive code that you can’t run on a client, or requires code to run on a trusted server.

In this architecture, Firebase sits between the server and clients. Your servers can connect to Firebase and interact with the data just like any other client would. In other words, your server communicates with clients by manipulating data in Firebase. Our Security and Firebase Rules language lets you assign full access to your data to your server. Your server code can then listen for any changes to data made by clients, and respond appropriately.

In this configuration, even though you’re still running a server, Firebase is handling all of the heavy lifting of scale and real-time updates.

If you’re writing your server code in Node.JS, integrating with Firebase is easy. Our Node.JS library provides exactly the same API as our JS SDK. If you’re using a different language or framework, you can store and retrieve Firebase data using our REST API - this will work from any environment that lets you make HTTPS requests.

If you’re integrating an existing user authentication system with Firebase on your server, we also provide Auth Token Generators for a variety of languages.

An example of such an architecture in action would be clients placing tasks for the server to process in a queue. You can have one or more servers picking off items from the queue whenever they have resources available, and then place the result back into your Firebase database so the clients can read them. We have a Node.JS library that will help you do this, check it out!

*Check out case study on Wordspot, an app with both server and client code using Firebase. We've also built a search library called Flashlight that uses a queue and a server process to provide content searches.

Pattern 3: Existing app with Firebase-powered features

This pattern is common for larger sites, and is suitable if:

• If you have an existing full-featured app, and aren’t planning a rewrite.
• Your codebase is large and depends on several services or components that you cannot change.
• You want to add real-time features without touching the rest of your app.

In this architecture, Firebase sits alongside your existing server. Your clients will connect both to your server and Firebase and will utilize Firebase to power your real-time features, without interfering with the rest of your application.

Using this pattern, you can add a real-time notification system for your users, embed a chat system in your website, create a comment feed that updates in real-time, and more! Starting with small features is a great way to get started with Firebase. To make it even easier to integrate features like these (and more), we’ll be releasing several open source libraries over the coming months, so stay tuned!

Twitch.TV is a popular website that is using Firebase alongside its existing infrastructure.

Wrapping Up

We’re always on the lookout for new and interesting ways of using Firebase, so If you’ve come across (or are building) an app that uses a different pattern than the ones we’ve discussed, please let us know via our Google Group or email. As always, we are available to help you build your app in any way we can, so don’t be shy to reach out.

This blog post was the first of a three-part series on architecting your Firebase app. We’ll be following up with more tips, so make sure to follow us on Twitter!

Starting today, developers can power their native iOS applications with Firebase. Our brand new SDK brings the same ease-of-development, real-time updates, and automatic scaling found in our JavaScript API to developers building apps in Objective-C.

Why Is This Significant?

Apple has sold more than 500 million iOS devices to date[1], and there are more than 800,000 apps in the App Store[2]. Even today, however, most apps are not built for effective communication between users. Many apps lack collaboration features altogether, and those that have them generally don’t provide live updates. Users are forced to “Pull to Refresh” to see new events and then must watch a spinner while the data loads. Firebase eliminates “Pull to Refresh” and keeps your users engaged by delivering data immediately when changes occur.

Firebase also radically simplifies the development process for creating apps. In many cases, Firebase can act as a complete backend, eliminating the need for you to run your own servers. Our iOS SDK allows for easy data storage and our Firebase Simple Login support for iOS means that user authentication can be handled without custom server code as well.

Mobile is Where Firebase Shines

With Firebase, unreliable network connections won’t break your app. The Firebase SDK maintains a local data cache for quick access, and our sync-based API automatically compensates for network latency, helping you build highly responsive apps. If a network connection is lost entirely, Firebase apps will remain responsive and automatically handle resynchronization when a network becomes available again.

Examples

To see a live example of a Firebase-powered iOS app, check out SF Live Bus in the app store. It shows a real-time view of the location of every bus in San Francisco. You can check out the code for this app on Github. We’ve also put together a simple chat example for iOS.

Our iOS SDK has already gone through several iterations in a private beta, so you can feel comfortable knowing that production apps have already been built with it. Some examples include:

• Gempad - Turn your iPhone into a third input device for your computer.
• DiscoSync - Silent Discos available right through your iPhone. This app won $25,000 at the 2013 LAUNCH Hackathon.

Getting Started With the iOS SDK

Our iOS Quickstart Guide will walk you through downloading the SDK and setting up your project in Xcode. We’ve worked hard to make the SDK simple and easy to set up. You’ll be able to start replacing “Pull to Refresh” with real-time updates in a matter of minutes.

The Future

Our goal is to provide data access from anywhere, on any platform, in any language. We know we’re only just getting started on this mission, but stay tuned as we’ll be announcing new ways to access your data and support for new platforms soon.

Developers have been able to use Firebase in their Node.js projects for many months. Today, we’re formalizing our commitment to Node by publishing Firebase as a packaged module. We haven’t done this until now because our wire protocol was still in flux. This meant that any changes we made could potentially break our developers' apps.

As of today, however, the wire protocol has been tested well enough with real production apps that we are ready to declare it “stable”. This means that we are guaranteeing continued support for the current version and any libraries that depend on it.

As a result, we've published Firebase to the npm to make it more accessible to Node.js developers. You can install it with the following command:

npm install firebase

Here's a simple example of using Firebase in Node.js:

var Firebase = require('firebase');
var dataRef = new Firebase('https://myprojectname.firebaseIO-demo.com/');
dataRef.set("hello world!");

Installing the Firebase package will also install the firebase-token-generator package. This allows you to create authentication tokens on your own servers and is one of the three authentication options we offer. Here's a quick example:

var FirebaseTokenGenerator = require("firebase-token-generator");
var tokenGenerator = new FirebaseTokenGenerator(YOUR_FIREBASE_SECRET);
var token = tokenGenerator.createToken({uid: "1", some: "arbitrary", data: "here"});

You can learn more about our token generator for Node.js here.

If you want to learn more about our Node support, a good place to start is our Node.js Quickstart Guide. You may also be interested in our Firebase Work Queue project on Github, which shows how Firebase can be used as a job queue for Node.js.

We’re excited to better serve the vibrant Node community, and we can't wait to see what you build!

Since launching last year, we’ve received a steady stream of feedback from developers asking to use Firebase in their Chrome extensions. A Chrome extension is actually a perfect candidate for Firebase, since unlike a traditional web app, you don’t even need a server to host your HTML and JavaScript. The entire app lives in the browser.

This browser-hosted app model is great if your app lives in isolation, but what if you want to store and retrieve data outside of your extension? Or perhaps let users of your extension collaborate with one another?

As of today, you can use Firebase! We’ve updated Firebase to work even in the limited execution environment that Chrome extensions run in.

To get started, we have a sample extension on github you can fork. Or you can create your own extension from scratch and add the following snippet to your manifest.json to allow your extension to access Firebase:

"content_security_policy": "script-src 'self' https://cdn.firebase.com 
https://*.firebaseio.com; object-src 'self'"

Once you’ve added that snippet, you can include firebase.js in any extension page, background page, or content script, and use the JavaScript API just as you would use it in any other web app.

We look forward to seeing your Firebase-powered Chrome Extensions — happy hacking!