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

Open sourcing the Firebase SDKs

opensource.googleblog.com

Post reply on HN
Print view View original

51–60 of 77 posts

Re: Open sourcing the Firebase SDKs

#51

Post by flukus »

bad_user wrote: post #50
Brahma111 wrote: post #38

This post shows, how mis-informed the community can be. If you have been following up Google Cloud and Firebase, most of the questions regarding long term support, phasing out and Google turning rogue wouldn't be asked. Firebase is one key aspect of Google's cloud strategy. Pretty much everything on Mobile services is tied with Firebase, some way or the other. We have now built 2 products on Firebase and are reasonab…

> Tweeting to the Firebase handle on issues never get replied. Is that really how you expect to get support?

Sadly it's often the most effective way. Companies pay a lot for social media monitoring and anything that gets a lot of tweets they'll act on.

Re: Open sourcing the Firebase SDKs

#52

Post by samastur »

victorhooi wrote: post #25
josephg wrote: post #22

Earlier 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…

> From memory, it was deprecated with around 12 months of notice, there were provisions for migrating/exporting all your data etc.... - and to be honest, the writing was on the wall for RSS for a long time before that.

You couldn't export all your data easily unless you were only interested in starred item and subscriptions. If you cared about tagged items, you had to write your own code to fetch that or find someone else that did this (I know because I wrote such script).

It is true that you could access all of it and that you had about 3 months time to do so (not 12).

As far as RSS goes, I am still using it daily and have no problem finding sources except few places that really go for walled-garden like Google's G+.

Re: Open sourcing the Firebase SDKs

#53

Post by stemuk »

dsun178 wrote: post #46
stemuk wrote: post #43

Earlier quoted context omitted.

In particular I would love to see the query size change in the real-time database. This could either be achieved by compressing the JSON response, or by calculating the traffic differently. As a user of Firebase about a year ago I saw much, much higher egress traffic from the Real-time database than I expected. To be specific, for testing purposes I set up a note-taking app, which (being a test) had the database size…

It looks like you need an offline-first solution like pouchdb or rxdb. The traffic would have been around 31kb, no mather how much you query.

I really appreciate the input, however the note taking example mentioned above was just a test project of mine. The actual project needs real-time synchronization, which isn't something I was expecting pouchdb/couchdb to be capable of.

Re: Open sourcing the Firebase SDKs

#54

Post by bad_user »

flukus wrote: post #51
bad_user wrote: post #50

Earlier quoted context omitted.

> Tweeting to the Firebase handle on issues never get replied. Is that really how you expect to get support?

Sadly it's often the most effective way. Companies pay a lot for social media monitoring and anything that gets a lot of tweets they'll act on.

Well obviously some companies disagree.

Interactions on Twitter are shallow, which makes support interactions risky and unsatisfactory for the customer ;-)

Which is why any sane company will only reply "Please mail us at ...".

Re: Open sourcing the Firebase SDKs

#55

Post by user5994461 »

teddyh wrote: post #24
josephg wrote: post #22

Earlier 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

Bullshit.

Any telco operator has millions of customers and it handles support just fine.

Any bank has millions of customers and it does support just fine.

Google enterprise products (Cloud, app engine, apps) are nowhere near that number. They have no excuse for not having support.

Re: Open sourcing the Firebase SDKs

#56

Post by radimm »

hueving wrote: post #48
jamest wrote: post #10

[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.…

>1. We're aware that as we've integrated with Google our support response time & quality has decreased. I'm working with our team to do better. Can you though? I've yet to see any good google support for any software product. How much leeway do you actually have to change the support culture of a company that doesn't care about support?

(not affiliated) we are using compute engine and response time are great. Nothing we can complain about.

Re: Open sourcing the Firebase SDKs

#57

Post by jimrandomh »

jamest wrote: post #10

[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.…

It's good that you're able to fix this sort of thing when it's on the front page of HN, but Google's lack of support is legendary, and I don't see why people should expect anything if they aren't making the news like that. My own experience with Google Glass DevRel was about as bad, except no one made any attempt to set things right, or even apologize.

Re: Open sourcing the Firebase SDKs

#58

Post by [deleted] »

jamest wrote: post #10

[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.…

[deleted]

Re: Open sourcing the Firebase SDKs

#59

Post by [deleted] »

teddyh wrote: post #24
josephg wrote: post #22

Earlier 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

[deleted]

Re: Open sourcing the Firebase SDKs

#60

Post by unoti »

Top19 wrote: post #20
jamest wrote: post #10

[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…

> SIDE NOTE: I don't get how a lot of people today don't understand that using vague language in apologies doesn't help with apologies.

It doesn't, you're right. But specific language in apologies doesn't help the company much during litigation, especially civil litigation when assessing damages. I realize that's not real sexy, but that might give you some perspective on your question. Imagine everything you write is being entered into a court transcript, and evaluated by a judge's clerk working on a recommendation for assigning damages. It is better to focus on delivering excellent service so things more rarely get to that point, but that's how apologies and announcements tend to get vague to the point of senselessness.

Post reply on HN