I've been using Firebase for a couple of months now for an iOS app I'm building for a client, and it has been a fantastic experience.
For anyone who doesn't know, it's main selling point is that it automatically syncs with the server so you can focus on the data instead of the communication protocol or replication. Its nosql data store looks like a local filesystem, so you can save trees of data to it as JSON. It also has server-side rules written in javascript that enforce constraints on data and read/write permissions per user. They also have a free test account for developers.
"What about merge conflicts?" was my first question, but luckily it has transactions on an individual node (and its subtree) that perform an "optimistic-concurrency transactional update" which basically means a compare-and-swap where you review the current value in a callback and decide whether to try to commit that value (or a new value, say, for a counter) or give up. For most other writes, you're usually just saving status updates where there is little or no danger of being rejected or encountering merge conflicts. If in doubt, it's possible to get a callback with the final value.
So when it’s all said and done, I can totally see writing a full-featured app using it without a single line of server-side code. I used their hosting while it was in development to store images (like a CDN) and it’s very simple to use from the console, so if you have a build script, it could push to production with a single call. After an exhausting ordeal battling iCloud for a different project, Firebase is so profoundly better that I will never go back.
Hi HN, I'm the lead developer on Firebase Hosting and the post’s author. We're trying to build something that's both simple to use and a serious production grade product. We think we're pretty close to the mark but we'd love to hear how we can improve it. Let us know in the comments (or email me at chris@firebase.com).
While this isn't specific to hosting, one glaring thing that I've noticed in the documentation / tutorials is there are no clear instructions on how to retrieve data. In the Getting Started link at the top of your site, theres a section that says 'Save Data', but nothing for 'Retrieve Data'. And the documentation isn't any clearer.
Take a look at the "Reading Data From Firebase" doc (https://www.firebase.com/docs/reading-data.html). If you've got some feedback on it or think it isn't clear enough, I'd be happy to chat with you and see how we can improve the docs.
Thanks for the response. I have, and its simple enough from the perspective of a developer that has been in the field for a little while, but since these services are getting more and more popular it seems like striving for absolute clarity might pay off in the long run.
For example,
1. Its not totally clear that the url that you are supposed to use is the url that is generated when you create a new app and land inside of Forge.
2. Its also not totally clear that in retrieving data you're supposed to follow the structure of you JSON schema. A simple note along the lines of "If you would like the retrieve the third index in your array, its as simple as creating a new Firebase instance and passing in 'mydata.firebaseio.com/3' as the url.
3. Like I mentioned in my first comment, it would be good if you had a 'Retrieve Data' bullet point on your getting started page. For users who simply want to import JSON into Forge to display in their app via retrieval, a two line note and example along the lines of
Retrieve Data
user = new Firebase('mydata.firebaseio.com/users/3')
user.once (userData) ->
console.log userData.val() # Should return Kim Gordon
would help.
There are little things (and I emphasize little here) scattered throughout which would lead less experienced devs into a bit of confusion when first getting started.
If I'm being overly cautious here please disregard, but it did hang me up when I first started playing around with the system.
Either way, totally love the hosting and super psyched to dive deeper into the platform!
I agree with cnp. I think it would've been much easier to grasp if the URLs worked like most APIs. For instance, I expected this URL https://samplechat.firebaseio-demo.com/users to return the users as JSON instead of the html data dashboard. This slowed me down more than anything when I started. I think it would be helpful to have both the data dashboard and the raw data, but on separate URLs. But generally it's awesome!
I really appreciate the great feedback! I will take another look at the doc sections you mentioned and see how I can work in your comments without getting too verbose. I think that since the people who write the docs are the ones who make the API, we take some things for granted which we shouldn't. The only way to find that out is to get great feedback from people like you, so thank you!
Also, glad to hear you like the hosting! We're really proud of what we launched today and have a lot of plans for it into the future. If you have any more suggestions, feel free to email me. You can find my email in my profile.
Firebase gives you the ability to create dynamic pages with no backend requirement. This left a really small gap that the developer still had to host that HTML/JS page somewhere. So Firebase already supplied the backend now they also supply the hosting.
In short, both. :-) This was a commonly-voiced pain point for our existing customers and fits very well with our vision to make Firebase the best platform for building modern apps.
But when we do something, we like to do it "right" and so we also think Firebase Hosting comes with a very compelling feature set (Simple Deploy/Rollback, Automatically-provisioned SSL, and a global CDN). So we're optimistic it'll also attract new developers to the Firebase platform.
It would be nice if you could add some latency benchmark against common alternatives like S3. A lot of ppl use that for static webpages, but I wonder how lack of CDN affect the user experience.
I guess comparing to CloudFront would be helpful, too. If you've gone so far as hosting on S3, serving through CloudFront is about 5 minutes of additional effort.
Great suggestion! The difference between being on a CDN and not is really night and day. Every serious site deserves to be on a CDN. Your users will thank you for the faster page loads. :-)
Would someone here kindly be able to comment about the usability of Parse vs. Firebase vs. AWS JS SDK? I've looked into all three. They seem comparable because they are "no-backend" solutions and NoSQL stores.
It seems like the AWS JS SDK is the youngest, least mature (there are surprisingly few results on Google), and perhaps most difficult to use, but it's sure nice that I can manage my existing AWS stuff with a client-side JS SDK, now. If you use AWS JS SDK with DynamoDB, isn't it as if you've built your own Firebase?
I've used both Parse and Firebase extensively and I love them both. Parse is far more mature. Not only has it been around for longer but it's owned by Facebook so it has the resources to continue adding amazing stuff, like Cloud Code. Cloud Code is a huge differentiator in my opinion because it takes care of the last mile for BAAS' (back-end(s) as a service) - custom server-side data validation and manipulation.
However, Parse's SDK follows a very Backbone-like syntax with setters and getters which I'm not all that thrilled with (as an Angular developer) and has no real-time functionality to speak of (outside of push notifications). That's where Firebase shines. Firebase is newer but is maturing very quickly. Their system is solid and pretty much "solves" realtime for all intents and purposes. They don't have a Cloud Code equivalent and search is pretty much non-existent at this point but those are solvable problems I'm sure they will tackle in the not-so-distant future.
What it comes down to is what type of app you're building. And by the way, there's no reason you can combine them to get the best of both worlds :)
Firebase may not have Cloud Code, but since you have use their npm module and deploy to a free hosting service like Heroku, I actually think its more powerful. The big win: once you are in a full node.js environment you can leverage the power of all the npm modules. Parse's Cloud Code is very isolated from the entire ecosystem.
This is a big question, and I'm biased by working at Firebase, so I'd welcome somebody from the community chiming in with their experiences. But one key differentiator worth mentioning is the realtime aspect of Firebase.
We believe that modern apps should be client-side apps that update in realtime as changes happen, without having to refresh the page or continually poll the server for updates. So this is baked into the core of Firebase. All of our features and APIs (and our new Hosting service!) were designed around this concept of how modern apps should be built.
Building with Firebase was always a bit of a pain since I had to use at least two services (Firebase + S3). This is really great. I've got a dozen or so static page apps that could use this right away.
Non-SNI device support & naked domain support are awesome features. I’d like to see a bit more customization around the routing / DNS still. It would be nice if I could host different versions of my app on different subdomains (staging, etc). Apex hosting is a nice touch too. Overall this is a great entry to the PASS space.
One nice thing about Firebase Hosting is that they're the only static site provider I could find that will render html in response to a POST request. When you make a Facebook Canvas app, they expect you to serve your site via POST. If you host on github or something, you just get a 400 error.
Firebase is a revolutionary tool, and this is the last piece that was missing from the big picture. It's hard to imagine a Firebase-driven world today, but in 5 years developers will need to quickly deploy and iterate on real-time applications, for which a system like this is ideal. Lay out your database, set up login and security rules, and deploy your application, all through the same service.
However, the lack of benchmarks is a bit disconcerting. Hosting and SSL are great, but if the page loads are slow I'd rather pay money to host them elsewhere.
Also, there is the single-point-of-failure problem, which materialized yesterday when Firebase went down. Although the outage was only for a couple minutes (a lot faster than it would take me to troubleshoot a downed Rails app), it made me realize the dangers of relying on a single system for all of your web application's needs.
Overall, I think Firebase is just going to get better and better. They still need to integrate payments, file upload, and the ability to make API calls to external services, but by adding hosting they are demonstrating a desire to provide services for the full stack. Also, there is a brilliant team of people behind Firebase, so I'm sure that my ideas for Firebase are only the tip of the iceberg.
Have to agree with this. We built Webhook.com on top of Firebase, and it's been transformative. We built a CMS system similar to Wordpress that loads on a single cms.html page that loads off a static server. Its just, well, I never thought it'd be possible.
Service has been excellent.
Doing everything through JSON was initially a little different. There's a lot of times when you really want things to be relational and although you can come up with interesting ways to do it, most of it is tedious. That's really my only complaint and is pretty specific to what we're building. Other than that I really do see this model of storage as the future. Really, really impressive stuff.
Thanks for the feedback! We'd love to know what benchmarks would make you feel more comfortable. Internally, we have a lot of monitoring and diagnostics to make sure everything is running optimally. Downtime like yesterday's is rare and will become even rarer as we continue to advance our infrastructure.
In general, I agree with your point though. That's why I'd recommend using 3rd-party monitoring / measurement, even if we did expose more benchmarks for you. It's important to understand your external dependencies and verify they meet the service level you require.
Brilliant work guys. Choice of initial features seems right on for a developer focused hosting service. At first I was a bit confused by the SSL offering for custom domains, until I saw that firebase actually acquires the cert and configures it. That's a huge pain point, bravo.
What about bots (search engines, social media bots, etc.)? If a web app has both static content and dynamic content (based on data in the firebase db) how can bots see a rendered version of the page. Do you have a way / plan for users to install middleware to check for bots and if so return pre-rendered content. ( Middleware details: http://webcache.googleusercontent.com/search?q=cache:8k8JuuU... ). Thanks in advance!
Great question. This is a very real pain point with dynamic content in today's world of bots / crawlers. Many sites right now are completely or partially invisible to crawlers.
As you point out, pre-rendering content is the prescribed way to solve this and there are some existing solutions (prerender.io, brombone, etc.) that are a good start, but this is still a confusing / hard problem for people to solve when they'd like to focus on building their app instead.
So we're keenly looking into how we can best integrate with these sorts of services or provide our own solution as part of our hosting offering. Stay tuned!
Upvoted solely for the description of how modern web-apps should be developed!!! So many people have legacy, server-side attitudes... JavaScript is treated like a special cousin that can raise alert boxes and things...
It's all cyclical, and I've seen enough cycles now. The trend always oscillates between heavy clients and heavy servers. They each have their strengths:
Heavy Client: simplified backend management
Heavy Server: clients all run the latest software (no versioning)
There is (and will never be!) a silver bullet. Development is always tricky.
Not buying the latest version argument for a web app... But I am sure you're right that it is cyclical from a wide view. It seems to me that all human endeavour is. Additionally, all choices have a benefit and opportunity cost - everything in life is a trade-off...
Seems to me, in the case of a world where bandwidth is scarce and processing power is ubiquitous, that the fat-client, thin-pipe model is where it's at. :)
How many cycles have you seen? Are they really comparable? Doesn't each one need to be treated specially and considered independently?
So far I have been using site44 (http://www.site44.com/) to accomplish this already. I see that you guys have built some node apps to make deploying and rolling back easy, which is smart. I have found the way site44 works (it's a dropbox app that updates what's being served automatically when the dropbox folder contents change) to be very convenient.
It may be interesting for you guys to consider doing something similar.
Thanks for the feedback! Now that we've got the core deploy / rollback tooling in place, we're definitely looking for ways to plug into other common workflows (git, Dropbox, etc.). Stay tuned!
Git integration is on our roadmap. However, you can also set this up yourself now by adding your own git hook that calls 'firebase deploy' on push.
For more information, see the documentation for the commandline tool here: https://www.firebase.com/docs/command-line-tool.html
Why are connections always the selling point for these real time services? Are they actually the most expensive thing to scale or just the most required therefore most profitable?
Edit: The surcharges for going over the limits seem a bit high. (Candle Plan: $0.25 each additional connection). Get some spike in traffic that causes 2000 visitors to your site for an hour and pay $500 lol
Billing is based on 95th percentile usage, so you wouldn't have to pay overages if you exceed the limits for a couple hours (e.g. you got front-paged on TechCrunch, HN, or Reddit)
For context, 2000 concurrent connections would be quite a large site. If you're hitting 2000 concurrents, $500 probably wouldn't be an issue for you. It's also worth noting that Firebase employs burstable billing at the 95th percentile, so only sustained overuse within the monthly billing period will result in a surcharge.
As for why we charge for connections in general, they do tend to be the most expensive thing to scale. They're also useful as a proxy of how "big" a site is (in terms of users). They're kind of the analog to "page views" in today's world of single-page-apps that update in real-time
Congrats Firebase team! I've used Firebase hosting while it was in beta, and had a great experience. Very easy to setup and follow even for someone like me who has very little experience with servers/deployment.
They're also super friendly to their community and always responds to questions fast :-) would love to see more awesome stuff coming from them.
I've built some client / server syncing code for a while, and never wondered to check for papers on that subject ( since i did it in a wqy specific to my model each time). What those guys are doing seem quite generic. Are there any famous algorithms for multi end-point data syncing ?
I suppose it's related to the ditributed database research field...
Thanks, i already knew about this one. I was looking to something more specific to single server / multiple clients that need to sync.
It seems a bit different to the type of algorithm used when trying to reach a concensus between multiple servers upon a read request ( or is it ?)
Edit : when i said related to ditributed database, i related more to things like log shipping.
I am building a financial services app and was using Angular and Firebase. I absolutely loved my development time with Firebase. It really complements Angular nicely and helped cement (in my head at least) what the role of the server in a modern app should be.
That being said, I decided that Firebase is not quite ready yet for my own app's requirements (for financial data I need data-at-rest encryption and on-premise hosting for my clients), but I wish them all the best and highly recommend them for anyone whose apps do not have the same constraints that mine does.
FWIW, my Firebase-like alternative is Node.js + SockJS + MongoDB. I'm looking into Feathers.js as well. It doesn't seem to be very widely used, but looks like it will provide some of the basics (service hooks, event hooks, etc.) on top of Node/SockJS that I will need.
We're building a single page app. Is it possible to use Firebase Hosting only for SSL and static assets and our own servers(exposing REST APIs) for dynamic content?
Yes, although the real-time database that comes packaged with a paid plan wouldn't be used. If you're looking to fully utilize Firebase you could add a live chat feature or real-time commenting to your existing website, while maintaining your existing API for dynamic content.
You can make everything Firebase-related happen at the JavaScript level (which is why hosting is valuable to Firebase users in the first place).
Yes. We think our hosting service and realtime backend complement each other nicely for building modern web apps, but you certainly don't have to use both. :-)
This solves a major headache for me. I have a production app built using Angular and Firebase and I was up until this point using Amazon S3 hosting to host my static assets. It was a beautiful thing - I don't have to maintain any server side code. But it was annoying having to deal with Amazon and their stale, obtuse documentation. I will definitely be moving my static files over to Firebase. It's one less service I have to worry about.
This is great. I am using Firebase for my app https://remoteinterview.io . And yes my current build/deploy system is a bit long due to FTP. Will try this out.
Thank you :)
Yes it has grown out of hackathon size hack now. But we built the initial prototype within a weekend. Firebase really helped in speeding up things.
How do integrate business logic on the back end ? Do we implement EventSource / Server-Sent Events protocol and have a server on our back end that is basically the logic server ?
Also have any one done a C# wrapper for your REST layer ?
I've hosted my FB apps on Github up to this date but am very pleased to see they have added the features that a go beyond a simple static site deployment. I'm especially excited about the SSL support.
For my app i use other databases (MySQL) along with Firebase. Does firebase hosting allow me to host MySQL or connect to a MySQL instance on another hosting provider like AWS?
It seems like firebase is good if you're making a CRUD app. But if yours is media heavy with pictures and video, using something a little lower level is needed.
For anyone who doesn't know, it's main selling point is that it automatically syncs with the server so you can focus on the data instead of the communication protocol or replication. Its nosql data store looks like a local filesystem, so you can save trees of data to it as JSON. It also has server-side rules written in javascript that enforce constraints on data and read/write permissions per user. They also have a free test account for developers.
"What about merge conflicts?" was my first question, but luckily it has transactions on an individual node (and its subtree) that perform an "optimistic-concurrency transactional update" which basically means a compare-and-swap where you review the current value in a callback and decide whether to try to commit that value (or a new value, say, for a counter) or give up. For most other writes, you're usually just saving status updates where there is little or no danger of being rejected or encountering merge conflicts. If in doubt, it's possible to get a callback with the final value.
So when it’s all said and done, I can totally see writing a full-featured app using it without a single line of server-side code. I used their hosting while it was in development to store images (like a CDN) and it’s very simple to use from the console, so if you have a build script, it could push to production with a single call. After an exhausting ordeal battling iCloud for a different project, Firebase is so profoundly better that I will never go back.