Like Facebook (Parse), if Google also decides that Firebase is not profitable and decides to close down, how do we run our applications without rewriting?

How do we protect ourselves, if Google decides to increase the price of Firebase 3-4 times in a single day?

Even just a public pledge from Google saying that they will open source the full featured Firebase if they decide to close down the devision will go a long way to alleviate this fear.

[0]: https://github.com/rethinkdb/horizon

RethinkDB doesn't require polling. It's like their #1 feature and differentiator from other non-sql databases.

We use websockets in our realtime platform.

[1] http://rethinkdb.com/docs/writing-drivers/

One simple solution is giving each state a defined name, and keeping a socket open from mobile. If the connection is restarted, each side can name their current state, and the delta can also be easily synced.

Later on, changes can be directly transmitted via the socket.

(I am working on something like that currently myself).

It's not going anywhere.

AWS has a head start and a great product catalog, Azure has the windows/office/server ecosystem, but Google has been doing scaled computing for a very long time and has contributed to many of the innovations in the industry. Although they're newer with less features, what they do have is more advanced and the Google name carries a lot of weight and reputation.

Most corporations are still focused on just moving over to IaaS with compliance and security first and Google has done a great job building a solid foundation for this which should pay dividends in the future.

Yes but my point is AWS has more mindshare and MS has more leverageable pre-existing business inroads with a huge number of these corporations.

> and Google has done a great job building a solid foundation for this which should pay dividends in the future

That seems rational, but the countless examples of "worse is better" in life indicate that that outcome is far from guaranteed.

Never liked the downvoting idea, but if it must be, then it would be nice if people were at least required to comment while downvoting and open themselves to downvotes for their whacked, baseless downvotes.

I see this being thrown around here a lot. Buying into Google's PR is what this is. If you've valid points apart from BigQuery vs RedShift, I'd request you to enumerate them for me.

I have personally interacted with Googlers who lament the fact that 'no one internally bothers using most of GCP' and hence not being able to 'iterate/innovate as fast as AWS' is a key disadvantage despite their 'superior offerings', whatever that means.

Really? Have you actually used it or done any research?

1. Container Engine = built on kubernetes, faster and easier than the others

2. Compute Engine = VMs start faster, customizable rather than set sizes, live migration when the host has maintenance or starts to fail, NVME SSDs available with < 1ms latency

3. Networking = faster and more consistent performance, all the regions are connected which makes cross-regional/global deployments easier and more secure

4. Load balancing = actually routes the traffic automatically to the closest region and spills over based on capacity, not just DNS junk like the rest, no warmup or latency issues

5. CDN interconnects = cheaper bandwidth and lower latency using their partner CDN networks

6. Pub/Sub = great message system that doesnt need shards or anything to deal with for scaling, supports multiple subscribers and acks

7. gcloud = best shell access available to interact with pretty much everything, no keys or passwords to worry about

8. grpc APIs, fast storage/nearline, bigtable/datastore/cloud sql, Vision API, etc

Yes it's still new and there are a few frustrating issues, and AWS and Azure do have lots of products and their own special offerings, but the core Google platform is the amazing at running a bunch of servers/containers for a globally distributed app with high performance. We've tried them all and GCP has been the best so far.

They all have their own proprietary services which are valuable but it's completely your choice to use them.

It's not exactly the same thing but it achieves the same goal and is opensource.

API services are generated from RAML files (yaml) No code required for simple crud, biz logic can be hooked using http event handlers. Uses Elasticsearch for reads and Mongodb or Postgres for writes. Other DB can be hooked by writing the proper Db engines, it's all documented.

Docs & specifications at http://docs.telepat.io/. Hope this helps you.

Horizon.io ticks both boxes by offering a cloud SaaS :) one could say that is the ideal product!

Couchbase Mobile is open-sourced under Apache 2 and has all of the database and sync functionality of Firebase. From a database perspective it is more complete than Firebase. It also has enterprise level security, REST/Stream/Batch APIs, etc. Take a look and see if it meets your needs.

http://www.couchbase.com/mobile

Realtime, Peer-to-Peer, Offline-First, Graph.

A podcast on its performance (25+M ops/sec) just happened on http://readthesource.io/ an hour or so ago, hangouts link: http://youtu.be/70dn1oZQFCk?a .

