I can see there's no Ruby SDK, but are there any plans to build one?
Open sourcing the Firebase SDKs
21–30 of 77 posts
Re: Open sourcing the Firebase SDKs
#22[other Firebase founder] It was painful to read the article[1] this morning, especially since I was one of the people responsible for dropping the ball on getting Home Automation the credit to cover the overage a few weeks ago. We're working with the founder to make sure he's in a better spot. If you have similarly serious issues, my email is: james@firebase.com To address a couple of points that have been raised: 1.…
To my discredit I enjoyed dumping on Google earlier today with the Firebase support issue article. That being said this was a great response and I appreciate it. Also my first React Native app used Firebase and I have fond memories of setting that up :) I like that item #1 was very direct...essentially: "look the support got worse and it's not good but we're working on it". SIDE NOTE: I don't get how a lot of people…
I enjoyed dumping on Google earlier too. I love firebase, but I've talked two companies I've worked with out of using it for new, mission critical projects. The earlier article made me feel completely vindicated in my recommendations.
I simply have no trust that:
- Google won't randomly cancel firebase (wave, reader, etc)
- Google won't randomly, suddenly jack up the prices for firebase, leaving users in the lurch (appengine)
- When something mission critical breaks or changes, I'll have any way of contacting someone who cares, no matter how much my company is paying for the service. (Google's support forums are a pit of sorrow)
I was reading an article the other day talking about personhood[1]. It makes the point that part of being a member of society is the idea of standing. That is, if you break your word there has to be a way for you to lose out as a result. If there isn't, its impossible for anyone to enter into an agreement with you because you can't be trusted. Forming an agreement requires both sides to have skin in the game.
I don't genuinely believe that google has skin in the game when it comes to cloud services for small-to-medium customers. Its just too easy for them to drop the ball, stop answering emails and leave customers in the lurch. They've done it again and again. I'd say its the default way Google operates.
Thomas Schelling from The Strategy of Conflict:
> Among the legal privileges of corporations, two that are mentioned in textbooks are the right to sue and the "right" to be sued. Who wants to be sued! But the right to be sued is the power to make a promise: to borrow money, to enter a contract, to do business with someone who might be damaged. If suit does arise, the "right" seems a liability in retrospect; beforehand it was a prerequisite to doing business.
Please, firebase. Please be different. But know that thats the reputation you're fighting against. Thats the reputation you've inherited by joining Google. But for now I'm standing by my earlier recommendations.
[1] http://www.meltingasphalt.com/personhood-a-game-for-two-or-m...
Re: Open sourcing the Firebase SDKs
#23I can see there's no Ruby SDK, but are there any plans to build one?
I help maintain the unofficial Ruby client for interfacing with the Firebase Database REST API: https://github.com/oscardelben/firebase-ruby
I use it on my fairly high-traffic Firebase site and it works well.
Re: Open sourcing the Firebase SDKs
#24Earlier quoted context omitted.
To my discredit I enjoyed dumping on Google earlier today with the Firebase support issue article. That being said this was a great response and I appreciate it. Also my first React Native app used Firebase and I have fond memories of setting that up :) I like that item #1 was very direct...essentially: "look the support got worse and it's not good but we're working on it". SIDE NOTE: I don't get how a lot of people…
I enjoyed dumping on Google earlier too. I love firebase, but I've talked two companies I've worked with out of using it for new, mission critical projects. The earlier article made me feel completely vindicated in my recommendations. I simply have no trust that: - Google won't randomly cancel firebase (wave, reader, etc) - Google won't randomly, suddenly jack up the prices for firebase, leaving users in the lurch (a…
As I said two years ago¹, Google is too large to have actual customers, per se, since any group of paying users is still too small for Google to need to pay attention to.
Re: Open sourcing the Firebase SDKs
#25Earlier quoted context omitted.
To my discredit I enjoyed dumping on Google earlier today with the Firebase support issue article. That being said this was a great response and I appreciate it. Also my first React Native app used Firebase and I have fond memories of setting that up :) I like that item #1 was very direct...essentially: "look the support got worse and it's not good but we're working on it". SIDE NOTE: I don't get how a lot of people…
I enjoyed dumping on Google earlier too. I love firebase, but I've talked two companies I've worked with out of using it for new, mission critical projects. The earlier article made me feel completely vindicated in my recommendations. I simply have no trust that: - Google won't randomly cancel firebase (wave, reader, etc) - Google won't randomly, suddenly jack up the prices for firebase, leaving users in the lurch (a…
I think you've mischaracterised things a bit in your post - not sure if this is just because you're repeating what you read elsewhere? Anyhow, regarding the bullet points:
1. Google Wave was released an experimental consumer product, designed to combine the best of IM and email. According to the announcement, it was finally sunset due to lack of interest from the public. Personally, I was super excited about Wave - I even pestered an ex-Googler at the time to get me in on the preview. (I was in uni at the time). However, I had a lot of trouble getting other people to use it.
Did you personally use Wave yourself? Were you able to convert anybody else to using it?
Firstly - this is hardly apples to oranges. You're comparing a experimental consumer-oriented preview product, to an enterprise offering with SLAs. It would be like if we released a Star Wars game showcasing awesome new WebGL features - then decided to sunset it 12 months later.
Secondly - the project was open-sourced and then moved to under the Apache banner - an effort that in itself took significant engineering effort.
https://en.wikipedia.org/wiki/Apache_Wave
I'm not really sure what more you want?
In the case of Reader - this is somewhat personal, as I was a big lover of Google Reader as well. From memory, it was deprecated with around 12 months of notice, there were provisions for migrating/exporting all your data etc. It wasn't open-sourced like Wave, but there were reasons behind that (I can't comment). However, it was hardly the worst handled deprecation - and to be honest, the writing was on the wall for RSS for a long time before that.
2. You didn't provide any specifics, so I'm not sure what event you're referring to.
AFAIK, the only major price change was when Google AppEngine left beta/preview, and became an actual commercial product, and Google added SLAs, and other things etc:
https://groups.google.com/d/msg/google-appengine/Hluog1_a3n4...
The changes were announced at I/O that year (May), I believe, and the actual changes took effect in September.
Is that what you're referring to? Because even taken aside my Google hat, that seems like a fairly reasonable thing to do.
3. All of Google's enterprise offerings have support. I know, because I actually work in such a support team. For GSuite, support comes free as part of the product - you can contact us via email/chat or over the phone.
For GCP, there are commercial support packages available (https://cloud.google.com/support/) (similar to the AWS model).
> They've done it again and again. I'd say its the default way Google operates.
This is a pretty bold claim - can you cite any examples of this?
If this is something that personally affected you - please feel free to reach out to me. I can't promise I can fix everything, but I can definitely try to find out more for you, or see what I can do internally.
Disclaimer: I work for Google, but views expressed above are my own.
Re: Open sourcing the Firebase SDKs
#26I was an early Parse engineer (4th engineer to join the company) and now am the SDK engineering lead for Firebase. The experience of working on Firebase at Google is vastly different from Parse at Facebook, and it shows in Google’s continued commitment to building and expanding Firebase, integrating it with its Cloud Platform products, and otherwise pouring huge amounts of effort into making Firebase great for develo…
I'm just wondering if there is a feature on your future pipeline to include username as a sign up/sign in your SDKs besides only email and password?
Re: Open sourcing the Firebase SDKs
#27Earlier quoted context omitted.
I enjoyed dumping on Google earlier too. I love firebase, but I've talked two companies I've worked with out of using it for new, mission critical projects. The earlier article made me feel completely vindicated in my recommendations. I simply have no trust that: - Google won't randomly cancel firebase (wave, reader, etc) - Google won't randomly, suddenly jack up the prices for firebase, leaving users in the lurch (a…
As I said two years ago¹, Google is too large to have actual customers, per se, since any group of paying users is still too small for Google to need to pay attention to. ① https://news.ycombinator.com/item?id=9912754
These are all little hobby projects for the advertising company.
Re: Open sourcing the Firebase SDKs
#28[other Firebase founder] It was painful to read the article[1] this morning, especially since I was one of the people responsible for dropping the ball on getting Home Automation the credit to cover the overage a few weeks ago. We're working with the founder to make sure he's in a better spot. If you have similarly serious issues, my email is: james@firebase.com To address a couple of points that have been raised: 1.…
Hi! One related question, and one offtopic question.
Do you happen to have any idea what actually happened internally with this? I ask this coming from the standpoint of "ouch, another example of ignored paying customers". Obviously this is a difficult question to answer generally, but extra detail about what happened has the potential to instantly pull this specific instance out of the generic "Google support is insufficiently human" bucket, which might be interesting. (Please note that I'm asking this to get the other side of the story about this, I'm not trying to shoot the messenger :) )
OK, now for my offtopic question. I think you're probably the perfect person to ask this.
https://github.com/HackerNews/API (linked from the bottom of every HN page except the add-comment page) describes HN's Firebase-based API. The current API design tends to require a lot of discrete requests to get at high-level information due to the fact that it doesn't support batching (and the page acknowledges this, with "It's not the ideal public API, but it's the one we could release in the time we had.").
Now... that page also says "There is currently no rate limit."
For some time I've wanted to track page votes over time. These are not logged, so this operation is necessarily very realtime. There are lots of posts, and when one of them goes viral the vote goes up very quickly. Perhaps you can see where this is going :)
If I wanted to try and overcome the poor API design by requesting individual items every 500ms or 250ms, or 100ms.... or 50ms......
a) at what point am I likely to get hard IP-blocked? (I'm also wondering how bad it/I would be if I used a bunch of different IPs, at least in terms of technical load.)
b) what rate should I tend to prefer so I can be nice to HN (I'm not sure what tier they're on)?
Re: Open sourcing the Firebase SDKs
#29Earlier quoted context omitted.
I enjoyed dumping on Google earlier too. I love firebase, but I've talked two companies I've worked with out of using it for new, mission critical projects. The earlier article made me feel completely vindicated in my recommendations. I simply have no trust that: - Google won't randomly cancel firebase (wave, reader, etc) - Google won't randomly, suddenly jack up the prices for firebase, leaving users in the lurch (a…
I think you've mischaracterised things a bit in your post - not sure if this is just because you're repeating what you read elsewhere? Anyhow, regarding the bullet points: 1. Google Wave was released an experimental consumer product, designed to combine the best of IM and email. According to the announcement, it was finally sunset due to lack of interest from the public. Personally, I was super excited about Wave - I…
> This is a pretty bold claim - can you cite any examples of this?
I don't know if you have read the original thread, but there are a few examples of this: https://news.ycombinator.com/item?id=14356409
Also this: https://stackoverflow.com/questions/38959321/firebase-databa...
Re: Open sourcing the Firebase SDKs
#30what's new? Bug fix that increases costs by a huge amount. It's a feature not a bug ;-)
There have been some updates on this situation for those that caught it earlier today. Original post has been updated about being contacted by Firebase: https://medium.com/@contact_16315/firebase-costs-increased-b... Firebase founder comment on Medium about it: https://medium.com/@startupandrew/firebase-founder-here-im-v... (and he posted the same thing on the HN thread https://news.ycombinator.com/item?id=14359801 )…
I was being needlessly trolly but glad there's some dialog happening. And I'm sure this will get worked out.