Introducing Firebase Hosting
firebase.com
firebase.com
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.
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.
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?
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.
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
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!
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.
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?
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.
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 :)
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.
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.
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.
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.
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!
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.
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.
Take care.
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
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
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).
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 suppose it's related to the ditributed database research field...
Edit : when i said related to ditributed database, i related more to things like log shipping.
(Edit: Apparently Meteor does not use OT; yet another reason it's behind Derby.)
Also google CRDT
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.
You can make everything Firebase-related happen at the JavaScript level (which is why hosting is valuable to Firebase users in the first place).
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.
I'll be switching to Firebase hosting it tonight!
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.
Also have any one done a C# wrapper for your REST layer ?