Although it seems like we just moved into our old space not long ago, we’ve already outgrown it! On March 1st we moved again, to a new office in the heart of downtown San Francisco.
The new office is at 22 4th Street, conveniently located near the Powell BART/Muni Metro station. It’s a perfect spot to continue to grow our team. We’re excited for more conference rooms (we were starting to spill out into the hallways of our old office), panoramic views of the San Francisco skyline, and a large area for meetups.
We want to make the space uniquely our own. At our office warming party two weeks ago we invited developers from our community to paint our walls with whatever inspired them. We’re really pleased with the results!
Not to be outdone by our community, we’re having an internal competition to see who can furnish and decorate the best looking conference room.
The Firebase office will be open to the local developer community to host meetups. We’re starting by hosting the SFJS meetup on May 8, 2014. If you’re interested in us hosting your local meetup please drop me a note. With our new office we have a lot more room to grow, and we are! If you want to build something that helps developers create extraordinary experiences, we’re hiring!
Two years ago today there was a torrential downpour in San Francisco. Despite the abysmal weather, a group of 250 friends and passionate technologists came to see Andrew, Vikrum, Michael and I introduce Firebase to the world.
Vikrum, who doubles as our Head of Operations and our Chief Naming Officer, codenamed the product ‘Plankton’ when we started coding in the fall of 2011. As 2011 turned into 2012 we found a name we loved, iterated on our API, and systematically gathered feedback from an incredible group of developers -- many of whom presented their own Firebase-powered apps at our launch on the rainy night of April 12th, 2012. (Thanks Sara, Judy, Smita, Ted, Jeff, Felix, Melih, Joey, Ben, & Mehul!)
The past two years have been incredible. We’ve consistently been astonished with the support you’ve shown for both our product and our team. You’ve built things on Firebase that we never dreamed of, and your creativity and enthusiasm inspire us to keep making Firebase better every day.
Our community just crossed 62,000 developers and is growing every day. Our team is now 15 people strong with 2 more joining soon, and we’re hiring!
Some of the highlights from the past two years include:
We’ve got a number of great new features and improvements coming in the next few weeks and months. Follow us @Firebase on Twitter for the latest news, email firebase-support@google.com with technical questions, and join our Google Group to get involved with our developer community. We can’t wait to see what you build.
Finally, here’s the video from our launch two years ago!
Yesterday the OpenSSL Project released an update to address the "Heartbleed" vulnerability. This is a serious vulnerability that allows an attacker to see the contents of memory on a server. Given the widespread use of OpenSSL and the versions affected, this vulnerability affects a large percentage of services on the internet.
Although the Firebase realtime servers were unaffected by this exploit, our servers managing authentication to the Firebase website were vulnerable. This could have allowed an attacker to obtain authentication credentials while they were in-flight. Internally we protect passwords by hashing them using bcrypt, but that precaution did not help given the nature of this exploit.
Once the exploit was revealed our infrastructure team responded immediately and all Firebase services were secured the same day, by 11pm PDT on Monday, April 7. Firebase is no longer vulnerable to this exploit.
We do not have any evidence that passwords or any other private information has been compromised. However, given that this exploit existed in the wild for such a long time, it is possible that an attacker could have stolen passwords without our knowledge. As a result, we recommend that all Firebase users change the passwords on their accounts. We also recommend that you reset your Firebase Secrets, which you can do from the "Secrets" tab in your App Dashboard.
The safety and security of our customer data is our highest priority. We are continuing to monitor the situation and will be responding rapidly to any other potential threats that are discovered.
If you have any questions or concerns, please email us directly at security@firebase.com.
We’re excited to announce that the Firebase REST API now supports streaming! This means you can add realtime notifications to your Firebase app on currently unsupported platforms. We’ll outline how to get started with the new streaming protocol, and then we’ll dive into some Ruby and Python examples that make use of streaming.
Streaming changes to a location in your Firebase is the equivalent of attaching a single listener to a Firebase reference on any of our client libraries. The new streaming feature makes use of the EventSource / Server-Sent Events protocol, an API for creating an HTTP connection for receiving push notifications from a server.
To stream changes to a single location in your Firebase, you’ll need to set the client’s Accept header to “text/event-stream”.
You’ll also need to be sure your app respects HTTP Redirects, specifically HTTP status code 307. The Firebase servers will direct your client to the correct machine for the data that you want to stream via a URL specified in the Location header of an HTTP 307 response.
If the Firebase location you’re streaming changes to requires permission to read, you must include the auth parameter. The auth parameter is supported by all request types, and authenticates a request to allow access to data protected by your Security and Firebase Rules. The argument can either be your Firebase Secret or an authentication token. Here is an example:
curl \ https://SampleChat.firebaseIO-demo.com/users/jack/name.json?auth=CREDENTIAL
As the data at your Firebase location changes, the server will send named events in the following structure:
event: event name data: JSON encoded data payload
The structure of these messages conforms to the EventSource protocol. The server may send the following five event types: put, patch, keep-alive, cancel, or auth_revoked. Here is one example of a set of events returned from the server:
put
patch
keep-alive
cancel
auth_revoked
// Set your entire cache to {"a": 1, "b": 2} event: put data: {"path": "/", "data": {"a": 1, "b": 2}} // Put the new data in your cache under the key 'c', so that the complete cache now looks like: // {"a": 1, "b": 2, "c": {"foo": true, "bar": false}} event: put data: {"path": "/c", "data": {"foo": true, "bar": false}} // For each key in the data, update (or add) the corresponding key in your cache at path /c, // for a final cache of: {"a": 1, "b": 2, "c": {"foo": 3, "bar": false, "baz": 4}} event: patch data: {"path": "/c", "data": {"foo": 3, "baz": 4}}
Check out the Streaming documentation for a full explanation of each event type.
We’ve created a simple command line chat client in Python and Ruby to demonstrate the REST API’s new streaming feature. Both chat clients have the same architecture:
A thread to manage the UI
Simply clone the EventSource-Examples repo on GitHub to get started.
We encourage you to try out the new streaming feature and let us know what you think. If you have any questions or feedback, post them in our Firebase Google Group or email me at greg@firebase.com. Submit a pull request to our example repo if you have any streaming examples you’d like to share.
We’re excited to see what you create!
Just in time for EmberConf next week, we’re excited to announce a new version of our EmberFire bindings, along with an example blogging app to showcase the magic of using Firebase with Ember.
Our new Ember bindings now work directly with Ember Data. This means you can now use Ember Data’s relationships with Firebase to define hasMany and belongsTo relationships between your models. If you’re new to Ember Data, Ember’s guide to models is a great place to start.
With these updates, EmberFire now works only with Ember Data. For Ember developers who aren’t using Ember Data, Michael Jackson has written ember-firebase - an awesome, thoroughly tested set of Firebase bindings for Ember. If you’d still like to use the previous version of EmberFire, it is available in the v0.1.0 release on GitHub.
With our new bindings, you can start using EmberFire in just two steps. First, you’ll need to include the necessary libraries:
<head> <!-- Ember + Ember Data --> <script src="http://builds.emberjs.com/canary/ember.min.js"></script> <script src="http://builds.emberjs.com/canary/ember-data.min.js"></script> <!-- Firebase --> <script src="https://cdn.firebase.com/js/client/1.0.17/firebase.js"></script> <!-- EmberFire --> <script src="https://cdn.firebase.com/libs/emberfire/1.0.13/emberfire.min.js"></script> </head>
You can also download EmberFire and all its dependencies from Bower via bower install emberfire --save.
bower install emberfire --save
Then, simply create an instance of the DS.FirebaseAdapter in your app and add your Firebase URL:
DS.FirebaseAdapter
App.ApplicationAdapter = DS.FirebaseAdapter.extend({ firebase: new Firebase('https://<my-firebase>.firebaseio.com') });
With the adapter set up, you can now interact with the data store as you normally would with Ember. For example, calling find() with a specific ID will retrieve that record from Firebase. It will also start watching for updates and will update the data store automatically whenever anything is added or removed.
To help you understand our new EmberFire bindings we’ve created FireBlog, a realtime blogging app with posts, comments, and users. We’ll walk through the core concepts here, and the full code is available on GitHub.
Because both Ember Data and Firebase work best with denormalized data, FireBlog does not embed comment data directly in each post. Instead, each post has a comments object with a comment ID pointing to the comment data in /comments. We’ve created three top-level keys for posts, comments, and users, and the data structure in Firebase looks like this:
/comments
Each post in our blog will have a title, body, published, user, and comments attributes. Using Ember Data’s relationships, each post belongsTo a user and hasMany comments. We’ll use Ember’s computed properties to format the date to display on the blog post.
App.Post = DS.Model.extend({ title: DS.attr('string'), body: DS.attr('string'), published: DS.attr('number'), publishedDate: function() { return moment(this.get('published')).format('MMMM Do, YYYY'); }.property('published'), user: DS.belongsTo('user', { async: true }), comments: DS.hasMany('comment', { async: true }) });
The comment and user models are set up in a similar way, which you can see on GitHub.
To get all blog posts from Firebase we can use the standard Ember Data way of fetching posts, like the following:
App.PostsIndexRoute = Ember.Route.extend({ model: function() { return this.store.findAll('post'); } });
This will fetch all posts when the page first loads, and will also listen for updates to Firebase. Whenever posts are added, the data store will update automatically and new posts will be displayed in the DOM.
Similar to how we fetched all posts using store.findAll(), we’ll fetch individual posts using store.find():
store.findAll()
store.find()
App.PostRoute = Ember.Route.extend({ model: function(params) { return this.store.find('post', params.post_id); } });
We'll use the following template to display a single post. Then we'll create an Ember.Component to display individual blog posts. We'll pass in the model from the route (post=model) as a property to show the post's title, author, date, and comments:
Ember.Component
<script type="text/x-handlebars" data-template-name="post"> {{ "{"}}{{ "{"}}fire-post post=model onPublishComment="publishComment"}} </script>
Here is the App.FirePostComponent we use to display an individual blog post:
App.FirePostComponent
<script type="text/x-handlebars" data-template-name="components/fire-post"> <div class="post-header"> <img {{ "{"}}{{ "{"}}bind-attr src="post.user.avatar"}} class="avatar post-avatar"/> <div class="post-author">{{ "{"}}{{ "{"}}post.user.id}} <div class="post-date">{{ "{"}}{{ "{"}}post.publishedDate}} <h3 class="post-title">{{ "{"}}{{ "{"}}post.title}}</h3> <div class="post-content">{{ "{"}}{{ "{"}}breaklines post.body}} <ul class="post-comments"> {{ "{"}}{{ "{"}}#each comment in post.comments}} <li class="post-comment"> <img {{ "{"}}{{ "{"}}bind-attr src="comment.user.avatar"}} class="avatar post-comment-avatar" /> <div class="post-comment-body"> <div class="post-comment-meta"> <strong class="post-comment-author">{{ "{"}}{{ "{"}}comment.user.username}}</strong> <em class="post-comment-date">{{ "{"}}{{ "{"}}comment.publishedDate}}</em> {{ "{"}}{{ "{"}}breaklines comment.body}} </li> {{ "{"}}{{ "{"}}/each}} </ul> </script>
Now we have a full-featured blogging application that displays posts and comments in realtime without a server. It’s that simple!
Our goal with the new EmberFire library is to make the process of adding a backend to your Ember app and integrating with Ember Data as seamless as possible. We encourage you to take our new bindings for a spin. Submit a pull request or email me at adam@firebase.com with any feedback. We’re just getting started with this new Ember Data integration, and we’re working hard to make updates based on your suggestions. We’re excited to see what you build with Firebase and Ember.
For those of you going to EmberConf, look for James, Alex, Sara and I in the bright yellow t-shirts!
