Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Firebase, a scalable real-time backend

firebase.com

Post reply on HN
Print view View original

101–110 of 148 posts

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

#101

Post by buu700 »

jdavid wrote: post #16

Firebase, Burn your servers, you don't need them any more. Firebase is for app developers that don't want to worry about building real time scalable back ends.

Random aside, but when I first saw this comment (it was originally downvoted, IIRC), it sounded like an incoherent insult directed at Firebase for catering to "noob" developers; I only realised that you meant it as a potential marketing line after reading a bit of your comment history :P. I think a colon in place of a comma at the start would have been more clear.

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

#104

Post by shurane »

pkrein wrote: post #4

I used Firebase to build thereelbox.com, and enjoyed it thoroughly. It took 2-3 hours from starting into the documentation to completed/nobugs/pushed to production. Credit for that speed goes entirely to Firebase. 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…

That's quite useful! I hope you're making money from it.

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

#105

Post by shurane »

pkrein wrote: post #4

I used Firebase to build thereelbox.com, and enjoyed it thoroughly. It took 2-3 hours from starting into the documentation to completed/nobugs/pushed to production. Credit for that speed goes entirely to Firebase. 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…

That's quite useful! I hope you're making money from it.

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

#106

Post by tlrobinson »

pkrein wrote: post #86
davej wrote: post #78

Earlier quoted context omitted.

Still though, somebody could delete all the movies and showtimes in a couple of clicks. I presume you have the JSON backed up but it's still going to get annoying if somebody decides they want to be a dick.

true [backs up data]. the system will also auto-recover by falling back to the RT/YT/YQL APIs if someone does that, though pages will load significantly slower and Rotten Tomatoes will throw a bunch of rate-limiting errors until Firebase is repopulated.

I'll be honest, it's kind of fun to go to [REDACTED URL] and delete the list of movies and watch them repopulate as people load the site...

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.

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

#107

Post by aphexairlines »

geoffschmidt wrote: post #84
asselinpaul wrote: post #21

What is the difference between this and let's say 'Meteor'?

Meteor dev here. If you're writing a Meteor application, you need a realtime database. Otherwise, Meteor can't make the page update in realtime, because it can't find out about database changes in realtime. 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…

Would you say that Meteor is a functional reactive programming platform like Flapjax or FrTime, but over the wire? Distributed FRP?

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

#108

Post by courtewing »

smoody wrote: 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 think that is a valid concern, but it doesn't really apply to all apps.

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.

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

#109

Post by aidenn0 »

pilom wrote: post #95
aidenn0 wrote: post #91

Earlier quoted context omitted.

which violates your copyright. Microsoft Word is entirely client-side so it too can literally just be downloaded and reused by a would-be competitor.

Downloading Microsoft Word does not include all the source code in addition to the application.

Neither does obfuscated and minified javascript.
Post reply on HN