Six months ago we released Firebase Hosting! We’ve been amazed by the apps you’ve deployed and we’re excited to see many more to come. Since the launch, our hosting service has had 99.99% uptime and we've seen nearly 6,000 websites deployed a total of 100,000 times. These sites have uploaded more than 700 GB of HTML, CSS, JavaScript, image data, and more to their websites, and many of them are using Firebase to host their own custom domains - including Pathwright and Thinkster.io. If you haven’t tried Firebase Hosting yet, you can dive right in by watching our screencast or checking out the five minute quickstart.
After getting feedback from developers using Firebase Hosting in development and production, I want to share some hints on using the hosting tools effectively.
A common question we see is how to manage different environments with hosting. To start, I’d recommend creating a separate Firebase for each environment (i.e. my-app-dev, my-app-staging, my-app-prod). With our Hacker Plan you can create up to ten free Firebases, and creating multiple Firebases allows you to test things like rewrite rules and redirects before deploying to production. If you have a deploy script, you can easily switch out the name of your Firebase in your app to match your current environment. Only Firebases with a custom domain need to be on a paid plan for Firebase Hosting.
The firebase-tools repo is constantly being improved and a lot of the features explained here have been added since v1.0.0. If you’re on an older version make sure you’ve updated to the latest by running:
npm update -g firebase-tools
You can just as easily run Firebase tools from a script as you would from the command line. Here are a few hints that might make things a little easier:
-s
--email
--password
~/.firebaserc
firebase
firebase.json
--firebase
firebase deploy
Many of you have requested support for uploading user-generated content like images and files in hosting, and improved SEO support in single page apps. Thank you for your feedback - these features are definitely on our roadmap.
We’re always looking for more ways to improve hosting and we’d love to hear what you think. Share your feedback or show us an app you’ve deployed with hosting in our Google Group or mention @Firebase on Twitter.
Yesterday we were at Google Cloud Platform Live in San Francisco. We had a great time introducing developers to Firebase through our booth and two presentations.
Things got started with the keynote, where there were several great new Cloud Platform products announced, including Google Container Engine (GKE) and Google Cloud Interconnect.
Here’s the video from my section of the keynote, where I announce a brand new Firebase feature -- richer querying in Firebase.
Later in the day my co-founder, Andrew, led a session that demonstrated how to create an iOS app with Firebase and built it live on stage in Swift! You can watch his talk and the live coding awesomeness here:
Throughout the day, the Firebase team chatted with developers at our booth and demoed cross-platform apps powered by Firebase. We’ll be open-sourcing our furniture app, Executive Mover 5000, soon, so stay tuned for details.
We’re thrilled to be part of the Cloud Platform team, and over the next few months we’ll be working on new Firebase features as well as integrations with many of Cloud Platform’s services. Thank you to everyone who came to the event and watched on the live stream.
Today we're launching enhanced query support across our iOS, Android, and Web clients, and the Firebase REST API! You can now query your data by any child key in Firebase. Querying has been a frequently requested feature and we’ve made great strides based on developer feedback since our beta release last month.
This release dramatically improves the way you can query your data in Firebase. With our new querying methods you can order and retrieve your data using a child key, by key name, or by priority. Our existing priorities-based ordering will continue to work, but I encourage you to try out the new queries features as it is much more flexible.
A basic Firebase query starts with one of our orderBy functions: orderByChild(), orderByKey() or orderByPriority(). You can then combine these with five other methods to conduct complex queries: limitToFirst(), limitToLast(), startAt(), endAt(), and equalTo(). Since all of us at Firebase agree that dinosaurs are pretty cool, we’ll use this sample firebase of dinosaur facts to demonstrate how you can write complex, realtime queries. To start, we can use orderByChild() to retrieve dinosaurs ordered by height:
orderByChild()
orderByKey()
orderByPriority()
limitToFirst()
limitToLast()
startAt()
endAt()
equalTo()
var ref = new Firebase("https://dinosaur-facts.firebaseio.com/dinosaurs"); ref.orderByChild("height").on("child_added", function(snapshot) { console.log(snapshot.key() + " was " + snapshot.val().height + " meters tall"); });
Firebase *ref = [[Firebase alloc] initWithUrl:@"https://dinosaur-facts.firebaseio.com/dinosaurs"]; [[ref queryOrderedByChild:@"height"] observeEventType:FEventTypeChildAdded withBlock:^(FDataSnapshot *snapshot) { NSLog(@"%@ was %@ meters tall", snapshot.key, snapshot.value[@"height"]); }];
Firebase ref = new Firebase("https://dinosaur-facts.firebaseio.com/dinosaurs"); Query queryRef = ref.orderByChild("height"); postsQuery.addChildEventListener(new ChildEventListener() { @Override public void onChildAdded(DataSnapshot snapshot, String previousChild) { System.out.println(snapshot.getKey() + " was " + snapshot.getValue().get("height") + " meters tall"); } // .... });
curl 'https://dinosaur-facts.firebaseio.com/dinosaurs.json?orderBy="height"'
var ref = new Firebase("https://dinosaur-facts.firebaseio.com/dinosaurs"); ref.orderByChild("weight").limitToLast(2).on("child_added", function(snapshot) { console.log(snapshot.key()); });
Firebase *ref = [[Firebase alloc] initWithUrl:@"https://dinosaur-facts.firebaseio.com/dinosaurs"]; [[[ref queryOrderedByChild:@"weight"] queryLimitedToLast:2] observeEventType:FEventTypeChildAdded withBlock:^(FDataSnapshot *snapshot) { NSLog(@"%@", snapshot.key); }];
Firebase ref = new Firebase("https://dinosaur-facts.firebaseio.com/dinosaurs"); Query queryRef = ref.orderByChild("weight").limitToLast(2); queryRef.addChildEventListener(new ChildEventListener() { @Override public void onChildAdded(DataSnapshot snapshot, String previousChild) { System.out.println(snapshot.getKey()); } // .... });
curl 'https://dinosaur-facts.firebaseio.com/dinosaurs.json?orderBy="weight"&limitToLast=2'
var ref = new Firebase("https://dinosaur-facts.firebaseio.com/dinosaurs"); ref.orderByChild("height").startAt(3).on("child_added", function(snapshot) { console.log(snapshot.key()) });
Firebase *ref = [[Firebase alloc] initWithUrl:@"https://dinosaur-facts.firebaseio.com/dinosaurs"]; [[[ref queryOrderedByChild:@"height"] queryStartingAt:@3] observeEventType:FEventTypeChildAdded withBlock:^(FDataSnapshot *snapshot) { NSLog(@"%@", snapshot.key); }];
Firebase ref = new Firebase("https://dinosaur-facts.firebaseio.com/dinosaurs"); Query queryRef = ref.orderByChild("height").startAt(3); queryRef.addChildEventListener(new ChildEventListener() { @Override public void onChildAdded(DataSnapshot snapshot, String previousChild) { System.out.println(snapshot.getKey()); } // .... });
curl 'https://dinosaur-facts.firebaseio.com/dinosaurs.json?orderBy="height"&startAt=3'
The best part is that all these queries will update in realtime as the data changes in your Firebase. There’s more I haven’t covered, so be sure to read the documentation for the iOS, Android or Web clients or the REST API to learn about all the new features.
With querying, we’re also introducing a new indexOn rule type to the Firebase Security and Rules language. You can use indexOn to tell your Firebase which child keys your app uses in queries. A node's key and and priority are indexed automatically, so there is no need to index them explicitly. Using indexOn is optional and can be left off for prototyping, but it will dramatically improve performance so you'll want to add it once you've figured out the indexes your queries will use.
While this represents a big step forward in terms of our querying capabilities it also lays the groundwork for even more improvements. We have a number of exciting features in the pipeline for our SDKs, including more queries improvements. And as always, we'd welcome your feedback on what you'd like to see next.
Let us know what you think in our Google Group or on Twitter, and send any suggestions to firebase-support@google.com.
