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

121–130 of 133 posts

Re: Welcoming Fabric to Google

#121

Post by pier25 »

asciimike wrote: post #60
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…

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

Re: Welcoming Fabric to Google

#122

Post by pier25 »

kuschku wrote: post #97
asciimike wrote: post #60

Earlier quoted context omitted.

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…

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

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

Re: Welcoming Fabric to Google

#123

Post by shortstuffsushi »

skyebook wrote: post #87
huangc10 wrote: post #22

Earlier quoted context omitted.

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.

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.

Re: Welcoming Fabric to Google

#124

Post by kuschku »

pier25 wrote: post #122
kuschku wrote: post #97

Earlier quoted context omitted.

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

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

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.

Re: Welcoming Fabric to Google

#125

Post by pier25 »

kuschku wrote: post #124
pier25 wrote: post #122

Earlier quoted context omitted.

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

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…

Oh wow.

So how did you/are you solving this?

Re: Welcoming Fabric to Google

#126

Post by dirtyaura »

derricgilling wrote: post #102
dirtyaura wrote: post #77

Earlier quoted context omitted.

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, Mo…

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

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.

Re: Welcoming Fabric to Google

#127

Post by HodGreeley »

kuschku wrote: post #97
asciimike wrote: post #60

Earlier quoted context omitted.

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…

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

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

Re: Welcoming Fabric to Google

#128

Post by kuschku »

pier25 wrote: post #125
kuschku wrote: post #124

Earlier quoted context omitted.

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…

Oh wow. 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.

Re: Welcoming Fabric to Google

#129

Post by kuschku »

HodGreeley wrote: post #127
kuschku wrote: post #97

Earlier quoted context omitted.

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

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…

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

Re: Welcoming Fabric to Google

#130

Post by marksomnian »

huangc10 wrote: post #37
jakerockland wrote: post #25

Earlier quoted context omitted.

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
Post reply on HN