6 ms·

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

by jamest 9y ago

[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. 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. 2. We know better querying and web offline are needed for the Realtime Database, stay tuned. Finally, I hope you enjoy all the new features that launched today! (https://firebase.googleblog.com/2017/05/whats-new-from-firebase-at-google-io.html https://firebase.googleblog.com/2017/05/whats-new-from-fireb...) Leave a comment if you have thoughts/comments. [1] https://news.ycombinator.com/item?id=14356409 https://news.ycombinator.com/item?id=14356409

hackerboos 9y ago
Until this[1] is fixed I'm not sure that Firebase would meet my needs for many projects. It's such a fundamental requirement to be able to query multiple fields without creating a mess of permutations of each field. [1] - https://youtu.be/sKFLI5FOOHs?t=541 https://youtu.be/sKFLI5FOOHs?t=541
Top19 9y ago
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 today don't understand that using vague language in apologies doesn't help with apologies. It definitely used to, but then everyone started doing it, and now the cool / rare thing to do is to be direct. Maybe the pendulum will swing back someday. Until then thank you Mr.Google/Firebase/James person.
- josephg 9y ago
  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-more-players/ http://www.meltingasphalt.com/personhood-a-game-for-two-or-m...
  - teddyh 9y ago
    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 https://news.ycombinator.com/item?id=9912754
i336_ 9y ago
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 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)?
piyush_soni 9y ago
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 few unpaid workers are trying to help others who are equally clueless, in return of some internet brownie points.
- jamest 9y ago
  Thanks for the comment
stemuk 9y ago
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 of 31kb. But here comes the weird part: by querying the database exactly 10 times, my console was showing 24.5mb of traffic, which is much higher than 31*10=310kb/0.31mb. Ultimately this caused me to change tracks to an open-source alternative, but if changes would be made on that front I'd be willing to take another dive into Firebase.
- dsun178 9y ago
  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.
  - stemuk 9y ago
    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.
- tlarkworthy 9y ago
  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 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.
hueving 9y ago
>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?
- radimm 9y ago
  (not affiliated) we are using compute engine and response time are great. Nothing we can complain about.
- jamest 9y ago
  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.
  - NotZachari 9y ago
    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.
jimrandomh 9y ago
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.
deleted 9y ago
[deleted]

by jamest 9y ago

hackerboos 9y ago

Until this[1] is fixed I'm not sure that Firebase would meet my needs for many projects. It's such a fundamental requirement to be able to query multiple fields without creating a mess of permutations of each field. [1] - https://youtu.be/sKFLI5FOOHs?t=541 https://youtu.be/sKFLI5FOOHs?t=541

Top19 9y ago

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 today don't understand that using vague language in apologies doesn't help with apologies. It definitely used to, but then everyone started doing it, and now the cool / rare thing to do is to be direct. Maybe the pendulum will swing back someday. Until then thank you Mr.Google/Firebase/James person.

josephg 9y ago
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-more-players/ http://www.meltingasphalt.com/personhood-a-game-for-two-or-m...
- teddyh 9y ago
  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 https://news.ycombinator.com/item?id=9912754

i336_ 9y ago

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

piyush_soni 9y ago

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 few unpaid workers are trying to help others who are equally clueless, in return of some internet brownie points.

jamest 9y ago
Thanks for the comment

stemuk 9y ago

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 of 31kb. But here comes the weird part: by querying the database exactly 10 times, my console was showing 24.5mb of traffic, which is much higher than 31*10=310kb/0.31mb. Ultimately this caused me to change tracks to an open-source alternative, but if changes would be made on that front I'd be willing to take another dive into Firebase.

dsun178 9y ago
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.
- stemuk 9y ago
  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.
tlarkworthy 9y ago
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 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.

hueving 9y ago

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

radimm 9y ago
(not affiliated) we are using compute engine and response time are great. Nothing we can complain about.
jamest 9y ago
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.
- NotZachari 9y ago
  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.

jimrandomh 9y ago

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.

deleted 9y ago

[deleted]