6 ms·

After all the noise about Firebase at the last Google I/O, it's odd that the article doesn't mention it at all. I guess its proprietary API and undocumented wi

After all the noise about Firebase at the last Google I/O, it's odd that the article doesn't mention it at all. I guess its proprietary API and undocumented wire protocol with no open source alternatives would be off message...

zwily 10y ago
There are few things in life that would excite me more than Firebase going open source. Sad, I know. :/
jephir 10y ago
http://horizon.io/ http://horizon.io/ While Firebase is proprietary, you can export your database as JSON and import into RethinkDB.
- piotrkaminski 10y ago
  And then rewrite your entire app against a new API. No thanks.
- piotrkaminski 10y ago
  To be fair, I think Horizon is one of the more promising Firebase alternatives. However, it has completely different semantics, and is quite immature at this point (look at the limitations: http://horizon.io/docs/limitations/ http://horizon.io/docs/limitations/). But if Firebase remains proprietary and Horizon continues to improve I could certainly imagine that rewriting my app will eventually start to look attractive.
- asadlionpk 10y ago
  I wish this was true. I am locked-in with Firebase and would love to self-host now that I have resources. Sadly I will have to rewrite the API. It's not that Firebase is not great, I just want to take control back.
colemickens 10y ago
Given that this blog post is about having portable workloads and Firebase is specifically not portable, isn't it obvious that talking about Firebase would be "off message"?
- piotrkaminski 10y ago
  Actually, the article specifically talked about some non-portable services and explained why this wasn't a big deal, so to me leaving out Firebase implies that 1) it is a big deal and 2) they're not interested in making Firebase apps portable. My conclusion is that they're only opening up the services where they're not in the lead and getting people locked into the ones that are. Which is fine and a great business strategy but rather detracts from the "we're all about openness and choice" image they're trying to project.
  - colemickens 10y ago
    I personally perceive Google as ahead in the container space and quickly the machine learning space. I don't see how one product being closed has any impact on the openness or portability of the products mentioned in this article. It seems unreasonable, to me, to criticize them for omitting an exhaustive list of closed products in a blog post about portable platforms.
stemuk 10y ago
I know everybody would love to see this, but for me it's a bit much to ask from Google to open-source Firebase since they invested quite a lot of time and money into it to get to the current version. Apart from that, I can definetly recommend http://deepstream.io http://deepstream.io as a Firebase alternive, although it currently lacks an Android/iOS client (Java client is in the works).
- themihai 10y ago
  Sure! We should be tankfull they throw us a bone here and there(i.e. a whitepaper)...until then let's invest more in their cloud services so they can show us how small we are without them. I remember people asking why they don't open source datastore and appengine. Their response was that we are too dumb to manage it so it won't help us anyway.
  - stemuk 10y ago
    If you ate not willing/able to pay for managed cloud services like Firebase, there are some really cool self-hosted alternatives out there (like deepstream.io and horizon.io). Open-sourcing software should always be a can, not a must. We could as well expect Amazon to open source DynamoDB, which is proprietary as well and still has quite a lot of users.
- piotrkaminski 10y ago
  Yeah, I agree that open sourcing Firebase is too much to ask. But there's other things they could be doing: a) document the wire protocol and license the clients for free use with any server, b) make the API definitions public domain and provide a compatibility test suite for alternative implementations, c) lead a standardization effort on real-time JSON databases, etc...
  - stemuk 10y ago
    True, maybe https://github.com/firebase https://github.com/firebase could help with some reverse engineering. However, I discovered the Firebase document and the deepstream.io record structure to be fairly similar, so with the help of https://github.com/firebase/firebase-queue https://github.com/firebase/firebase-queue the migration from Firebase to deepstream.io + RethinkDB might be possible. As a more general note, I would expect some of the stuff you mentioned to happen in the upcoming months/years, since Firebase is right now set to become the universal plattform for app devs (analytics, dynamic links etc.) rather than a standalone database offering.
010a 10y ago
Cloud PubSub is also missing, which I've always heard is one of the better parts of Google's cloud offerings.
novaleaf 10y ago
i use and love Google Cloud Datastore, but it also falls into this proprietary umbrella. Though honestly you should never write your app directly against a database schema. ORM or FRM (functional relationship mapping) is how it should be done.

zwily 10y ago

There are few things in life that would excite me more than Firebase going open source. Sad, I know. :/

jephir 10y ago

http://horizon.io/ http://horizon.io/ While Firebase is proprietary, you can export your database as JSON and import into RethinkDB.

piotrkaminski 10y ago
And then rewrite your entire app against a new API. No thanks.
piotrkaminski 10y ago
To be fair, I think Horizon is one of the more promising Firebase alternatives. However, it has completely different semantics, and is quite immature at this point (look at the limitations: http://horizon.io/docs/limitations/ http://horizon.io/docs/limitations/). But if Firebase remains proprietary and Horizon continues to improve I could certainly imagine that rewriting my app will eventually start to look attractive.
asadlionpk 10y ago
I wish this was true. I am locked-in with Firebase and would love to self-host now that I have resources. Sadly I will have to rewrite the API. It's not that Firebase is not great, I just want to take control back.

colemickens 10y ago

Given that this blog post is about having portable workloads and Firebase is specifically not portable, isn't it obvious that talking about Firebase would be "off message"?

piotrkaminski 10y ago
Actually, the article specifically talked about some non-portable services and explained why this wasn't a big deal, so to me leaving out Firebase implies that 1) it is a big deal and 2) they're not interested in making Firebase apps portable. My conclusion is that they're only opening up the services where they're not in the lead and getting people locked into the ones that are. Which is fine and a great business strategy but rather detracts from the "we're all about openness and choice" image they're trying to project.
- colemickens 10y ago
  I personally perceive Google as ahead in the container space and quickly the machine learning space. I don't see how one product being closed has any impact on the openness or portability of the products mentioned in this article. It seems unreasonable, to me, to criticize them for omitting an exhaustive list of closed products in a blog post about portable platforms.

stemuk 10y ago

I know everybody would love to see this, but for me it's a bit much to ask from Google to open-source Firebase since they invested quite a lot of time and money into it to get to the current version. Apart from that, I can definetly recommend http://deepstream.io http://deepstream.io as a Firebase alternive, although it currently lacks an Android/iOS client (Java client is in the works).

themihai 10y ago
Sure! We should be tankfull they throw us a bone here and there(i.e. a whitepaper)...until then let's invest more in their cloud services so they can show us how small we are without them. I remember people asking why they don't open source datastore and appengine. Their response was that we are too dumb to manage it so it won't help us anyway.
- stemuk 10y ago
  If you ate not willing/able to pay for managed cloud services like Firebase, there are some really cool self-hosted alternatives out there (like deepstream.io and horizon.io). Open-sourcing software should always be a can, not a must. We could as well expect Amazon to open source DynamoDB, which is proprietary as well and still has quite a lot of users.
piotrkaminski 10y ago
Yeah, I agree that open sourcing Firebase is too much to ask. But there's other things they could be doing: a) document the wire protocol and license the clients for free use with any server, b) make the API definitions public domain and provide a compatibility test suite for alternative implementations, c) lead a standardization effort on real-time JSON databases, etc...
- stemuk 10y ago
  True, maybe https://github.com/firebase https://github.com/firebase could help with some reverse engineering. However, I discovered the Firebase document and the deepstream.io record structure to be fairly similar, so with the help of https://github.com/firebase/firebase-queue https://github.com/firebase/firebase-queue the migration from Firebase to deepstream.io + RethinkDB might be possible. As a more general note, I would expect some of the stuff you mentioned to happen in the upcoming months/years, since Firebase is right now set to become the universal plattform for app devs (analytics, dynamic links etc.) rather than a standalone database offering.

010a 10y ago

Cloud PubSub is also missing, which I've always heard is one of the better parts of Google's cloud offerings.

novaleaf 10y ago

i use and love Google Cloud Datastore, but it also falls into this proprietary umbrella. Though honestly you should never write your app directly against a database schema. ORM or FRM (functional relationship mapping) is how it should be done.