Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Welcoming Fabric to Google

firebase.googleblog.com

Post reply on HN
Print view View original

51–60 of 133 posts

Re: Welcoming Fabric to Google

#51

Post by dabeeeenster »

dabeeeenster wrote: post #50
jondubois wrote: post #39

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 t…

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 i…

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

Re: Welcoming Fabric to Google

#52

Post by gorkemcetin »

I wonder whether China will start banning Fabric servers, as they'll literally be owned by Google. If that would be the case, I cant imagine the mess Chinese developers will face. Assuming they have access to Fabric services now.

Re: Welcoming Fabric to Google

#53

Post by traskjd »

danielhooper wrote: post #23

Knowing Google's reputation with abandoning developer tools and services, can anyone offer suggestions as to possible alternatives? Or counterpoints as to why I shouldn't fear this service degrading over the next year or two? We're currently using Fabric and Crashlytics for our iOS app where I work and this news has prompted us to research alternatives.

Disclosure: I'm the CEO of Raygun (https://raygun.com).

Raygun provides Crash Reporting & Real User Monitoring. Across both mobile, backend and desktop (and all mobile, including Xamarin stacks). Love to have you check it out.

We've been picking up a bunch of customers who have been getting nervous with Twitter being in a bad shape and worrying about Fabric previously.

Re: Welcoming Fabric to Google

#54

Post by krschultz »

atarian wrote: post #31

Twitter just lost one of their crown jewels; Fabric is probably the biggest mobile analytics platform out there.

s/lost/sold/

Twitter clearly decided that dev tools were a non-core part of their business. Meanwhile Google has been investing more heavily in becoming a platform company to compete with AWS, and also increasing their investment in mobile through Firebase.

Re: Welcoming Fabric to Google

#55

Post by orbitur »

I'm happy that Crashlytics will live on, as that was something I was concerned about in light of Twitter's recent poor performance.

However, I'm really not looking forward to the eventual Firebase-ifying/Google-ifying of the UI/design. The Firebase/Google Console interfaces are terrible. Just awful. I cringe thinking about what could happen to the Crashlytics UI.

Re: Welcoming Fabric to Google

#56

Post by mbleigh »

orbitur wrote: post #55

I'm happy that Crashlytics will live on, as that was something I was concerned about in light of Twitter's recent poor performance. However, I'm really not looking forward to the eventual Firebase-ifying/Google-ifying of the UI/design. The Firebase/Google Console interfaces are terrible. Just awful. I cringe thinking about what could happen to the Crashlytics UI.

Firebase engineer here -- what don't you like about the Firebase Console? Any specific things that we could improve?

Re: Welcoming Fabric to Google

#57

Post by guelo »

fharper1961 wrote: post #2

Seems to me like the main value for Google is the data from all the apps that have Fabric SDK integration (e.g. Crashlytics). Quote from the Fabric blog post https://fabric.io/blog/fabric-joins-google "Fabric has grown to reach 2.5 billion active mobile devices".

They have the app data on the Android side which is probably a decent proxy for the iOS app market, but Crashlytics gives them direct visibility into a sizable chunk of the ios market.

Re: Welcoming Fabric to Google

#58

Post by sulam »

bdd wrote: post #29
jrowley wrote: post #11

Earlier quoted context omitted.

I wonder what it costs to operate Twitter Digits. I can't imagine they are using Twilio as an SMS gateway.

Twitter used to be the biggest SMS sender in United States. Much larger than Twilio, even bigger than operators like Verizon and AT&T. Infrastructure that came from Cloudhopper acquisition with continuous care and improvement gave Twitter a reliable and super cost effective _world-wide_ SMS delivery platform. (I was an employee 2012–2016)

Hi Berk. ;)

Re: Welcoming Fabric to Google

#59

Post by on_and_off »

atarian wrote: post #31

Twitter just lost one of their crown jewels; Fabric is probably the biggest mobile analytics platform out there.

It is also a bizarre buy.

Google has been building a competitor to fabric crash reporting. 6 months ago it was an MVP, but the version unveiled recently is pretty close to fabric.

I am not sure what they are buying here, it seems that google could sherlock everything that fabric does, especially since fabric is not that great in my experience.

Maybe it just illustrates that I am missing some info on why Google would get in such a buyout

Re: Welcoming Fabric to Google

#60

Post by asciimike »

jondubois wrote: post #39

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 t…

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/). 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). 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)

Post reply on HN