In case anyone is confused, it requires Facebook, so if you block FB, it will be pretty much an empty page with some footer links. I assumed it had crashed. But they assumed I allowed facebook.
Might be good to have something show up in case you can't reach facebook.
This is a technology demo. We wanted to demo our real-time tech rather than show a bunch of sign-up workflow code. Facebook auth lets us save a bunch of boring code.
Would it be much more code to support Twitter's OAuth as well? That'd appease me... everything on my Twitter is public and they have a much better record with regard to user data than Facebook. Plus your demo is a Twitter clone, so you'd get points for irony :)
I don't block Facebook completely, but I do use ghostery which blocks Facebook Connect. Had to pause ghostery to get anything but the footer to show up.
We built Firefeed to show how easy it is to build realtime apps with Firebase. We've put up a detailed explanation of how we built it on the about page: http://firefeed.io/about.html
The code is all open source and on Github, please feel free to fork and reuse the project. Pull requests are welcome!
Firebase looks really cool, but my first impression the moment I see that you end up building everything in a way where it is tightly coupled to the servers of a startup that does not have years of profitability yet (or even published pricing), is that there's no way I'd put anything but toy/demo's on it for a long time.
It seems like the type of thing that'd do great with the option of a self-hosted server, and it also seems like the type of thing that'll see open source clones of pretty quickly, though. But I'd actually be vastly more comfortable paying Firebase to host my apps if I knew there was an open source fallback for their server component.
[Firebase founder] Thanks for the feedback! We're definitely aware that it's a concern. Hopefully we can go a little way towards winning your trust by showing you the great apps built on us by larger companies (happening soon) and by giving you the best customer service we possibly can. And, hey, toys are a good starting place too.
Pricing doesn't look like an issue. The hosting thing, for me, would remain an issue no matter how many large companies you sign up - A large enough company could presumably negotiate special concessions. And if not: Large companies make risky decisions too, and can often better afford to engineer their way out of a problem (such as your company failing) better than smaller companies.
If I were to consider using this for something important, my first order of business would be to establish how I could ensure I could remove my dependency on you in the case of problems. The more perceived effort that would require, the less chance I'd go ahead.
Nothing specific to you here - that's how I'd approach building a service around running on e.g. AWS too, or making use of any proprietary API.
You should have graduated concurrent user limits there. Rather than 1000 across the board, start with 100 for the "Candle" plan (the name "Spark" would be a great fit too), 1000 for "Bonfire", and 5000 for "Inferno".
Also, what happens if you exceed the 1000 concurrent user limit? For example, your site is momentarily popular and gets 1500 people trying it out for a few hours then goes back down under 1000. Is there burst pricing? Do connections get dropped? Is there a grace period, like the way 95th percentile bandwidth billing works?
I almost never use Facebook to log into anything, and vastly prefer using twitter as my catch-all account. You absolutely must put in a real account system as an alternative to Facebook if this is going to take off.
We currently provide convenience SDKs to login with Facebook, Twitter and just a regular email/password, but the system is flexible enough to allow any authentication mechanism that can produce JWTs.
It would be refreshing to see a twitter clone that was a free-for-all w.r.t. pseudonyms. Post as anyone and then if you want to register a name you link it to email/fb/twitter.
I wouldn't have used the same language as the parent, but every time a developer creates a FB-only login, it promotes the idea that it is acceptable. It is not.
How many potential clients are they really excluding here? In other words how many people would use this service and not already have a facebook account?
I have one, but I categorically refuse to use Facebook to log in anywhere. In other words, if you look at how many have a Facebook account, you're looking at the wrong number.
OK perhaps that was a tad harsh, but I do get annoyed when I see the only login option for something be Facebook. I won't go on an anti-Facebook tirade but suffice to say it is not everyone's cup of tea and not everyone has a Facebook account. I suppose given this is just a technical demo it is acceptable.
neat. Can I be the first to recommend that you peruse the federation specs (OStatus/Tent.io, also there is a w3 working group mailing list http://www.w3.org/community/fedsocweb/) and try to solve the silo/walled garden issue?
to elaborate, I think there is a huge future in what I call Status Update Services, and I think the trend will be for organizations to move away from the incumbent service providers towards infrastructure under their own control (as in the e-mail model.)
We're working on supporting multiple auth providers, but the larger question of federation is more interesting, and equally harder. We're not sure about where to take Firefeed yet, since it was built as a demo for Firebase, but that's something we'll definitely consider in the future.
Cool, happy I'm giving helpful feedback. The field is just starting to take off, but I think it's great that there is now a growing selection of small message/status update/microblog software.
It's possible that government agencies, universities, businesses, etc can take advantage of running status update services, which can be made either be public or private, tied to their own domain/network, and maintain administration of user accounts. Many other advantages from having this sort of infrastructure develop will be seen as well.
Great job FireBase team. Think I am going to try this for the http://commando.io status feed. Simply host on my CDN. Would love to have GitHub auth as well though.
Might be good to have something show up in case you can't reach facebook.