on a sidenote: I wouldn't do business with or trust my data to a company that hides their actual address behind whois protection
They'll probably remove the whois protection once they fully launch.
31–40 of 148 posts
on a sidenote: I wouldn't do business with or trust my data to a company that hides their actual address behind whois protection
They'll probably remove the whois protection once they fully launch.
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…
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?
Earlier quoted context omitted.
Sorry - I think "real-time web" is already in our lexicon. 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.
I don't think that it's a lost cause. Mainly because calling these things "real-time" is technically incorrect. Real-time computing is already formally defined and well established. 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.
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…
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
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.
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.
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…
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…
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?