When I started designing the tech stack for Reviewable I knew I wanted something lightweight that would allow a lone developer (me!) to put together a high quality, modern web app quickly. Most of my past experience had been with traditional client-server architectures communicating via a RESTful API, but the overhead of designing and maintaining a URL space, a complex database schema, the obligatory glue code between them on both client and server, sounded unappealing. And this is even before considering fun stuff like security, scalability, and collaboration.
As it happens I’d recently built a prototype for another project on top of Firebase and was surprised with how easy it was to work with the platform and how fast the app came together. While I initially had some qualms about whether it was mature enough to stand up to the rigors of long-term use in production, I had faith in the team and figured that shipping an MVP quickly trumped other concerns. So I decided to give it a try.
The first order of business was to set up some way to serve the app. Firebase is well-suited to a single page app (SPA) architecture, where a static bootstrap page on the client executes JavaScript to grab data from a server and renders HTML templates in the browser. Because the bootstrap page is static there's no need for a seperate application server, so all files can be served from a CDN for low latency and scalability.
I had previously tried a number of CDN solutions but never found a good combination of features and price. I saw that Firebase recently launched their integrated hosting feature with built-in support for SSL, cache control, and instantaneous file invalidation and decided to give it a try. The best part was that Firebase Hosting also supported URL path rewriting—a necessity for a modern app that uses the HTML5 History API to control the URL, while still requiring URLs to load the same static bootstrap page.
As an example, whether you visit Reviewable at https://reviewable.io or its demo code review at https://reviewable.io/reviews/Reviewable/demo/1, the same HTML page is initially sent to the browser before being populated with data from Firebase. This is easy to achieve with Firebase Hosting using a firebase.json configuration file like this:
https://reviewable.io
https://reviewable.io/reviews/Reviewable/demo/1
firebase.json
{ "firebase": "reviewable", "rules": "rules.json", "rewrites": [ {"source": "**", "destination": "/index.html"} ] }
This worked great for staging and production, but what about development? I didn't want to deploy the site to test it every time I made a small tweak, since even a few seconds' delay would disrupt the development flow. And a normal development HTTP server like python -m SimpleHTTPServer or node http-server would only serve files that directly matched the URL structure, unable to deal with path rewrites.
python -m SimpleHTTPServer
node http-server
To solve the problem, I quickly built the firebase-http-server tool that understands the configuration file and mimics how Firebase Hosting works. It's fast and dead simple to use, defaulting to reading the settings from a firebase.json file in the current directory:
npm install -g firebase-http-server firebase-http-server # load your site from http://localhost:8080
Presto, you have a running server that respects all your redirect, rewrite and header rules. The emulation isn’t perfect but it’s close enough for development work, and changes to the configuration or source files take effect instantaneously.
Another critical part of every Firebase application is writing the security rules that determine read/write access to the datastore and validate your data. Having all the rules in a central location and enforced in the datastore itself is a great idea, and much easier to deal with (and audit) compared to manual checks or annotations spread throughout your codebase. However, the native JSON format of the rules is not very human-friendly at scale, so I was looking for a solution somewhere between Firebase’s existing rules and the experimental Blaze Compiler they recently released. This inspired me to build Fireplan, an open source tool that uses a YAML syntax similar to Blaze together with Firebase’s established hierarchical rule structure.
Here's a fragment of Reviewable's actual security rules written in Fireplan syntax:
root: repositories: $ownerName: $repoName: .read: canPullRepo($ownerName, $repoName) core: connection: required oneOf('active', 'draining', 'closed') connector: userKey # null if connection closed current: openPullRequestsCount: required number && next >= 0 pullRequests: $pullRequestId: string functions: - userKey: string && isUser(next) - isUser(userKey): root.users.hasChild(userKey) - canPullRepo(owner, repo): auth.uid != null && root.users[auth.uid] != null && sanitize(root.users[auth.uid].core.public.username.val().toLowerCase()) == owner || root.queues.permissions[makePermissionKey(owner, repo, '*')].verdict.pull == true || auth.uid != null && root.queues.permissions[ makePermissionKey(owner, repo, auth.uid)].verdict.pull == true - makePermissionKey(owner, repo, uid): owner + '|' + repo + '|' + uid - sanitize(key): key.replace('\\', '\\5c').replace('.', '\\2e').replace('$', '\\24') .replace('#', '\\23').replace('[', '\\5b').replace(']', '\\5d') .replace('/', '\\2f')
Now this may look rather imposing—the function definitions in particular are pretty complex—but look at what it expands to in the native JSON format when compiled with Fireplan using fireplan rules.yaml:
fireplan rules.yaml
{ "rules": { "repositories": { "$ownerName": { "$repoName": { "core": { "connection": { ".validate": "newData.val() == 'active' || newData.val() == 'draining' || newData.val() == 'closed'", "$other": {".validate": false} }, "connector": { ".validate": "newData.isString() && root.child('users').hasChild(newData.val())", "$other": {".validate": false} }, ".validate": "newData.hasChildren(['connection'])", "$other": {".validate": false} }, "current": { "openPullRequestsCount": { ".validate": "newData.isNumber() && newData.val() >= 0", "$other": {".validate": false} }, ".validate": "newData.hasChildren(['openPullRequestsCount'])", "$other": {".validate": false} }, "pullRequests": { "$pullRequestId": { ".validate": "newData.isString()", "$other": {".validate": false} } }, ".read": "auth.uid != null && root.child('users').child(auth.uid).val() != null && root.child('users').child(auth.uid).child('core').child('public').child('username').val().toLowerCase().replace('\\\\', '\\\\5c').replace('.', '\\\\2e').replace('$', '\\\\24').replace('#', '\\\\23').replace('[', '\\\\5b').replace(']', '\\\\5d').replace('/', '\\\\2f') == $ownerName || root.child('queues').child('permissions').child($ownerName + '|' + $repoName + '|' + '*').child('verdict').child('pull').val() == true || auth.uid != null && root.child('queues').child('permissions').child($ownerName + '|' + $repoName + '|' + auth.uid).child('verdict').child('pull').val() == true", "$other": {".validate": false} } } } } }
Gotta love those quadruple backslashes! This rule complexity would be difficult to maintain in large apps like Reviewable, but luckily Firebase picked a good set of core rule semantics which made it easy to add syntactic sugar on top.
The Firebase ecosystem is still growing, but thus far I have not had occasion to regret my choice of platform. Sure it may need the occasional extra tool or library, but it’s still easy to achieve a development velocity that you could only dream of with traditional architectures.
If you have any feedback on Reviewable or any of my Firebase open source projects, I’d love to hear your thoughts. You can find me on Twitter at @reviewableio or email me at piotr@reviewable.io.
Jasko, Robert, Bjarne, Kiarokh and Rick are the team behind SurveyLegend, a platform-independent online survey web application built on AngularJS and powered by Firebase.
SurveyLegend is a company focused on reinventing online surveys. Our software enables users to create surveys with remarkable ease, both on tablets and computers. You don’t need to be a market research expert and you don’t have to deal with installing or updating any software programs. All you need is a browser and SurveyLegend’s web app.
We launched our new survey app in June 2014 to help anyone compile questions that need to be answered in an engaging way. We want to give individuals and companies the power to create mobile-friendly, gorgeous surveys comfortably - with a smile on their face. We feel no other solution in our industry has accomplished this.
With SurveyLegend you create great looking surveys on your computer or tablet wherever you are, customize the look of your survey, and display the results with eye-catching and insightful graphics - all as simple as drag and drop.
So far, the results and responses from our users have encouraged us to reinvent the market research industry through ease of use and a focus on interaction design and visuals.
Firebase is a great fit because of the realtime synchronization it provides. There are no conflicts, data which comes in later overwrites or merges with the old data seamlessly. Without Firebase, we would have to spend much more time solving synchronization issues, and optimizing and scaling our servers. Firebase enabled us to build our app more quickly and let us keep our development team small and focused on our core competence.
With Firebase, survey data is always available for respondents and their responses can always be submitted even if our servers go down. Firebase also powers our Live Analytics feature, which updates in realtime when a survey response is submitted so our users get instant feedback.
Firebase’s security rules make it easy to validate data, implement permissions and keep our users’ data safe. It saves us a lot of time and effort that would go into creating custom solutions.
On the server side, we use Linux machines running on DigitalOcean.Export of survey data is written in PHP and more real-time tasks are using NodeJS and CouchDB. We have several Node servers which act as Firebase-workers. The workers save responses and make backups of survey-data to CouchDB in real-time as well as updating Live Analytics on Firebase.
On the client-side, we develop using AngularJS and AngularFire bindings and many other libraries: Sass, Grunt and Gulp for various build tasks. We plan on moving our apps and static assets to Firebase Hosting in the future to increase the availability of our app and reduce the dependency on our own servers.
We are proud to have users from all sectors: individuals, small local businesses, global companies, nonprofit organizations, government agencies, and other institutions.
We see high school students use our solution to create small yet powerful surveys, asking challenging questions on the topic of bullying. We also see global enterprises running internal employee surveys and external customer surveys. Every day new users join from all over the world to gather much needed feedback, leading to decisive insight into their questions. Whether it’s individuals or global companies using SurveyLegend, we treat them as Legends and are proud to empower them.
We are working on two new features, Media Gallery and Custom Wallpaper. These features will not only help our users create more visually appealing surveys but will also help them create questions with images as answers.
Media Gallery is a question type guaranteed to help retail, design, and marketing companies with their choices in products, design and marketing. With the Media Gallery question type, you can ask a visual question, easily email it out or share it through social media, reaching thousands of people and leading to insightful choices for your design.
Our second feature in the pipeline is the ability to upload custom survey wallpapers. This is a feature that enables companies to further brand their survey using custom company colors or illustrations.
We have many more features on the way and we love getting feedback and feature requests, so don't be shy about contacting us. We look forward to hearing from you!
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
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.
