Go serverless boys :)
It won't resolve the problem
How we spent $30k in Firebase in less than 72 hours
231–240 of 249 posts
Re: How we spent $30k in Firebase in less than 72 hours
#232Earlier quoted context omitted.
I mean this in the nicest possible way: I see this all the time with the JavaScript set and I am absolutely not the least bit surprised. I used to work on a team that was TypeScript top to bottom, with people who didn’t really even understand how to debug (they were mostly bootcamp juniors). Whenever something would break, if restating it didn’t work, you know what they’d try? Yup, upgrading random dependencies. Refa…
> Refactoring was also pretty popular, although it usually just ended up making things more complicated. Yeah I'm guilty of this one. Sometimes you know the problem is somewhere in a particular area of code, but that code is all over the place. Pulling it apart and refactoring it can be a good way of understanding all its dependencies. If the refactoring doesn't help, just don't check it in..
I don’t think it’s necessarily something to be “guilty” for. Especially if it’s someone else’s code I’m debugging, I agree that rewriting it “in my own words” can be a great way to understand what’s going on. Like you said, its not like you have to check in the changes.
However it sounds like people are talking about refactoring an app solely for the purpose of hoping that the refactor shakes out whatever bugs. That sounds like the debugging equivalent of “8 hours of coding saved me 30 minutes of planning”
Re: How we spent $30k in Firebase in less than 72 hours
#233Go serverless boys :)
It won't resolve the problem
AWS Lambda costs about 20 cents per million requests. A billion requests would have put it just a little south of 200-300 dollars. Factor in a few additional read units for DynamoDB, but I don't see it going to total $30,000. The serverless architecture should scale as well.
Re: How we spent $30k in Firebase in less than 72 hours
#234Earlier quoted context omitted.
Legit question here; what would be a good architecture for this case?
SQL with no ORM. Harder to be unaware of what you’re querying when you have to write the queries. Not using attempted magic like Firebase would also fix the problem where the home page transfers 9 MB of data from Firebase on top of the 1 MB JavaScript, which appears to be… their entire database or something?? Accessible to the frontend??? Censored excerpt from that response: "email":{"stringValue":"soXXXXXXXsu@gmail.…
Exposing contents of DB without even any SQL injections... I think they have no idea about network monitoring. They _have_ an idea about console, since they're logging stuff there extensively.
Re: How we spent $30k in Firebase in less than 72 hours
#235Earlier quoted context omitted.
When was the last time the consumption of a Google ad lead to cancer and the eventual death of anyone?
> When was the last time the consumption of a Google ad lead to cancer and the eventual death of anyone? Great logic. Philip Morris is evil because they sell products that cause cancer and death. Therefore Equifax, who extorts money from people to protect them against Equifax polluting their credit rating, and who leaks their data into the wild is not evil, because Equifax doesn't cause cancer nor death!
When was the last time Google had a data breach and leaked my social security number they didn't have and didn't use to "extort" money from me?
Re: How we spent $30k in Firebase in less than 72 hours
#236I feel depressed about this, on how the industry promotes and even supports extreme technical incompetence. Maybe is a consequence of "everyone should learn to code" campaigns and bootcamps.
Cheer up buddy, you were this incompetent at one time too, but now look at you, a full grown narcissistic asshole senior developer. You have come a long way and these kids will too!
Re: How we spent $30k in Firebase in less than 72 hours
#237Earlier quoted context omitted.
How did you get your Startup credits?
My company was part of a partner acceleration program, however you can apply to be part of the Google Cloud for Startups program here[1], without needing to be in an accelerator. [1] https://cloud.google.com/developers/startups/
Thanks guys. Appreciated
Re: How we spent $30k in Firebase in less than 72 hours
#238Earlier quoted context omitted.
Product Manager for Cloud Firestore here. It's worth noting we do have the ability to set hard daily caps, as well as budgets that can have alerts tied to them. It's something we also looking at ways to improve it.
Hey! This might not be the best place to contact you, but my team is currently in crisis from a nasty Android Firestore bug. When the user's device switches networks it loses the real-time event listeners and in some cases doesn't re-establish until the app is reinstalled. We submitted a bug report and source for an app with the issue but haven't heard anything in a week. We love the product otherwise, but I thought…
Hey there. Thanks for letting us know. We unfortunately don't have a fix for this at the moment. We've seen reports on network connections not being reestablished, but have been unable to reproduce it so far. If you've filed a bug report, the best way to help us reproduce it is by adding details to the report. That then also gives our team a way to get back in touch with you once they're able to reproduce (and then fix) the problem. Thanks again for the report!
Re: How we spent $30k in Firebase in less than 72 hours
#239Earlier quoted context omitted.
It's only 460k QPS, with 16k documents everything would be cached really well. Or a single instance of redis can serve that load of reads fairly easily.
Good luck with that. A single Redis would not be able to serve that workload. Maybe a single machine but you're really pushing the limits there just with concurrent TCP connections. At that qps Redis has 2 microseconds per request. I agree it caches well but your proposed architecture is definitely not production quality.
Redislabs has hardware recommendations[1] for production environments. Shouldn't be hard for devs to look it up and implement it.
[1]https://redislabs.com/redis-enterprise-documentation/adminis...
Re: How we spent $30k in Firebase in less than 72 hours
#240"This means that every session to our site read the same number of documents as we have of number of payments. #UnaVacaPorDeLaCalle received more than 16,000 supporters, so: 2 million sessions x 16,000 documents = more than 40 Billion requests to Firestore on less than 48 hours." TLDR; Horrible architecture decisions like this can be very costly.
Legit question here; what would be a good architecture for this case?
A caching layer