Show HN: Firebase, a scalable real-time backend • Hacker News Board

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

#81

Post by nicholasreed » Thu, Apr 12, 2012, 9:32 PM UTC

arturadib wrote: post #57

nicholasreed wrote: post #51

Earlier quoted context omitted.

We're using authentication in our Firebase app and it works wonderfully. Although all data is visible on the Firebase backend, we simply put pointer ids in Firebase, so no identifying data is publicly visible.

Care to elaborate? Firebase's FAQ seems to suggest that they're still working on a solution.

I believe they are working on a fully documented and stable auth solution; we're running something custom for now. Our whole Firebase namespace is read-only, so all our writing happens with a private key from our server. I think when the Firebase admin panel has more protection we can store more sensitive/identifiable data in there.

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

#82

Post by [deleted] » Thu, Apr 12, 2012, 9:33 PM UTC

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.

[deleted]

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

#83

Post by _dtw » Thu, Apr 12, 2012, 9:34 PM UTC

Really interesting idea, look forward to giving it a whirl in a moment.

Quick question, are you affiliated with firebase.co? They seem to be in a similar field.

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

#84

Post by geoffschmidt » Thu, Apr 12, 2012, 9:39 PM UTC

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 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/)

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

#85

Post by geoffschmidt » Thu, Apr 12, 2012, 9:44 PM UTC

jamest wrote: post #23

asselinpaul wrote: post #21

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

Good question. Meteor is an application framework, like Ruby on Rails. Firebase is a database, like MySQL. 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.

Good answer :)

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

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

#86

Post by pkrein » Thu, Apr 12, 2012, 9:45 PM UTC

davej wrote: post #78

pkrein wrote: post #72

Earlier quoted context omitted.

yes, side project. my real focus is http://segment.io

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.

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

#87

Post by ebiester » Thu, Apr 12, 2012, 9:57 PM UTC

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…

Just a quick thing - for places that aren't so densely populated (like Tucson) it says there's no information. It'd be nice if you would expand your search a bit outside densely populated areas.

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

#88

Post by cwb71 » Thu, Apr 12, 2012, 9:58 PM UTC

SpiderX wrote: post #38

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…

Nice. The Hunger Games is a rickroll? Is that something you did?

Haha; see nigma's earlier comment about the open admin panel.

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

#89

Post by o1iver » Thu, Apr 12, 2012, 10:16 PM UTC

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…

Really nice site! I love the UI. But please make it available for other countries too (me: Switzerland!)!

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

#90

Post by nick_urban » Thu, Apr 12, 2012, 10:19 PM UTC

pron wrote: post #74

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.

You could say that just about any software development platform. If it makes building software easier, it makes competition easier. And if building apps is easier, it really doesn't matter what stack your app uses - it's going to get easier to "clone", so you may as well use whatever platform gives you the best results. Other than that, you could either make your business, rather than your technology, more competitiv…

It's not that client-side applications are easier to reverse-engineer. If the application is all client-side, it can literally just be downloaded and reused by a would-be competitor.