MIT / ZLIB / Apache 2 license - do whatever you want with it.

You can architect your app sequester these 3rd party services on the edge, making any rewrite much easier.

It's better to stick with open source stack. I like what Amazon is doing with AWS with services like RDS and ElastiCache. If one carefully selects the services on AWS, there is almost zero vendor lock in.

Google also had hiked the AppEngine price in Sept. 2011 which caused a lot of problems to early adopters.

This is a hard lesson each person learns on their own.

That's why I hate the whole SaaS idea - it turns products into services; something that should be permanent (as long as you can maintain the hardware it runs) into something that is ephemeral and ever changing. It's great for the service provider, but it totally sucks for the customers. SaaS drives entropy in the computing universe.

I'm not making a value judgement; I'm pointing out that SaaS is often picked for only its short-term benefits.

Link: https://events.google.com/io2016/schedule?sid=b4641ff7-0bef-...

https://www.firebase.com/terms/service-level-agreement.html

Though I think what you are looking for is Firebase being covered by a Deprecation Policy.

Which means you presumably saved months initially by using Azure, and got your product to market sooner. Everyone should be aware of the dangers of lock-in, and should carefully consider the value of it vs. the liability they're taking on. But I wouldn't say never use products like this. The value-add can be significant, even taking into account the fact that you may have to migrate off of it someday.

As a user of the Firebase iOS SDK, I was wondering why the SDK was getting so stale. The Quickstart guide used deprecated Swift, didn't offer Carthage support, etc.

I looked at the new docs, and I guess they ditched the old Quickstart format in favor of a bunch of examples. At least the code seems to be up to date, which is somewhat encouraging. I still wish for Carthage support, though.

I see a lot of people worrying about reliance on proprietary BaaS. I had services running on Parse when it announced the shutdown, and it really wasn't that hard to migrate. Firebase should be even easier to leave if necessary, since it's basically just a NoSQL data model. If you abstract your queries and avoid some bells and whistles, you can keep everything in one place for a relatively painless move that hopefully will never become necessary.

First off, I'm glad you like the new feature additions. We'd love to hear your feedback on Storage and FCM :)

Secondly, I'd love Carthage support as well, but there are a few things (built into Carthage) that prevent us from adding this: 1. Carthage requires iOS 8+ (dynamic frameworks only). Firebase supports 7+, and we build static "frameworks", so we'd lose that (which is still relevant in a lot of our developers). 2. Carthage is designed for open source (git based origins only), and while we'd love to get there, we currently ship everything as a pre-built framework.

Anyway, I continue to use (and enjoy using) Firebase for iOS and web.

The one big request I've always had was to be able to grab the client's IP address on request. Is that possible with this new Firebase and GCE integration?

I have many Firebase apps. Most of them have an intermediate server solely for this one reason.

I also use an intermediate server (ipify.org) to get the IP address. The only reason I need the IP address is to throttle users. If adjustable throttling was baked into the platform and not require me to write logic to handle it, that would be sweet too.

Looks like https://console.firebase.google.com is getting slammed. All of my attempted imports are failing.

Thanks, and congrats.

They're just not listed under "Projects using Firebase".

Short answer is no (well.. not without an intermediate proxy of some sort), but we're in the process of providing direct integration with Cloud Functions across many of the services that fall under the Firebase umbrella. So stay tuned!

Any news on deeper/more complex queries (chaining, or something like joins without rewriting our data in multiple places)

Or faster queries (server side I've seen some very slow .once calls taking hundreds of ms)?

Also I'd love some tips on how to better scale listener/trigger functions. I have many listeners (server side) and am migrating them to explicit client endpoint point functions to handle it horizontally (more api workers).

Google already offered a lot more more than other platforms (ios) in terms of analytics and this just makes that gap even bigger.

I'm wondering if you might be able to speak candidly about this whole acquire => shutdown pattern? Why will Google choose to keep running Firebase, instead of shuttering it and getting you guys to work on something else? And do you have any thoughts on why Facebook might have wanted to shut down Parse?

Firebase has been a popular choice for backend, but now there's no clear way (at least as reflected in the current docs) to take advantage of all the offer (FCM, testing, etc).