Show HN: Firebase, a scalable real-time backend
firebase.com
firebase.com
TheReelBox uses Firebase as a sort of API caching layer. This protects against rate limiting on the Rotten Tomatoes API, decreases request time by caching queries to the Fandango-via-YQL API, and eliminates an extra request per movie for Youtube trailers.
At the beginning, this system made it possible to host TheReelBox on my public dropbox folder, which made for really fast development. Since launch I've moved the static html and js to a micro AWS instance, but Firebase cleanly and transparently handles all the data.
Definitely recommend it.
The AWS micro is free :) and it gives me a bit more flexibility to do things (in the future) like track outbound clicks to Fandango through a redirect that hits a real server.
- Go to www.imdb.com
- Click on 'See more movie showtimes' at the right.
- On the next page, click on the 'Favorites' tab to choose a theater.
- Go to maps.google.com and plan the route to the theater.
And its got TRAILERS too !!! I'm addicted !!
Sorry, I'll stop.
Seriously though, this is a neat toy/prototyping platform, but they desperately need to add some security for it to be really useful.
Might I recommend incorporating some sort of mechanism to help people figure out a movie to watch?
- Sort by (name, start time, rating, distance)
- include video playback controls, useful info such as time of preview, buffering, etc..
- X out or remove videos from my personal view, this would be KILLER to allow me to narrow down my choices as I watch videos
It seems like it lowers the barrier to competition a bit too much for me.
Other than that, you could either make your business, rather than your technology, more competitive, or make your technology ever more sophisticated than what "commodity" development tools allow.
Microsoft Word is entirely client-side so it too can literally just be downloaded and reused by a would-be competitor.
(If I were in a nitpicking mood I would also point out that the source is what is fed into the minifier or obfuscator, not what comes out.)
It's a lot easier to reverse-engineer the site than to build it from scratch yourself. You won't get all the comments, and some of the names of functions and variables and whatnot may lose their semantic meaning in favor of shorter names. But yes, it is trivial to unminify the source and work through it. If it's 10k+ lines of code, that's never trivial to understand and get it all in your head, but the concern is absolutely valid. If you think minifying/obfuscating is securing your code intellectual property, you're fooling yourself. It's like security through obscurity... it's not really offering you any protection.
I'm a curious guy and have deciphered small-ish amounts of minified and/or obfuscated JS before. It is absolutely not trivial. Especially if it's obfuscated.
"un-minifying or un-obfuscating JavaScript is not a trivial exercise by any means."
I think you mean that understanding obfuscated code is not trivial. Un-minifying is certainly trivial. There are tools to do it for you. There's no such thing as un-obfuscating, if you consider that you can't get the original comments or all the semantic naming back. So I'll concede that it's more difficult to read through this obfuscated code than the original. But the original comment in this long thread seems valid to me... that an entirely client side app puts you at much greater risk for cloning than an app with a significant portion of code in back-end, just because your javascript is out there for all to see.
My point is that you can't just de-obfuscate a primarily client-side JS app and replace the Firebase (or whatever) endpoints. Proprietary obfuscation is more than just variable name munging and minification..
Once you have a basic HTTP database API, you can do most of an app in client-side JS. Security is the hardest part to get right. In CouchDB we've tried to follow the web security model when it makes sense (single origin policy, oauth, etc).
CORS and WebSocket are both changing the web model, so it's not surprising to see the idea of a simple data API catching on as the web gets more power. Can't wait to see where this goes.
As one example, for a lot of businesses, the value is not so much in the app itself but in the data the app interacts with. In those cases, giving your competitors the source code to your app does mean they could copy anything they want from your app, but that doesn't do them much good if the real value is in the data.
Dropbox for JS objects.
If I've got that right, I think this is totally awesome for front-end web devs and the most exciting backend-as-a-service out there.
That being said, I do believe the hardest part of all these attempts to abstract backends is authentication and security models. It seems to me that most of these services launch before figuring out that critical part of the puzzle.
Figuring this stuff out is hard. Usually for questions that come up in this shift, we have a good model we can look at, which is the client/server desktop applications of the late 80s and early 90s. But in the case of authentication and security, they tell us not so much, because in those days most software lived inside private corporate silos. These days, our software not just technologically distributed, it's politically distributed.
In the case of Meteor, it's designed from the ground up for security. In fact, it's a second generation security model, designed after reflecting on lessons learned from Asana's Luna platform (I worked on Luna at Asana for a while in 2010.) It just isn't exposed in a user-friendly way in the Tuesday release.
But people dug into the code, found it, and are using it anyway, whether we like it or not. Briefly, 'meteor remove autopublish', use Meteor.publish to define what data clients can access, use Meteor.subscribe to control what data a particular client is getting, use Meteor.methods to define what writes clients can do, and see the following Stack Overflow question to disable the 'newbie mode' insert()/update()/remove() that let you do arbitrary writes to the database.
http://stackoverflow.com/questions/10115042/how-do-you-secur...
I'm not trying to put down Firebase, I imagine it's great.
http://en.wikipedia.org/wiki/Real-time_web#Real-time_search
Just make sure people say web after they say real-time and there should be no confusion.
Given the definition of real-time, one could actually create a real-time web or a real-time search. So there is still cause for confusion--or, at least, technical incorrectness--if one uses that terminology.
So maybe something like "blink speed." (Then we'd have blink speed apps on retina displays.)
Interstingly, I got much more feedback this time, probably due to catching the article soon after it was posted. It's also intersting that you noticed that I'd posted an identical comment yesterday and called me out on it; I was wondering if anyone would.
I hadn't given it much thought, but if making the same comment twice bothers anybody, I apologize.
Interestingly, most of the core Meteor team has worked on systems that you might consider "actually" realtime: I wrote machine vision software that watches a few dozen cameras and tracks objects moving between them, Nick wrote software defined radio code that runs inside rural cell towers, Matt wrote kernel drivers for high performance IO interconnects.
Seems there is a huge development ongoing to reflect new development and scaling practices...
EDIT: REALLY like the RT-Chat on the site - that is showcasing as it should be (and not just another "Demo" button).
Mongo for storage backend
Node.js client is Faye
Scala + Netty backend
custom JS client supporting "IE7+, Opera 10+, Safari / Chrome (recent versions), FF3.0+"
Once you start playing with it you realize that there are so many apps that can be built.
the team has a few things to work on, and trust me many of us in the beta flushed a lot of those out. they have their work ahead of them. what's there is polished and ready for use. give it a try. use this as a chance to explore what can be done when you can forget about the backend.
A very simple guide to make a very simple, understandable web-app would be the killer feature for me.
There is a tutorial for a chat-app but that's way over my head(I of course get how to put in the code, I just don't understand it (REST, roots, references etc). If I could be shown how to make something insanely simple, and I actually understood how it worked, it'd lead me on to the next thing. A collaboration with codecademy might be the thing.
So much potential.
We both think that application development is going to radically change in the future and we're both building products that promote a new way of developing apps. We're stoked about Meteor and see our products as very complementary.
One minor quibble.. I like to think of Meteor as an "application platform" rather than a framework, because we're trying to take on some problems that web frameworks don't always tackle, like packaging and deployment. Also, we don't require you to use a particular strategy for generating HTML. For example, it makes sense to use backbone.js with Meteor, if that's your thing. At the end of the day, Meteor is about how you make all of the pieces fit together in a distributed cloud application. (For better or worse, that's what websites have morphed into, when you think about all of the APIs and services they use.)
Firebase is a realtime database that you could use with Meteor. The database we use in the Meteor video is MongoDB with Meteor's 'mongo-livedata' package, which adds some realtime glue to Mongo. But there are many potential advantages to using a database that is designed from the ground up to be realtime, and we're very excited that the smart guys at Firebase are taking this on. We predicted that this would happen eventually, but we had no idea it would be so soon.
(If you don't like the word realtime, please s/realtime/reactive/)
I used to work at Asana, where I worked with Luna, which is Asana's inhouse framework and is a distributed FRP system very much like a future-alien-technology version of Flapjax.
It's also worth pointing out that Firebase grew out of Envolve which supported millions of users, so you know these guys can handle scale.
(Absolutely loved the interactive tutorial. Brilliant way to show off the service!)
Not that I begrudge anybody the chance to make some money, but along with Meteor I feel like there's a slightly deceptive nature to this kind of thing where the home page is emblazoned with "look, it's all free!" when in fact there's an unknown price to pay down the line.
About Meteor: There might be a lot of things wrong with Meteor (insecure by design), but this is not one of them: it's opensource and has a command which makes a self containing tar.gz bundle for you to deploy on your own server.
Under a license that does not permit you to easily use it for commercial projects, unlike, say, Django, Rails, Node.js, etc... etc.... etc....
Also, the fact that they talk about commercial licenses is indicative that they may be thinking along similar lines.
It also does the work of managing distributed state of data across all of the clients and the server, and merging that data as needed to prevent conflicts in a distributed network like this. In fact, it allows you to run operations atomically across this distributed system -- operations that are latency-compensated, and work even in offline mode.
And finally, it can scale, with no work from the developer.
Suddenly there is a solution to distributed always consistent real time fully scalable reliable easy to use inexpensive database :)
Do you know this saying? "Nobody can give so much as I can promise you."
Also, if you want to have any non-realtime parts of your web app that do server-side processing of data then it looks like you have to use Node.js to talk to Firebase, as there's no REST API for it that I can see. I guess they don't mind because they're trying to get you to do all data processing in the client anyway.
Definitely need security and permissions. How do I make sure only registered users of my site can access chat? How do I make sure only admin users can create new chat threads? From my brief reading it looks like all clients can see everything in the database and modify it all. Am I wrong?
Also, there is a rest API and I believe they're working on clients for other platforms so that nodejs isn't the only player in town.
We're definitely working on security full speed. We have some basic security but it's not ready yet. If you'd like to beta test it, please email us: beta@firebase.com
You can check out our FAQ for more info: http://www.firebase.com/faq.html
They'll probably remove the whois protection once they fully launch.
I realize this is in beta, and it's early, but am I the only one who would not trust my data to a service where I can't get at least some idea of how they're actually functioning behind the curtain?
Well done, thank you.
We might need a snappier name though, because this sort of real time is a lot more real time that the type of real time people are already used to.
What kind of browser compliance is there?
At the end of the demo you are asked if you'd like early access. Definitely.
Quick question, are you affiliated with firebase.co? They seem to be in a similar field.
From the Leader Board sample:
// Use setWithPriority to put the name / score in Firebase, and set the priority to be the score.
userScoreRef.setWithPriority({ name:name, score:newScore }, newScore);
How about I just change newScore to 100,000 in the debug window?
Great website BTW.
This sounds like Model-as-a-service from the MVC pattern.
But just like meteor, doesn't have any authentication or authorisation, which sadly makes them just toys for now. Looking forward to both projects becoming usable.