Live data from Hacker News

Google is killing Fabric in mid-2019, pushes developers to Firebase

venturebeat.com

41–50 of 60 posts

Re: Google is killing Fabric in mid-2019, pushes developers to Firebase

#41
post #35

Just a reminder that, if you critically depend on a IaaS/PaaS/SaaS, you should be able to trivially replace it, sometimes as quickly as overnight. Having the service be completely open source so you can self-host generally helps, as does open protocols and standards. Especially important when it's a Google service given their historical speed of deprecation and abruptness in announcement.

If you can trivially replace it with something else overnight, the SaaS might be a bit too simplistic to use in the first place, no?

Or there is healthy competition in the space.

I think OP means you should write your interfaces with SaaS such that changing to a different provider is relatively easy (just rewrite a little client code or something to fit the new provider to your abstractions).

Re: Google is killing Fabric in mid-2019, pushes developers to Firebase

#42
post #32

Why move to firebase when it will be shutdown when it becomes useful?

Firebase seems to be pretty integrated with Google's GCP strategy, as well as Android push notifications with FCM. Not saying concern over Google's commitment to various tools is unfounded, but it seems that generally things that are tied into their core goals are pretty safe. GCP is very important to Google, Inbox was an interesting UI built on top of Gmail.

FCM is only the third in a row of push notification solutions for Android (preceded by C2DM and GCM), and it'll be replaced someday, too.

Re: Google is killing Fabric in mid-2019, pushes developers to Firebase

#43

Earlier quoted context omitted.

That seems a little exaggerated. It looks like Google Cloud terms of service promise a year's notice for products in general availability. I don't think they've broken that promise? Though of course, even with notice, migration can still be annoying.

In my opinion, a year is not a lot of time for any complex integration with a service. Compare that to AWS which still support effectively-retired products indefinitely.

I agree, but it's not "overnight" either.

Re: Google is killing Fabric in mid-2019, pushes developers to Firebase

#44

Earlier quoted context omitted.

In my opinion, a year is not a lot of time for any complex integration with a service. Compare that to AWS which still support effectively-retired products indefinitely.

I agree, but it's not "overnight" either.

At a speed that's faster than the expected sunset speed of the product without significant impact to your business is a bit of a mouthful.

Re: Google is killing Fabric in mid-2019, pushes developers to Firebase

#45

Earlier quoted context omitted.

This is why we need truly distributed webapps rather than monolithic tied-to-domain apps. Doing this right is a hard problem and many of current solutions are still essentially centralized despite their reliance on certain aspects of P2P.

Open standards are superior to the complexity of distributed webapps. I can port my Gmail account to Fastmail with a few clicks. There's no lock in with my email data. I can put my mail anywhere! That should be the goal of all hosted data; portability, so you're never beholden to a SaaS provider.

But this is also starting to not be true. Gmail is very slowly adding features not in smtp/imap and one day they might just break away and have their closed email. This happened on multiple occasions with xmpp. At one point you could write from icq to hangouts to facebook messanger. After companies gathered critical mass of users they turned off federation. This is one of the main reasons people use facebook messanger (almost everyone has it) and this might happen to gmail quite easily. Almost everyone had gmail at some point so this idea is pretty possible. Many people would then keep gmail account just to comunicate with people who dont have email.

Re: Google is killing Fabric in mid-2019, pushes developers to Firebase

#46
post #45

Earlier quoted context omitted.

Open standards are superior to the complexity of distributed webapps. I can port my Gmail account to Fastmail with a few clicks. There's no lock in with my email data. I can put my mail anywhere! That should be the goal of all hosted data; portability, so you're never beholden to a SaaS provider.

But this is also starting to not be true. Gmail is very slowly adding features not in smtp/imap and one day they might just break away and have their closed email. This happened on multiple occasions with xmpp. At one point you could write from icq to hangouts to facebook messanger. After companies gathered critical mass of users they turned off federation. This is one of the main reasons people use facebook messange…

I hate to beat the dead horse as I often do on HN, but the support of open standards requires constant vigilance. If Gmail begins to "wall the garden off", you must move to a more open provider (such as Fastmail, but any provider providing standards compliant email works).

Re: Google is killing Fabric in mid-2019, pushes developers to Firebase

#47

Firebase is the worst name ever. Literally it describes absolutely nothing. I really wish Google would take a look at naming.

Google acquired that company.

And the name even has half the word "database" in it, which is much more descriptive than most tech names.

Re: Google is killing Fabric in mid-2019, pushes developers to Firebase

#48
post #30
post #17

Earlier quoted context omitted.

These things come and go. One could have been just as wrong to focus on Silverlight, OpenSolaris, SmallTalk, etc, etc, etc, or even your own company's ABI.... And is it really wrong to spend a couple of years becoming an expert Plan 9 user just because it doesn't take over the world? I still think it's all (mostly) time well spent.

> And is it really wrong to spend a couple of years becoming an expert Plan 9 user just because it doesn't take over the world? I still think it's all (mostly) time well spent. https://en.wikipedia.org/wiki/Opportunity_cost

it's hard to gauge opportunity cost, since architectures fade in and out of popularity and patterns succeed where the frameworks that introduced them fail.

I doubt Rob Pike and Ken Thompson would give up the experience of writing Plan 9; its lessons persist in Go and other systems they've designed. Google's tech stack was pioneered by systems programmers who built their career writing for supercomputers, forced to target commodity hardware.

Patterns have a much longer shelf-life than their originating products.

Re: Google is killing Fabric in mid-2019, pushes developers to Firebase

#49
Firebase is revolutionary. If you haven't used it, it means you can remove your reliance on all the server side logic you currently maintain. It is a huge philosophical change but is the perfect complement to serverless architectures.

This is smart by Google. AWS AppSync provides much of the same functionality but gives you the benefit (if you already know Graphql) of Graphql. Or, it forces you to learn about graphql, which is also the downside. Forcing Fabric customers into the firebase ecosystem makes it look like this was a cheap acquisition from Twitter after all.

The huge win with either platform commitment is you simply focus on your data and forget about the challenging problem of syncing that data across all the platforms. That's (multi client sync) a big, big, big challenge and no one does it well on their own.

Re: Google is killing Fabric in mid-2019, pushes developers to Firebase

#50
post #49

Firebase is revolutionary. If you haven't used it, it means you can remove your reliance on all the server side logic you currently maintain. It is a huge philosophical change but is the perfect complement to serverless architectures. This is smart by Google. AWS AppSync provides much of the same functionality but gives you the benefit (if you already know Graphql) of Graphql. Or, it forces you to learn about graphql…

We follow this exact same architectural approach at hasura.io as well. We are an opensource realtime GraphQL engine on Postgres and just last week we announced event-triggers on Postgres that allows you to call webhooks/serverless functions anytime there is a change in your database. (I work at Hasura)
Post reply on HN