4 ms·

Based on my experience with Firebase, it doesn't reduce complexity; it just shifts it around and adds extra costs (both financial and performance costs) to your

Based on my experience with Firebase, it doesn't reduce complexity; it just shifts it around and adds extra costs (both financial and performance costs) to your system. For any serious app, you still need to have a backend server on the side and your Firebase service often becomes bloated and inefficient. Sometimes you want to store the Firebase data inside your main DB as well and so you end up with two sources of truth and Firebase ends up becoming a third wheel to your project (just a bloated data transport layer). It's not surprising that Firebase has been sliding in terms of popularity: http://www.alexa.com/siteinfo/firebase.com http://www.alexa.com/siteinfo/firebase.com It's good for rapid prototyping/MVC but not for any serious use case. I think the big lesson in the framework/devtools space is that the more opinionated the tooling is, the less flexible it becomes and the fewer use cases it covers.

wmblaettler 10y ago
I don't know if the Alexa.com ranking of Firebase.com is really indicative of popularity due to the fact they moved their main site to https://firebase.google.com/ https://firebase.google.com/ about the time of the sharp decline indicated.
bduerst 10y ago
That Alexa rank drop for firebase.com is because they switched from firebase.com to firebase.google.com, not because there is a decrease in interest. The latter is the first result when you search: https://www.google.com/#q=firebase https://www.google.com/#q=firebase Also, searches for firebase have increased, which indicates more interest: https://www.google.com/trends/explore?date=today%2012-m&q=firebase https://www.google.com/trends/explore?date=today%2012-m&q=fi...
dabeeeenster 10y ago
Completely disagree. We started using Firebase; compared to using websockets with e.g Pusher its much, much simpler, primarily because it's a store of state as well as a real time stream. It also handles going off-line and then syncing whilst coming back online perfectly and without any additional code. Yes of course you need a server for most apps, but I don't see a problem with that. Yes, your app might have data in two places, but it's still the simplest way to build a real-time app. My biz has done it several times and the smallest, simplest code base has been with Firebase. Far fewer moving parts too.
- dabeeeenster 10y ago
  Sorry, just to add it's WAY cheaper than part-way solutions like Pusher.
asciimike 10y ago
The approach Firebase takes can be summarized as, "make the 90% use cases simple, and make the complicated 10% possible." Tradeoffs are a core engineering concept, so I think this comes as no surprise to seasoned engineers (the more cynical ones often phrase the question as "what's the catch"). By partnering with Google Cloud Platform, we're working to make the complicated 10% much easier (tradeoff here is lower cost/greater control vs having to be more hands on with your infrastructure). A great example of this is [Firebase Storage](https://firebase.google.com/docs/storage/ https://firebase.google.com/docs/storage/). We've made the 90% of file upload/download use cases easy, while making the 10% of use cases (lifecycle management, object versioning, advanced processing) [accessible through Cloud](https://firebase.google.com/docs/storage/gcp-integration https://firebase.google.com/docs/storage/gcp-integration). Stay tuned for more, similar integrations in the future :) As for the financial costs--you're paying someone else to build and manage your infrastructure, so yes, it will cost more than buying raw infra. Again, this is a tradeoff: is this more valuable to your product/users to answer pages or build features? Depending on where you are in your product lifecycle, YMMV. (Disclosure: I work on Firebase)
- kuschku 10y ago
  > As for the financial costs--you're paying someone else to build and manage your infrastructure, so yes, it will cost more than buying raw infra. Again, this is a tradeoff: is this more valuable to your product/users to answer pages or build features? Depending on where you are in your product lifecycle, YMMV First, 2-3 orders of magnitude more expensive is quite a steep price to pay for the featureset of Firebase. Second, it’s only a good idea to use Firebase if you don’t plan on ever migrating away – because that will be hell. And third, Firebase is a massive engineering effort, and I’m surprised that stuff actually works, considering how much work it is to try and replicate the features I need myself. On the other hand, somehow I feel like Firebase is just an example of the hell we live in, one of the greatest development tools, and all of it is secret, most not even patented, never will be open or free, and just being used to force developers into a closed ecosystem of Google’s Cloud. It’d be a lot nicer place if projects like this would be open, so people could use it on their own systems (because I certainly won’t trust a company running systems in a country ruled by Trump).

wmblaettler 10y ago

I don't know if the Alexa.com ranking of Firebase.com is really indicative of popularity due to the fact they moved their main site to https://firebase.google.com/ https://firebase.google.com/ about the time of the sharp decline indicated.

bduerst 10y ago

That Alexa rank drop for firebase.com is because they switched from firebase.com to firebase.google.com, not because there is a decrease in interest. The latter is the first result when you search: https://www.google.com/#q=firebase https://www.google.com/#q=firebase Also, searches for firebase have increased, which indicates more interest: https://www.google.com/trends/explore?date=today%2012-m&q=firebase https://www.google.com/trends/explore?date=today%2012-m&q=fi...

dabeeeenster 10y ago

Completely disagree. We started using Firebase; compared to using websockets with e.g Pusher its much, much simpler, primarily because it's a store of state as well as a real time stream. It also handles going off-line and then syncing whilst coming back online perfectly and without any additional code. Yes of course you need a server for most apps, but I don't see a problem with that. Yes, your app might have data in two places, but it's still the simplest way to build a real-time app. My biz has done it several times and the smallest, simplest code base has been with Firebase. Far fewer moving parts too.

dabeeeenster 10y ago
Sorry, just to add it's WAY cheaper than part-way solutions like Pusher.

asciimike 10y ago

The approach Firebase takes can be summarized as, "make the 90% use cases simple, and make the complicated 10% possible." Tradeoffs are a core engineering concept, so I think this comes as no surprise to seasoned engineers (the more cynical ones often phrase the question as "what's the catch"). By partnering with Google Cloud Platform, we're working to make the complicated 10% much easier (tradeoff here is lower cost/greater control vs having to be more hands on with your infrastructure). A great example of this is [Firebase Storage](https://firebase.google.com/docs/storage/ https://firebase.google.com/docs/storage/). We've made the 90% of file upload/download use cases easy, while making the 10% of use cases (lifecycle management, object versioning, advanced processing) [accessible through Cloud](https://firebase.google.com/docs/storage/gcp-integration https://firebase.google.com/docs/storage/gcp-integration). Stay tuned for more, similar integrations in the future :) As for the financial costs--you're paying someone else to build and manage your infrastructure, so yes, it will cost more than buying raw infra. Again, this is a tradeoff: is this more valuable to your product/users to answer pages or build features? Depending on where you are in your product lifecycle, YMMV. (Disclosure: I work on Firebase)

kuschku 10y ago
> As for the financial costs--you're paying someone else to build and manage your infrastructure, so yes, it will cost more than buying raw infra. Again, this is a tradeoff: is this more valuable to your product/users to answer pages or build features? Depending on where you are in your product lifecycle, YMMV First, 2-3 orders of magnitude more expensive is quite a steep price to pay for the featureset of Firebase. Second, it’s only a good idea to use Firebase if you don’t plan on ever migrating away – because that will be hell. And third, Firebase is a massive engineering effort, and I’m surprised that stuff actually works, considering how much work it is to try and replicate the features I need myself. On the other hand, somehow I feel like Firebase is just an example of the hell we live in, one of the greatest development tools, and all of it is secret, most not even patented, never will be open or free, and just being used to force developers into a closed ecosystem of Google’s Cloud. It’d be a lot nicer place if projects like this would be open, so people could use it on their own systems (because I certainly won’t trust a company running systems in a country ruled by Trump).