Hacker News Reader

Firebase is fantastic. There is also a steady drumbeat of continual improvements going on in Firebase that keeps making it better and better.

Even when Firebase is using other GCP products under the hood (e.g. Firebase Storage is Cloud Storage and Firebase Functions are Cloud Functions) they often provide a better developer experience that makes things flow smoother. For example, having a Firebase Function running on a schedule is a just an added line in your functions config whereas running a Cloud Function on a schedule requires setting up a Cloud Scheduler Job and linking everything together with PubSub.

Oh definitely. Also, I like their SDK. It's even easier to keep all the app data in Firebase than dealing with native solutions. All the stuff about imperfections of the world like slow connections and so no is taken care of.

My only issue so far is that cloud functions respond very slowly if they are not used for a while. The first time takes 2-3 seconds, thereafter it's in the milliseconds.

But other than that, it's such a nice experience.

I love the idea of Firebase but the thing keeping me off it is the pricing. It's like regular cloud pricing on steroids. Comparing Firebase pricing to say a $5 droplet from DigitalOcean:

- Bandwidth egress uses Google's standard pricing, which is hilariously uncompetitive (~0.12$/GB vs. ~0.01$/GB) and totally inappropriate for anything bandwidth-intensive like image hosting.

- $5/month will get you 2.7M writes, 8.3M reads or 25M deletes on Firebase while Postgres running on a DigitalOcean droplet should be able to handle at least ~500 transactions a second, or ~1.3B per month.

- A GB-month of RAM costs $6.48 on Firebase and is included as part of the $5 droplet from DO.

- A month of CPU time costs $25.92 on Firebase and is included as part of the $5 droplet from DO.

So a $5 DO droplet will give you 1GB-month, 1 CPU-month, 1.3B write transactions and 1TB of bandwidth.

For those same resources you'd pay $6.48 for RAM, $25.92 for CPU time, $2332 for 1.3B writes, and $120 for bandwidth, for a total of $2484.40, or 497x more. Even if you just look at the CPU and RAM, it's 6x more expensive.

I can imagine this being great for a pet project where you might only use a few minutes of CPU time each month but for any kind of scale, the resource costs just seem crazy.

Oh definitely, I am hoping to see serious competitors so that the prices go down. I also wish for an open-source alternative where we can spin it on our own server.

That said, even at these prices, it is quite useful. I think If you need that many writes for cheap, it's probably part of your core product and you can concentrate on building a custom solution for that and take advantage of the rest of the product for the more mundane tasks of your business, like user access management for example.

Besides, If you think about it, 1.3 billion writes are about two writes per every person in USA and EU combined. There are usually a lot of things that you can do to optimize and reduce writes and make each write worthwhile.

Are you equating one droplet with no redundancy or scalability to Firebase's services? Also, will postgres sustain 500 transactions/sec for a month to reach 1.3B. Sounds like serious stretch to me.

I'm pretty happy with Firebase compared to other platforms I used. At this point I'm using all major components including hosting, firestore, cloud storage, cloud functions, etc.

I wrote up a whole design document of how we designed our app a few months back:

https://getpolarized.io/2019/01/03/building-cloud-sync-on-go...

I think the biggest thing I miss is having some sort of full-text search support for the JSON storage. I'm used to having Elasticearch so this was a big of a headache.

One of the nice things is that you can use some of the easier things in Firebase but also dive down and use more lower level components in Google Cloud when necessary.

For example, I might need a more complex caching CDN for our server-side rendered pages and I might end up deploying that next.

I definitely hope Google stays competitive here as it will make my job a lot easier.

Yes, they suggest using something like Algola for text search.

Yesterday, I was galavanting their marketplace for apps that you can use in your GCP and I like the idea a lot. I think they are doing something similar for Firebase and call it "Firebase Extensions".

I think this can also be another gold rush. I was hoping to find Cryptocurrency exchange ticker dataset(but there were only at low resolution). I think Salesforce has such a marketplace where developers write apps for automating things, enable things, sell data and so on. Would be nice to have a standardized API marketplace.

So much potential there. Easy to start with and a lot of depth if you want to dive deeper.

The extensions/plugins are kind of cool in that they build in a bunch pre-existing functionality like automatic thumbnail generation for uploaded images.

There's definitely a ton of 3rd party plugins / innovation that could happen here much the way Intercom, etc was able to build on top of other people's data.

Ditto, the area is getting ripe for exploitation IMHO.

Are you considering training a ML model to automatically generate questions based on highlighted text for the anki-system?

> That's why I am under the impression that at the end the gold rush for the cloud, the result would be something like Firebase.

What's funny is Google Cloud is going in the opposite direction. They've pretty much destroyed the standard App Engine in the upgrade to Python 3. With the latest updates they've been moving towards becoming just another provider of dumb boxes where you do everything yourself. I'm expecting the standard App Engine to be deprecated at some point soon as they push everyone to the flexible environment (which is pretty much what you can get at any cloud provider).

As much as I always thought the app engine development model was pretty sweet, it seems like it just wasn't that compelling in the marketplace. You look at the biggest sites built on appengine and while there's some good stuff there it is not exactly mind blowing. If the development model were really that much more productive you'd expect there to be more there.

I'm sure you're right, but they already had a parallel service (App Engine flexible environment) that did what all the other providers did. I don't see why they had to destroy the standard environment.

It's not like they have a shortage of developers to work on it.

I've built the early version of our platform atop Firebase and I agree, it's a great acquisition by Google.

Integrated authentication, deployment, database and file-serving.

I do have concerns about being closely tied to Firebase (mainly for cost reasons down the road - just eyeballing the pricing, it seems things can escalate very quickly). I agree that an open-source hosting alternative would be amazing (though that would obviously chip away at some of the "plug-and-play" benefits).

From a technical perspective, though it's fantastic.

It's a natural evolution of c-panel on some random server.

Not really. C-panel is a total Wild West, with no real security or scalability or usability for that matter.

Saying Firebase is the new C-panel is like saying Uber is the new O’Reilly Auto Parts.

Firebase is great but the web sdk bundle sizes are just outrageous. They must sort this or it goes against everything google wants from “web speed”.