Maybe, but there are others of us who don't use firebase because we can't outsource our datastore like that. It goes both ways.

We're actually building an open-source alternative to services like Firebase and Parse. Ours is a fully peer-to-peer, real-time, graph database that doesn't require a lot of expertise or overhead, and is extensible.

http://gun.js.org/ / https://github.com/amark/gun / https://gitter.im/amark/gun

In many industries (I.e. healthcare with HIPAA) you can't save your data in Firebase/Parse.

My thoughts exactly. Kinto is a database with an API that you have to configure, deploy, manage and scale. It's not really an alternative to Parse/Firebase, as it is an alternative to Mongo.

I believe, really, its more about being indie and such. Its the same reason many people can just run gmail - or google apps for your domain - as opposed to the heavy-lifting of running your own email server, etc. Not like I'm an expert, but running one's email - and ensuring high degree of deliverability nowadays - is quite difficult. There are those who choose to run something on their own, maybe to learn, maybe for privacy's sake, etc. I'm sure those who do so, dive in with their eyes wide open. ;-)

> Isn't one of the main benefits of something like Firebase or Parse that you don't have to run it?

But do I have to pay for it?

I find it an ongoing mystery how many of these tools and services pop up that aren't based on Couch/PouchDB, don't reference Couch/PouchDB, aren't compatible with the Couch sync protocol, and don't even seem aware the Couch/PouchDB exist.

I'm 100% waiting to be sold on "here's a new tool that does what CouchDB does, but is better in these specific ways", but if your sales pitch is just "we're working on writing an exact clone of CouchDB because we didn't realise CouchDB existed" it doesn't really sell me.

(Nothing wrong with a dose of Not Invented Here Syndrome; a lot of progress comes from reinventing the wheel. What gets me is the No Idea What's Been Invented Syndrome.)

You might be interested in https://github.com/couchbase/sync_gateway which is the Couchbase Mobile access control and sync layer (compatible with PouchDB etc). It has fine grained access control based on a channel metaphor. And it's also written in Go, so you might be interested in using parts of it.

Specifically if you wrap your storage layer in a facade that looks like https://github.com/couchbaselabs/walrus you'll be able to use our suite of storage layers, and we'll be able to use yours. That means it'd be trivial to swap out your storage for something scalable like Couchbase Server, or something tiny and embedded like ForestDB or RocksDB.

Or Couchbase + Sync_Gateway + PouchDB / CouchbaseLite?

This is a very full featured combination, basically a PaaS/BaaS with sync, and user accounts, out of the box.

http://www.couchbase.com/nosql-databases/couchbase-mobile

Note, while that website is very corporate, the software is open source and the company is very supportive of developers.

Speaking of finer-grained permissions in CouchDB/PouchDB. I'm working on implementing that now in my application. Can filtered replication (server-side) solve this problem?

For an application targeting small-businesses, I'm considering the following setup on the server. Has anyone done this or something similar?

One DB per user and a Company DB. Filtered replication from Company DB to User DBs. Full replication from User DBs to Company DB. All reads/writes/deletes from client (or PouchDB sync) to User DB only

Well, "kinto" is the name for the cloud in Japanese (see: http://dragonball.wikia.com/wiki/Flying_Nimbus).

Yeah the full name is "Kinto-un" :)

From the Overview page: At Mozilla, Kinto is used in Firefox and Firefox OS for global synchronization of settings and assets, as well as a first-class solution for personal data in browser extensions and Web apps.

That's what it looks like [1]. Every operation is done locally via IndexedDB, and then you manually perform syncs.

[1] https://kintojs.readthedocs.org/en/latest/

There's https://github.com/nolanlawson/socket-pouch. It's Node + LevelDB and optionally offline-first.

GUN defaults to WebSockets - http://gun.js.org/ / https://github.com/amark/gun / https://gitter.im/amark/gun

RethingDB[0] talks WebSockets.

[0]http://rethinkdb.com/

Hi, at zetapush (http://zetapush.com), we provide a realtime BaaS with database, file storage, search engine, ... everything with a websocket connection. You can use our javascript SDK to connect to our clusters.

Firebase's JavaScript SDK uses WebSockets when available and falls back to HTTPS when unavailable.

Basically, you need a service running on a separate server to implement these sorts of integrations. If Firebase is a long-term part of your stack, I agree that sounds unappealing, b/c the reason you're paying Firebase is so you don't need to wrangle a server.

You may think differently if you're using Firebase as the fastest way to get an MVP up and running (that happens to be my use case)

We use parse with stripe. The client drives the transaction and then stripe hits your parse cloud function via webhook with the confirmation.

Of course you can use firebase also in combination with server side code. It is no reason not to use firebase because you use server side code. I use firebase and SQL at the same time. It works quite good if you know what you do.

I've done exactly that - integrated Stripe with our Firebase-backed app (https://play.google.com/store/apps/details?id=com.twansoftwa...). My method was to use App Engine as the callback component to handle Stripe webhooks.

I also do have custom server code, which was a little bit tough to get going, but it's great having a dedicated Linux box as well.

> this seems to be lacking a graphical administration panel as well

we are working on one, that's almost ready. Should be released sometimes during Q1

I agree with you, but I think SDKs for at least Android and iOS will be available very soon.

Agree.They should at least have Android and ios SDK.

There is an irc channel, join #storage on Mozilla IRC

https://search.mibbit.com/networks/Mozilla/%23storage

It was our first use case at Mozilla when we started the tool. This sentence is now a bit misleading. Thanks for pointing this out.

IndexedDB is not limited to 5MB, its essentially unlimited in Chrome and Firefox. It can be tricky with mobile browsers but they often also have the option of using an unlimited web app wrapper (http://www.html5rocks.com/en/tutorials/offline/quota-researc...)

And as for WebSockets, HTTP is easier to debug and experiment with, in my experience the performance difference for the typical use cases is negligible and when needed it is trivial to wrap the communication in a socket.

WebSockets are for fast, low-overhead connections. If you end up making a new HTTP connection for every update, and there are a lot of updates happening, you should be using WebSockets instead.

Otherwise, HTTP works best. It has better tooling and will soon be even faster due to HTTP/2.

It really is a challenge. I don't think it'll be realistic to build mid-size, fully offline web apps (excluding tools like electron) until indexedDB has wider support. One solution is to garbage collect the oldest data from localStorage and sync with a server when you've got connection, but once you're offline you're kinda stuck with 5mb. However, caniuse.com/#feat=indexeddb is optimistic about the future. The company I work for is trying to make offline/decentralized apps more realistic (gundb.io, github.com/amark/gun) and storage limitations can be aggravating at times.