Live data from Hacker News

Show HN: Firebase, a scalable real-time backend

firebase.com

141–148 of 148 posts

Re: Show HN: Firebase, a scalable real-time backend

#141

Earlier quoted context omitted.

Firebase is not really super complicated. It's just a database with a REST Api. I can not think of much more things they could add to lock you in more. I think if this becomes a thing, someone will make an opensource clone sooner or later. 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 ta…

Firebase is a lot more than a database with a REST API. It pushes changes to you live, as they happen, in a way that is fast enough that you can use it for real-time gaming, collaborative whiteboards, and other apps could never work with a polling architecture. 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…

Yeah sure!

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

Re: Show HN: Firebase, a scalable real-time backend

#142
post #70

Here's my big concern: If my entire app is client-based JavaScript, wouldn't that make cloning my app as simple as copying all of the JavaScript and other asset files and then associating them with another firebase account -- perhaps modifying them some so they dont't get banned? It seems like it lowers the barrier to competition a bit too much for me.

I keep wondering this myself. On my resident JS-only app, the only thing that I can think of that's keeping someone from ripping off my code and duping the site is that nobody cares enough to try.

Or using your paid repository to story their own app data. The authentication credentials are running on the client. I'm wondering how I keep a troll from writing a billion things to my firebase.

Re: Show HN: Firebase, a scalable real-time backend

#144
post #56

When the multi-player asteroids story was published, people were talking about Firebase, and having never heard of it, I started googling and found this: http://www.cubeia.com/index.php/products/firebase A scalable real-time game server with a html5/javascript front end. I still don't know which Firebase that game was built with. You guys have trademark issues.

MMOasteroids.com links to firebase.com

Re: Show HN: Firebase, a scalable real-time backend

#145
post #56

When the multi-player asteroids story was published, people were talking about Firebase, and having never heard of it, I started googling and found this: http://www.cubeia.com/index.php/products/firebase A scalable real-time game server with a html5/javascript front end. I still don't know which Firebase that game was built with. You guys have trademark issues.

[deleted]

Re: Show HN: Firebase, a scalable real-time backend

#146

Earlier quoted context omitted.

as I said above, de-obfuscating a large javascript app that's been obfuscated/minified by proprietary tools is virtually impossible to decode. Try running some of google's code - gmail, docs, take your pick - through your beautifier ;)

I don't know if anybody uses proprietary tools to minify and obfuscate their javascript. We all use the same minification tools, with different features selected. Seems like most people use YUI compressor, or one of the others listed here http://compressorrater.thruhere.net/ . I assume Google is using their closure tools (which I've never played with myself). It's a lot easier to reverse-engineer the site than to bui…

That doesn't sound right to me. People will rewrite code that already exists as open source because they don't want to take the time to understand someone else's code. But you're saying that some will reverse engineer a JS app from minified code rather than just rewrite it. Are there any examples of this actually happening?

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.

Re: Show HN: Firebase, a scalable real-time backend

#147
post #27

Earlier quoted context omitted.

Any reason you don't host those static files on a public 'web enabled' ec2 bucket? We do that for http://www.incubatebang.com and it costs us like $1.40/year for hosting

I love the design of your site! Did you have it done in-house?

Yeah, I'm an owner of http://www.isotope11.com and our designer threw it together in a couple of days. He's awesome, and he's leaving shortly, and we'll miss him :(

Re: Show HN: Firebase, a scalable real-time backend

#148
post #146

Earlier quoted context omitted.

I don't know if anybody uses proprietary tools to minify and obfuscate their javascript. We all use the same minification tools, with different features selected. Seems like most people use YUI compressor, or one of the others listed here http://compressorrater.thruhere.net/ . I assume Google is using their closure tools (which I've never played with myself). It's a lot easier to reverse-engineer the site than to bui…

That doesn't sound right to me. People will rewrite code that already exists as open source because they don't want to take the time to understand someone else's code. But you're saying that some will reverse engineer a JS app from minified code rather than just rewrite it. Are there any examples of this actually happening? I'm a curious guy and have deciphered small-ish amounts of minified and/or obfuscated JS befor…

I'm mostly responding to your comment here.

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

Post reply on HN