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

71–77 of 77 posts

Re: Open sourcing the Firebase SDKs

#71

Post by teddyh »

user5994461 wrote: post #68
teddyh wrote: post #65

Earlier quoted context omitted.

I think you misunderstand me. I’m not saying Google couldn’t have acceptable support. I’m saying they don’t have to ; there is simply no perceptible downside to them if they don’t.

That is true for all their free public services. They are build without support. Can't support 1 billion free users. That is untrue for all entreprisey services. They must have support.

What do you mean, “must”? They seem to be doing fine without it. Google will still have enterprise customers, no matter how bad their support is when it is really needed.

Re: Open sourcing the Firebase SDKs

#72

Post by jamest »

bad_user wrote: post #54
flukus wrote: post #51

Earlier quoted context omitted.

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

Yes, we don't reply on Twitter since it became difficult to operate across multiple channels as we scaled.

I've just updated our Twitter bio to make it clear where to go for support:

http://twitter.com/firebase

Re: Open sourcing the Firebase SDKs

#73

Post by jamest »

piyush_soni wrote: post #42
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.…

Thanks for responding to the issues and admitting the support has got worse since your association with Google. That's a big admission to make (are you sure Google doesn't punish people for revealing such things?). You might also want to tell 'other teams' in Google what's the perceived image of their support outside. What Google Support means for me for most of their services is - some 'internet forum' on which a fe…

Thanks for the comment

Re: Open sourcing the Firebase SDKs

#74

Post by tlarkworthy »

stemuk wrote: post #43
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.…

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…

Hi, Tom from the Firebase Realtime database team here. To address the difficulties of figuring out where performance issues were, we made a database profiler (https://firebase.google.com/docs/database/web/profile). I expect that would help pinpoint where the issue was. My informed guess would be an index was not setup as you expected and the querying was being done client side, or my next guess would be the client was rapidly connecting and disconnecting. (check clientside with Firebase.database.enableLogging(true)).

The profiler excludes SSL overhead, but you can see usage inclusive of SSL in the webconsole.

Re: Open sourcing the Firebase SDKs

#75

Post by salqadri »

dirtylowprofile wrote: post #26
depoll wrote: post #2

I 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?

Firebase actually announced phone number authentication on Wednesday as yet another alternative to only having email/pw.

Re: Open sourcing the Firebase SDKs

#76

Post by HodGreeley »

yeldarb wrote: post #5

How about open sourcing the realtime database server? Would love to be able to do offline local development.

With Couchbase Mobile, we shy away from the "realtime" claim, because it's vague. (Ask a high-frequency trader how they define realtime...) Having said that, we have customers that are very happy with the response times. Always been open-source. Check our blogs for steps to get everything set up front to back to develop on one machine.

Re: Open sourcing the Firebase SDKs

#77

Post by NotZachari »

jamest wrote: post #70
hueving wrote: post #48

Earlier quoted context omitted.

>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?

Both Fabric & Firebase (pre-acqusition) had great support cultures. I think we have a good shot at improving how Google approaches support for Firebase. The proof will be in the results. Hopefully we can share those in the future.

I know I'm late to the party, but I really hope that things get back on track soon.

When I learned Google had acquired Firebase, I was really disappointed because I knew that it would be another instance where a great product or service was crippled by Google's approach.

I came across Firebase fairly early on, and I absolutely loved it. Documentation was solid, the examples were all interesting and straightforward, and support was always great. Now, documentation and site navigation are both downright painful to deal with. I've recently transitioned multiple projects to Deepstream.

Personally, I'm not confident enough in the direction things have headed to commit to Firebase beyond trivial projects. I got in on Fabric in Jan 2015, and again, it was a great experience. I just feel like Google's lead to a decrease in focus on the core of what makes Firebase so appealing.

Like I said, I'm a long time Firebase guy, and I really want to see things improve. At the very least, can I give up my first born for a documentation overhaul? I swear it wasn't always this frustrating and cluttered.

Post reply on HN