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.<p>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.<p>"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.<p>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).
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.<p>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 <i>existing</i> 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?
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.<p>Non-SNI device support & naked domain support are <i>awesome</i> 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.<p>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.<p>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.<p>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.
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: <a href="http://webcache.googleusercontent.com/search?q=cache:8k8JuuUs9SoJ:https://prerender.io/how-it-works+&cd=1&hl=en&ct=clnk&gl=us" rel="nofollow">http://webcache.googleusercontent.com/search?q=cache:8k8JuuU...</a> ). Thanks in advance!
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...
This is neat. Thanks for making and sharing this.<p>So far I have been using site44 (<a href="http://www.site44.com/" rel="nofollow">http://www.site44.com/</a>) 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.<p>It may be interesting for you guys to consider doing something similar.<p>Take care.
Hey Firebase team, I really liked how you did the <a href="https://www.firebase.com/tutorial/" rel="nofollow">https://www.firebase.com/tutorial/</a> !
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?<p>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
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.<p>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 ?<p>I suppose it's related to the ditributed database research field...
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.<p>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.<p>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?
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 have a site completely powered by Firebase but hosted on S3/cloudfront, which tbh is overkill for it.<p>I'll be switching to Firebase hosting it tonight!
Why firebase doesn't provide pro-rated refunds on downgrades or refunds? It seems indirectly that locks an unhappy user in. Not cool.<p><a href="https://www.firebase.com/pricing.html" rel="nofollow">https://www.firebase.com/pricing.html</a>
This is great. I am using Firebase for my app <a href="https://remoteinterview.io" rel="nofollow">https://remoteinterview.io</a> . And yes my current build/deploy system is a bit long due to FTP. Will try this out.
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 ?<p>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.
Very cool! I just built and deployed a real-time voting app in literally 10 minutes.<p><a href="https://crackling-fire-7227.firebaseapp.com" rel="nofollow">https://crackling-fire-7227.firebaseapp.com</a>
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.