Introducing Firebase Hosting

https://www.firebase.com/blog/2014-05-13-introducing-firebase-hosting.html

by jamest • 12 years ago

220 75 12 years ago

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.

drTriumph• 12 years ago

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).

jakozaur• 12 years ago

Congratulations on launch!

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.

mikelehen9• 12 years ago

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. :-)

nirvdrum• 12 years ago

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.

taylorbuley• 12 years ago

Can you provide any background on Firebase's thinking for where this, strategy-wise, fits into the platform?

For example, is this supposed to be more of an add-on service for folks who already use Firebase or intended to woo new developers?

mikeryan• 12 years ago

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.

mikelehen9• 12 years ago

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.

cnp4• 12 years ago

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.

jacobawenger2• 12 years ago

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.

asadlionpk3• 12 years ago

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.

jamesmishra• 12 years ago

This is unrelated to the parent topic, but I like your app!

I was planning on designing something similar for an upcoming hackathon, but it definitely would not have been as good as what you already have.

asadlionpk3• 12 years ago

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.

hrrld• 12 years ago

This is neat. Thanks for making and sharing this.

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.

Take care.

mikelehen9• 12 years ago

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!

asadlionpk3• 12 years ago

A git deployment would be great. Similar to heroku I guess.

thomasfromcdnjs• 12 years ago

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

mikelehen9• 12 years ago

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

primitivesuave3• 12 years ago

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)

From https://www.firebase.com/pricing.html:

Because we use 95th percentile billing, you won't be charged for your overages 5% of the time (about 1.5 days each month).

podviaznikov• 12 years ago

http://www.divshot.com/ - provides similar hosting for the static sites.

colevscode• 12 years ago

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.

shiftb• 12 years ago

This is great. I have a site completely powered by Firebase but hosted on S3/cloudfront, which tbh is overkill for it.

I'll be switching to Firebase hosting it tonight!

primitivesuave3• 12 years ago

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.

mikelehen9• 12 years ago

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.

snide• 12 years ago

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.

pramodliv1• 12 years ago

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?

mikelehen9• 12 years ago

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. :-)

primitivesuave3• 12 years ago

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).

bobfunk• 12 years ago

Check out BitBalloon (https://www.bitballoon.com).

Static hosting as well, but we're not tied to any specific BaaS provider, have both an open API, command line deployment tools and grunt integration.

Deploys are atomic and versioned and you can roll back to any earlier version at any time.

We also support rewrite rules, which is essential if you're using history pushstate for your app.

stevetjoa• 12 years ago

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?

mikelehen9• 12 years ago

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.

marknutter2• 12 years ago

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 :)

bravura• 12 years ago

Could you please elaborate more, perhaps through example, of apps where either parse or firebase would be clearly superior?

aoberoi• 12 years ago

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.

jermaink• 12 years ago

Hey Firebase team, I really liked how you did the https://www.firebase.com/tutorial/ !

mikelehen9• 12 years ago

Thanks! We worked hard to try to make a tutorial that communicated the simplicity and power of the API. Glad you liked it!

thurn• 12 years ago

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.

tylermauthe2• 12 years ago

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...

johnrob• 12 years ago

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.

tylermauthe2• 12 years ago

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?

zackmorris• 12 years ago

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.

lazyant• 12 years ago

Unlike other hosted db offerings it supposts SSL by default, awesome

marknutter2• 12 years ago

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.

amirvaliani2• 12 years ago

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!

mikelehen9• 12 years ago

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!

amirvaliani2• 12 years ago

Ok. Great. Glad you are aware of the problem and evaluating solutions. Thanks!

Ryel• 12 years ago

Isnt $0 - $49 quite a large gap in your packages?

jayonsoftware• 12 years ago

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 ?

Max_Horstmann2• 12 years ago

https://github.com/ziyasal/FireSharp

p1mrx• 12 years ago

Does it support IPv6? www.firebase.com has no AAAA records.

bsaul2• 12 years ago

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...

_pius• 12 years ago

Paxos is a good place to start, as it's well-regarded and fairly accessible.

http://en.wikipedia.org/wiki/Paxos_%28computer_science%29

bsaul2• 12 years ago

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.

wmf2• 12 years ago

Most real-time frameworks like Wave and Derby use Operational Transformation. http://www.waveprotocol.org/whitepapers/operational-transfor... http://blog.derbyjs.com/2013/06/04/derby-v0-dot-5-0/

(Edit: Apparently Meteor does not use OT; yet another reason it's behind Derby.)

sgdesign• 12 years ago

What are the other reasons it's behind Derby?

jchrisa• 12 years ago

The last 1/3 of my talk at last year's Strange Loop was on the data structures used in the Couch world for multi master sync. http://www.infoq.com/presentations/sync-mobile-data

Also google CRDT

cnp4• 12 years ago

Just deployed my first app and WOWOW that workflow is NICE.

mayop100• 12 years ago

Thank you! We put a lot of effort into making it simple and providing real-time feedback as things are moving along. I'm glad you liked it.

dsl• 12 years ago

It looks like the actual hosting is done on top of SoftLayer. The CDN is Fastly.

naught_sleeping• 12 years ago

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.

sevilo• 12 years ago

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.

camus2• 12 years ago

Hi i'd be interested to know what kind of db your using under the hood,just curious are there any technical articles about it? thanks.

workoy2• 12 years ago

MongoDB i believe. http://www.mongodb.org/about/production-deployments/#cloud-i...

workoy2• 12 years ago

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?

jenkinsj• 12 years ago

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.

happywolf• 12 years ago

Why firebase doesn't provide pro-rated refunds on downgrades or refunds? It seems indirectly that locks an unhappy user in. Not cool.

https://www.firebase.com/pricing.html

Noxchi• 12 years ago

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.

Max_Horstmann2• 12 years ago

Very cool! I just built and deployed a real-time voting app in literally 10 minutes.

https://crackling-fire-7227.firebaseapp.com

Introducing Firebase Hosting

Related Stories