Huh? If Twitter's future is not ads and analytics then what is it?
Welcoming Fabric to Google
41–50 of 133 posts
Re: Welcoming Fabric to Google
#42Best of luck, really dig the platform.
Re: Welcoming Fabric to Google
#43What 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.
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
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
Re: Welcoming Fabric to Google
#44Based 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…
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.
Re: Welcoming Fabric to Google
#45Earlier quoted context omitted.
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).
Firebase is really just a Google brand at this point, not a separate company.
Re: Welcoming Fabric to Google
#46(This Fabric is not the popular python library for deploying things from the command line.)
Re: Welcoming Fabric to Google
#47Based 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…
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...
Re: Welcoming Fabric to Google
#48Earlier quoted context omitted.
I think they're saying "joining" because > 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/
Re: Welcoming Fabric to Google
#49Unlikely 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?
Using Countly for crash reporting (https://count.ly/crash-reports/)
Re: Welcoming Fabric to Google
#50Based 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 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.