Welcoming Fabric to Google(firebase.googleblog.com)
firebase.googleblog.com
Welcoming Fabric to Google
https://firebase.googleblog.com/2017/01/FabricJoinsGoogle17.html
132 comments
Really? That's interesting because for our purposes, Fabric's graphs and windows into the data were much too general and coarse-grained.
For instance, there is no way to see all the data! They only give you the first page of top results. I asked them for pagination and they said it was "technically difficult." Whereas with Google Analytics, I could dive as deep as I wanted into the data. Even when I wanted to isolate a unique, rare event out of thousands.
Plus I could search GA, and correlate different events and properties. Fabric only gave the very basic essential graphs. Which might be great for monitoring a giant app like Twitter, where individual events are just noise, but when you're just getting started with 100-1000 users, you want to see everything those users are doing, especially the outliers.
For instance, there is no way to see all the data! They only give you the first page of top results. I asked them for pagination and they said it was "technically difficult." Whereas with Google Analytics, I could dive as deep as I wanted into the data. Even when I wanted to isolate a unique, rare event out of thousands.
Plus I could search GA, and correlate different events and properties. Fabric only gave the very basic essential graphs. Which might be great for monitoring a giant app like Twitter, where individual events are just noise, but when you're just getting started with 100-1000 users, you want to see everything those users are doing, especially the outliers.
Well there is that, and also there is the superior accessibility of crash stats.
The Fabric app makes the crash stats very easily accessible to all the relevant people. You are one tap away from them on your phone.
With GA it takes so much more effort to navigate your way to the crash stats.
As a result you respond to issues much more quickly and decisively with Crashlytics. At least that was our experience.
The Fabric app makes the crash stats very easily accessible to all the relevant people. You are one tap away from them on your phone.
With GA it takes so much more effort to navigate your way to the crash stats.
As a result you respond to issues much more quickly and decisively with Crashlytics. At least that was our experience.
Definitely a missed opportunity for Apple. Crashlytics would have been a huge asset for their own analytics.
They are two completely different tools, they can't be compared, serve different purposes.
The title is a bit ambiguous. From my understanding, Google (Firebase) acquired Fabric from Twitter (not necessarily "joining").
Fabric is one of the top dev tools I use for iOS. I wonder what kind of change is in store...
Fabric is one of the top dev tools I use for iOS. I wonder what kind of change is in store...
Yes, you're right - it is an acquisition. Jeff Seibert clarifies in his tweet https://twitter.com/jeffseibert/status/821780349164388356
More specifically, Twitter is carving out (i.e. divesting) Fabric and selling it to Firebase, which is a wholly owned subsidiary of Google (or perhaps selling it to Google directly).
I think they're saying "joining" because
> Fabric will join Google's Developer Product Group, working with the Firebase team.
> Fabric will join Google's Developer Product Group, working with the Firebase team.
I think you're right but it's weird how this post is coming from the Firebase blog not a main Google products blog (is there one..?). I guess it makes sense...
I would think the "main Google products blog" is https://blog.google/
That's more of a consumer facing blog it feels like. Maybe here? Not sure. https://developers.googleblog.com/
[deleted]
Also a big user of Fabric, really hope this means only good things for Fabric users.
I know it won't happen but I wish they'd stay with the dark/Twitter blue theme.
You could probably hack something in with Stylish
Huh, interesting. I once responded to speculation that Google would buy Twitter by saying [1] they'd be better off neutering Twitter's ad network and data mining ambitions that were largely buoyed by Fabric and Crashlytics, and now I figure this will largely accomplish that. It also disproves my point that Twitter can sustainedly pivot into this space [2] by leaning on Fabric, Digits, and Magic Pony, and answers my more recent musing about how Fabric will fare with Twitter's recent downsizing [3].
[1] https://news.ycombinator.com/item?id=11913828#11914620 [2] https://news.ycombinator.com/item?id=11937756#11942293 [3] https://news.ycombinator.com/item?id=12784274#12784473
[1] https://news.ycombinator.com/item?id=11913828#11914620 [2] https://news.ycombinator.com/item?id=11937756#11942293 [3] https://news.ycombinator.com/item?id=12784274#12784473
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.
> We're currently using Fabric and Crashlytics for our iOS app where I work and this news has prompted us to research alternatives.
I spent the last few months working on getting iOS Support going in Sentry (sentry.io). Would love to hear feedback. Not only do we provide a hosted solution but it's also 100% Open Source which should give you the confidence that it will continue working for you no matter what happens.
I spent the last few months working on getting iOS Support going in Sentry (sentry.io). Would love to hear feedback. Not only do we provide a hosted solution but it's also 100% Open Source which should give you the confidence that it will continue working for you no matter what happens.
Bravo on Sentry - it's a terrific platform. I'm especially fond of the breadcrumbs, they're a great feature.
Thanks so much. It's always great to hear when people enjoy what we're doing :)
Love it as well and I am recommending it to everyone I know who's shipping iOS apps
Indeed. I was about to write and suggest sentry for crash reporting plus extra features. I'm starting to use breadcrumbs now to test and see how they can be useful.
From the article
> [...] we expect that Crashlytics will become the main crash reporting offering for Firebase [...]
They will be integrating Crashlytics into their core developer offering, Firebase. Looks like if you are just using Fabric's Crashlytics service you will be ok. But there is more room to worry if you are using some of Fabric's other tools.
> [...] we expect that Crashlytics will become the main crash reporting offering for Firebase [...]
They will be integrating Crashlytics into their core developer offering, Firebase. Looks like if you are just using Fabric's Crashlytics service you will be ok. But there is more room to worry if you are using some of Fabric's other tools.
Additionally, Firebase was an independent company bought by Google back in 2014 [1]. There was some teeth-gnashing and worry at the time that Firebase may be killed off, but it has only grown - in some ways by leaps and bounds - since then. It even had a prominent position at Google I/O 2016. [2]
We plan to stick with Crashlytics at my company.
[1] https://techcrunch.com/2014/10/21/google-acquires-firebase-t...
[2] https://scotch.io/bar-talk/a-look-at-the-new-firebase-a-powe...
We plan to stick with Crashlytics at my company.
[1] https://techcrunch.com/2014/10/21/google-acquires-firebase-t...
[2] https://scotch.io/bar-talk/a-look-at-the-new-firebase-a-powe...
Having a popular developer tool that is already integrated with a lot of apps in both iOS and Android is valuable strategic asset for Google. Analytics and ads go hand in hand and as tracking cross-app behavior is hard, and having a library that is installed in many apps makes it easier.
I'm pretty sure that this was the strategic thinking when started to invest to app developer tools (Crashlytics, Fabric, Digits, MoPub). It's interesting to speculate why they are selling Fabric, is their business model focus moving away from mobile ads?
I'm pretty sure that this was the strategic thinking when started to invest to app developer tools (Crashlytics, Fabric, Digits, MoPub). It's interesting to speculate why they are selling Fabric, is their business model focus moving away from mobile ads?
It's definitly interesting to see them move. Google already has Google Analytics/Firebase Analytics which pretty much every app developer integrates given their generous free tier so the extra data seems to be diminishing returns for Google. Seems to be more of a loss for Twitter than Google's gain given now they won't have a GA like equivalent.
I don't think Fabric was ever used for Twitter ad targeting just by reading their TOS unlike the Google/FB world and their analytics products but I could be wrong. Seems like a case where Twitter didn't realize the full potential of Crashlytics and Answers.
I don't think Fabric was ever used for Twitter ad targeting just by reading their TOS unlike the Google/FB world and their analytics products but I could be wrong. Seems like a case where Twitter didn't realize the full potential of Crashlytics and Answers.
I made a poll in my circles and a surprisingly few iOS developers use Google Analytics. Whereas Crashlytics is used by 70%, Hockey App by the rest.
Can you please some give examples to developer tools and services Google abandoned that frustrated people? I can't seem to recall any but Google Code Project Hosting and Code Search.
I'm not really aware of what dev tools Google killed besides code/code search, but I would hope that as they get more serious about Google Cloud they will get better about not pissing off developers unnecessarily.
I would say don't fear for now. Google is pouring a lot of money there and want to win developers hearts. They have GA on web, to some extend, now want to grab your mobile and web data. I see it highly unlikely that Firebase will decelerate.
As an alternative, suggesting Countly (open source) - http://github.com/countly/countly-server - with crash reporting, push notifications and analytics.
As an alternative, suggesting Countly (open source) - http://github.com/countly/countly-server - with crash reporting, push notifications and analytics.
Check out Apteligent, better crash reporting as well as performance data, user behavior and business impact. As a bonus your data doesnt go into Twitter or Google's ad networks and it's COPPA compliant.
I heard great things about Apteligent, especially from larger apps and teams. Was Twitter using the data from Crashlytics for ads? I am not sure if there's a clear answer, but they are an ad company at the end of the day.
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.
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.
HockeyApp is great. Owned by Microsoft, who has doubled down on mobile tools with Xamarin. For beta distriubtion, HockeyApp is a superior product. And it has an API (so you can, say, auto register iOS devices). Fabric is just more known and considered cooler (they do have nice CSS transitions :).
You could try AppDynamics mobile RUM product.
https://www.appdynamics.com/product/mobile-real-user-monitor...
Disclosure : I work there
What have they abandoned?
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".
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.
Having experienced some rather concerning keychain issues with Digits a few months back and seeing the writing on the wall with Twitter and their stockholders calling for blood I dropped all of my Fabric dependencies in November.
For crash reporting the best alternative I found (superior to Crashlytics IMO) is Sentry[0]. It's been awesome so far and allows you to easily federate crash reporting over multiple platforms. I have no association with the company.
[0]: https://sentry.io/
For crash reporting the best alternative I found (superior to Crashlytics IMO) is Sentry[0]. It's been awesome so far and allows you to easily federate crash reporting over multiple platforms. I have no association with the company.
[0]: https://sentry.io/
Aside we're also building a bunch of open source tooling (our entire platform is open source) around mobile, so if you're looking to roll your own or bring something in-house, we'd love to hear your feedback.
https://github.com/getsentry
https://github.com/getsentry
Can confirm, Sentry is awesome. It's been very easy to integrate in our web apps and the results are helpful.
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.
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.
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
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
[deleted]
As an example - we use Crashalytics at work. Even if Google built a parity product, we wouldn't have switched; Crashalytics was a known entity with few pain points. So if Google wanted our data (and others like us..) the only way to get that data is by acquiring Crashalytics. tldr: they bought it for the install base, not the product.
What does this mean for Twitter Digits? Will their free SMS authentications continue?
It would be a perfect fit if they phased in Twitter Digits as a Firebase authentication provider - I suspect many developers (including myself) already use these 2 services in tandem.
It would be a perfect fit if they phased in Twitter Digits as a Firebase authentication provider - I suspect many developers (including myself) already use these 2 services in tandem.
They do say
> During the transition period, Digits, the SMS authentication services, will be maintained by Twitter.
but it's unclear what will happen long term
> During the transition period, Digits, the SMS authentication services, will be maintained by Twitter.
but it's unclear what will happen long term
Long-term it will be with Google.
It says so here: As part of this acquisition Digits will be transitioning to Google over the coming months but will be maintained and operated by Twitter in the interim
It says so here: As part of this acquisition Digits will be transitioning to Google over the coming months but will be maintained and operated by Twitter in the interim
The main thing is that Digits is free. We are using it in our products. I hope Google doesn't have plans to earn money here
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)
(I was an employee 2012–2016)
Twitter has a bunch of longstanding SMS delivery agreements, so it's quite cheap.
Crazy thought but does Digits have value for Google with adding SMS to Allo?
Silly me - I was concerned they somehow acquired the Fabic python library.
http://www.fabfile.org/
http://www.fabfile.org/
Yeah, that moment of panic when you think something Google acquired is something you use.
In the case of fabric/fabfile this wouldn't matter, as fabric/fabfile looks dead anyway. No Python 3 support, no road map, last Github activity 5 months ago.
There is a roadmap: http://www.fabfile.org/roadmap.html
One of the goals in the roadmap is to move part of Fabric's functionality into another library (Invoke), which does have recent activity and supports Python 3.
One of the goals in the roadmap is to move part of Fabric's functionality into another library (Invoke), which does have recent activity and supports Python 3.
Unfortunately, the main dev has been saying that he'll be releasing a rewrite with Python 3 support "at the end of the month" for the past 2-3 years. There's actually a fork ("Fabric3") which fully supports both Python 2.7 and Python 3.4+, but the Fabric dev refuses to merge in any PRs that have been submitted to help with Python 3 support. It's somewhat infuriating.
https://github.com/fabric/fabric/pulls?q=is%3Apr+python+3
https://github.com/fabric/fabric/pulls?q=is%3Apr+python+3
Buff, same here. It took me a lot of time to realize the blog post doesn't talk about my fab files.
> to free developers from so much of the complexity associated with modern software development, giving them back more time and energy to focus on innovation
I was thinking Fabric is a nice tool indeed, but what is the connection, and why they want to add cloud messaging and analytics.
> to free developers from so much of the complexity associated with modern software development, giving them back more time and energy to focus on innovation
I was thinking Fabric is a nice tool indeed, but what is the connection, and why they want to add cloud messaging and analytics.
(This Fabric is not the popular python library for deploying things from the command line.)
So weird to see the mostly dead http://crashlytics.com and its iOS 6-era design (linen texture!) as it's been superseded by "Fabric" and now "Firebase". Seems like such a strong brand name to kill in favor of these very generic alternatives.
Actually, the entire platform is called Fabric while Crashlytics is only a part of the platform (albeit the main part...).
They've just kept the website as-is since being acquired by Twitter and integrated into the larger Twitter products portfolio.
It is confusing at first though.
They've just kept the website as-is since being acquired by Twitter and integrated into the larger Twitter products portfolio.
It is confusing at first though.
its confusing at second, third, fourth looks too. I use Fabric and Crashlytics pretty heavily and still end up here a few times a month without thinking.
I end up going almost exclusively to Crashytics' website, then being redirected at login and have the "oh, right" moment.
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.
[deleted]
twitter.com is also blocked, so no difference.
Twitter.com only, or also Crashlytics services too?
How things change, three years ago Fabric was a key part of Twitter's platform strategy. This has to feel like a big letdown, unless you're Jeff Seibert.
Well, this is probably good for Google and Fabric, but I'm less sure about it being good for Twitter. My opinion has long been that Twitter needed to double-down on being developer friendly and developer focused. This seems like the exact opposite of that.
It strikes me as being about as smart as Sears selling off the Craftsman brand. At least, to me, this feels self-defeating.
It strikes me as being about as smart as Sears selling off the Craftsman brand. At least, to me, this feels self-defeating.
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.
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?
My main problems with the console are:
1) Lack of in depth analytics on storage and the database. You give us some vague bandwidth and space metrics which aren't that useful.
2) No way to search, filter, or query the database. The database manager is really only a JSON editor which isn't that useful. I'm guessing this is a consequence of the database API being very limited.
3) Editing rules using a JSON or even Bolt becomes unmaintainable once you reach a certain complexity. Specially if you want to create role based permissions. There should be a UI to manage rules. Even better, there should be a role based permissions system built in.
1) Lack of in depth analytics on storage and the database. You give us some vague bandwidth and space metrics which aren't that useful.
2) No way to search, filter, or query the database. The database manager is really only a JSON editor which isn't that useful. I'm guessing this is a consequence of the database API being very limited.
3) Editing rules using a JSON or even Bolt becomes unmaintainable once you reach a certain complexity. Specially if you want to create role based permissions. There should be a UI to manage rules. Even better, there should be a role based permissions system built in.
Your texts and instructions are byzantine. For example, what is the following supposed to say:
"By default, your Firebase Analytics data will enhance other Firebase features and Google products. You can control how your Firebase Analytics data is shared in your Firebase settings at any time. Link your AdMob app(s) to Firebase and we'll share your data from the free Firebase Analytics tool with AdMob to improve app monetization and user engagement. You understand that this linkage may also allow AdMob Data to be shared with Firebase for enhanced reporting purposes."
I guess it means something like "Link you Admob account to Firebase" but it sounds kind of scary.
"By default, your Firebase Analytics data will enhance other Firebase features and Google products. You can control how your Firebase Analytics data is shared in your Firebase settings at any time. Link your AdMob app(s) to Firebase and we'll share your data from the free Firebase Analytics tool with AdMob to improve app monetization and user engagement. You understand that this linkage may also allow AdMob Data to be shared with Firebase for enhanced reporting purposes."
I guess it means something like "Link you Admob account to Firebase" but it sounds kind of scary.
In some ways I agree with you about Google-ifying of the UI design and that confusion. (e.g. there's been a "Google Developers Console" and also a separate "Google Play Developers Console" and I found the relationship between those confusing at times.)
OTOH, once I started using Firebase console, I felt that Google was taking a step in the right direction. That is, my general impression has been that Firebase's console is easier for me to make sense of and there is less needless complexity/confusion.
One example for me was my general impression with setting up Google Cloud Messaging with the old Google Developer Console (a couple of years ago) and more recently setting up Firebase messaging in the Firebase console. It just seemed easier and smoother to set up Firebase messages. There seemed to be less gotchas and dead ends, for what that's worth.
OTOH, once I started using Firebase console, I felt that Google was taking a step in the right direction. That is, my general impression has been that Firebase's console is easier for me to make sense of and there is less needless complexity/confusion.
One example for me was my general impression with setting up Google Cloud Messaging with the old Google Developer Console (a couple of years ago) and more recently setting up Firebase messaging in the Firebase console. It just seemed easier and smoother to set up Firebase messages. There seemed to be less gotchas and dead ends, for what that's worth.
I haven't heard of Fabric before. Fabric seems to have an ambiguous name and their marketing website is equally ambiguous. Something to do with mobile app analytics? I find this trend in developer tool marketing to be appalling.
They used to be called crashlytics. Best crash reporting tool . Just works. I guess they probably are a lot more interested in ranking for stuff like crash reporting than people chancing upon their website and trying to figure out who they are.
agreed
What about Fastlane?
Glad to see this under a better umbrella. The Twitter developers kept blowing off everyones' requests for Crashlytics to support the gradle-experimental plugin (which was necessary to use the NDK within Android Studio for the longest time).
Unlikely that we'll see improvements in Fabric services for a while... presumably, engineering resources will be focused on integrating with Firebase :(
Anyone recommend alternatives for Crashlytics and Digits?
Anyone recommend alternatives for Crashlytics and Digits?
Using Countly for crash reporting (https://count.ly/crash-reports/)
Apteligent, for one. Long time player with a strong offering for crash reporting and much more. (I'm not associated, just a fan.)
Ahh they used to be called Crittercism. Yeah I used to use them too
As an alternative for Digits Facebook offers Accountkit (https://developers.facebook.com/products/account-kit) which provides phone number and email based login.
Full disclosure, I work for Facebook.
You can look at the most popular crash reporting sdks here: https://mightysignal.com/top-ios-sdks?tag=6
https://www.hockeyapp.net (they were bought by Microsoft)
Any recommendations for cloud-based CI/CD services? I'm currently using Bitrise, then delivering to Fabric via fastlane.
Do you have any issue with Bitrise? Just curious (CTO here)
You can use fastlane on Bitrise.io if you want to, and you can use the Bitrise CLI locally (https://www.bitrise.io/cli), similar to fastlane.
You can use fastlane on Bitrise.io if you want to, and you can use the Bitrise CLI locally (https://www.bitrise.io/cli), similar to fastlane.
I'm an active user of Fabric and have found it rather convoluted and limited. For example, there is no way to easily get device UUIDs from Beta testers. Given they also sponsor Fastlane, I'm blown away they haven't provided a way to automatically register UUIDs. This is possible with HockeyApp through their API and some Fastlane scripts.
Crashlytics is their killer feature. The rest is mediocre. Hopefully Google will improve it. I'm not holding my breath.
Crashlytics is their killer feature. The rest is mediocre. Hopefully Google will improve it. I'm not holding my breath.
You might be interested in buddybuild's beta distribution which does automatic UDID management.
It basically makes it so neither the developer nor the tester ever have to worry about UDIDs ever again. Instead you can send a build to a new tester & trust they can immediately install it.
[Disclaimer, I built that feature at buddybuild]
It basically makes it so neither the developer nor the tester ever have to worry about UDIDs ever again. Instead you can send a build to a new tester & trust they can immediately install it.
[Disclaimer, I built that feature at buddybuild]
More of a comment on Firebase -- as someone who was using them pre and post merge -- a whole bunch of small things are notably worse.
They said "great adoption" but it was actually forced (my previous company held on as long to the old Firebase as we could), from things to poor naming specs on export, base URL structures changing, the live-view able to handle less data points and a number of other small things, it was a bit of a let down.
Hoping this goes better.
They said "great adoption" but it was actually forced (my previous company held on as long to the old Firebase as we could), from things to poor naming specs on export, base URL structures changing, the live-view able to handle less data points and a number of other small things, it was a bit of a let down.
Hoping this goes better.
Best of luck, really dig the platform.
The only thing I'm worry about is Digits. I hope Google won't close it
I guess they don't mean this Fabric: http://www.fabfile.org/
While Firebase is still awesome, there was a definite downgrade in support when Google integrated them. Hopefully this will go better.
Firebase team member here,
Anything specific you'd like to let us know about? Definitely agree that it hasn't been the smoothest transition--it's super hard to provide 24/7 support to hundreds of thousands of developers. Any feedback you can provide will help us refine that process.
Anything specific you'd like to let us know about? Definitely agree that it hasn't been the smoothest transition--it's super hard to provide 24/7 support to hundreds of thousands of developers. Any feedback you can provide will help us refine that process.
Let's hope it doesn't end up like Adwhirl. :(
I used it in my all iOS development. Will it be 2nd class?
What does this mean for moPub ?
[deleted]
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
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.
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
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.
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
Also, searches for firebase have increased, which indicates more interest: https://www.google.com/trends/explore?date=today%2012-m&q=fi...
Also, searches for firebase have increased, which indicates more interest: https://www.google.com/trends/explore?date=today%2012-m&q=fi...
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/ about the time of the sharp decline indicated.
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)
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)
> make the 90% use cases simple, and make the complicated 10% possible
That's not what we have experienced while using Firebase for the last year.
I have no complaints about storage, but the database is so limited that most projects will become impractical or simply impossible for a number of reasons:
1) No remotely decent querying capabilities
2) No search capabilities other than building your own or relying on third party like Elastic
3) No way to reference data, make joins, etc, like Rethink, Mongo, Arango, or others have.
I'd say the vast majority of projects will need one or more of those points which really doesn't fit into your statement.
That's not what we have experienced while using Firebase for the last year.
I have no complaints about storage, but the database is so limited that most projects will become impractical or simply impossible for a number of reasons:
1) No remotely decent querying capabilities
2) No search capabilities other than building your own or relying on third party like Elastic
3) No way to reference data, make joins, etc, like Rethink, Mongo, Arango, or others have.
I'd say the vast majority of projects will need one or more of those points which really doesn't fit into your statement.
> 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).
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).
Another option to check out is Couchbase Mobile. Open source, self-hosted database with full offline functionality and a solid sync solution.
I think Firebase is pretty amazing. Have been a fan since I met some of the team (I think it was at the 2011 Launch conference). Like anything, though, there are tradeoffs.
Briefly, I'd say that there's overlap, with Couchbase Mobile tending to shine toward the more complex end (including making the 10% much easier), and also being extremely easy to use as a substitute for SQLite/Core.
(I work for Couchbase.)
I think Firebase is pretty amazing. Have been a fan since I met some of the team (I think it was at the 2011 Launch conference). Like anything, though, there are tradeoffs.
Briefly, I'd say that there's overlap, with Couchbase Mobile tending to shine toward the more complex end (including making the 10% much easier), and also being extremely easy to use as a substitute for SQLite/Core.
(I work for Couchbase.)
> All data is stored and transmitted as JSON – the embedded database, the database server, REST APIs, stream APIs, and batch APIs.
That’s likely going to become an issue with my usecase – even currently while using a custom binary format on the net, and decoding with Java NIO, we’re seeing ~80-90% CPU utilization on latest Android phones for ~4-5 seconds during connection to sync the latest tenthousands to hundredthousands of messages.
I doubt using Strings, and specifically JSON, will make that more performant.
(But I’ll definitely look into your code as inspiration for how to continue)
That’s likely going to become an issue with my usecase – even currently while using a custom binary format on the net, and decoding with Java NIO, we’re seeing ~80-90% CPU utilization on latest Android phones for ~4-5 seconds during connection to sync the latest tenthousands to hundredthousands of messages.
I doubt using Strings, and specifically JSON, will make that more performant.
(But I’ll definitely look into your code as inspiration for how to continue)
> It’d be a lot nicer place if projects like this would be open, so people could use it on their own systems
Check Feathers.js if you want realtime on your own system.
Check Feathers.js if you want realtime on your own system.
I have, sadly it doesn’t really scale well enough.
I work on Quasseldroid, an android client for the quassel IRC bouncer, and the idea is that you can always access all messages instantly, while the client only buffers a few of them.
This works quite well, and is easy to do with Feathers.js and others, even Firebase...
...if there wasn’t the issue that the average user is in hundreds of channels and gets tenthousands of messages per hour, in some cases, even thousands of messages a second (if the user is in a channel with > 10k other users, for example, and everyone is chatting – such as during eurovision on Quakenet’s #eurovision).
Although users self-host, so we don’t have infrastructure costs, they usually do so on a raspberry pi – and Feathers.js can’t easily handle thousands of changes per minute to its database while running on a raspberry pi, and accurately sync them to multiple clients.
I work on Quasseldroid, an android client for the quassel IRC bouncer, and the idea is that you can always access all messages instantly, while the client only buffers a few of them.
This works quite well, and is easy to do with Feathers.js and others, even Firebase...
...if there wasn’t the issue that the average user is in hundreds of channels and gets tenthousands of messages per hour, in some cases, even thousands of messages a second (if the user is in a channel with > 10k other users, for example, and everyone is chatting – such as during eurovision on Quakenet’s #eurovision).
Although users self-host, so we don’t have infrastructure costs, they usually do so on a raspberry pi – and Feathers.js can’t easily handle thousands of changes per minute to its database while running on a raspberry pi, and accurately sync them to multiple clients.
Oh wow.
So how did you/are you solving this?
So how did you/are you solving this?
Well, while I only work on the Android client, the solution currently in use is a large codebase of code specifically written for this single purpose. In C++. Compiled natively. That’s the main reason why good performance with the system is even possible.
A huge performance boost (reconnection times down from ~2 minutes to ~12 seconds on 64kbps 2G network, using a Nexus 5X) could be accomplished by using Java NIO with non-copying IO for parsing the custom binary protocol, but we’re looking into using flat protobufs for improving performance further.
But then the database layer becomes the bottleneck. SQLite is far too slow to be normally usable, most users use PostgreSQL for the backing database.
Basically, the trick is in "don’t use JSON and JS, do stuff with native code and binary protocols to reduce overhead".
But this makes maintenance basically impossible, and isn’t really ideal either.
DISCLAIMER: I do not speak for the Quassel project, all opinions represented here are solely my own.
A huge performance boost (reconnection times down from ~2 minutes to ~12 seconds on 64kbps 2G network, using a Nexus 5X) could be accomplished by using Java NIO with non-copying IO for parsing the custom binary protocol, but we’re looking into using flat protobufs for improving performance further.
But then the database layer becomes the bottleneck. SQLite is far too slow to be normally usable, most users use PostgreSQL for the backing database.
Basically, the trick is in "don’t use JSON and JS, do stuff with native code and binary protocols to reduce overhead".
But this makes maintenance basically impossible, and isn’t really ideal either.
DISCLAIMER: I do not speak for the Quassel project, all opinions represented here are solely my own.
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.
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.
Sorry, just to add it's WAY cheaper than part-way solutions like Pusher.
It's better because:
Instant crash reporting reduces release time anxiety. iTunes and Google analytics need 24 hour collection period.
Fabric can offer Fastlane and Beta -- Toolkits that help deal with distributing builds to testers and releasing apps. Google has nothing to compete with here.
Whatever way Fabric seem to define active users and sessions they seem to produce more accurate reporting while Google numbers integrated with the exact same app produce higher more ego stroking numbers.