Live data from Hacker News

Kinto – open-source alternative to Firebase and Parse

kinto.readthedocs.org

81–90 of 95 posts

Re: Kinto – open-source alternative to Firebase and Parse

#81

Earlier quoted context omitted.

As a Firebase customer and former CouchDB user, I can tell you that the use cases are really not as similar as you apparently think they are. Until very recently, Couch/Pouch would only sync entire databases, and recommended a "One database per user" approach. This is improving now, but it's still very coarse-grained. Last time I checked, anything that has data that you couldn't shard easily is basically unfit for Co…

Personally, I'm looking for a database with: - strong consistency (cross-node transactions!) - strong access controls (don't want clients to see data they're not allowed to!) - the ability to seamlessly replicate a view from the server to a web client without me having to think about it (although only read-only) So far none of the web nosql databases I've looked at support these. Strong consistency seems to be unfash…

> I was really surprised to discover that CouchDB apparently doesn't support access controls, though --- if a client has access to the database endpoint, it can see everything.

Not sure what you mean; CouchDB has strong access controls, although they are at what in SQL terms we'd call the table level, rather than the row level. But it's not really any different than, eg, MySQL? Or MongoDB, if you want to compare NoSQL to NoSQL.

If you have data in a table that a client shouldn't see, don't give that client access to that table.

Re: Kinto – open-source alternative to Firebase and Parse

#82

Earlier quoted context omitted.

As a Firebase customer and former CouchDB user, I can tell you that the use cases are really not as similar as you apparently think they are. Until very recently, Couch/Pouch would only sync entire databases, and recommended a "One database per user" approach. This is improving now, but it's still very coarse-grained. Last time I checked, anything that has data that you couldn't shard easily is basically unfit for Co…

Personally, I'm looking for a database with: - strong consistency (cross-node transactions!) - strong access controls (don't want clients to see data they're not allowed to!) - the ability to seamlessly replicate a view from the server to a web client without me having to think about it (although only read-only) So far none of the web nosql databases I've looked at support these. Strong consistency seems to be unfash…

The Couchbase Mobile Sync Gateway tackles fine grained access control head on. Basically you write a function that stripes your data into channels, and manages access on a per channel basis.

There are a few things that are challenging to model this way, but for 80% of use cases it's the right simplification. Intro documentation: http://developer.couchbase.com/documentation/mobile/current/...

Re: Kinto – open-source alternative to Firebase and Parse

#84
post #34
post #32

Why not CouchDB + PouchDB? It's offline first and replicates over HTTP. For more fine-grained permissions and other features I'm also developing a small Go database compatible with PouchDB at https://github.com/fiatjaf/summadb I hope it will be able to sync through websockets soon.

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…

Thank you, jchris.

As far as I could understand, basically I must implement the Bucket interface[1]? I don't if that will work, since I'm storing things in a somewhat different manner, but it's definitely worth examining.

[1]: https://github.com/couchbase/sg-bucket/blob/master/bucket.go

Re: Kinto – open-source alternative to Firebase and Parse

#85

Earlier quoted context omitted.

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.

main feature of firebase for me are the "realtime" updates

I'm not sure why no one mentions rethinkdb. We use it and are extremely happy with both its API mindframe, realtime updates and how easy it is to scale it.

Re: Kinto – open-source alternative to Firebase and Parse

#86

I'm not a big fan of offline storage for web apps. Any serious app will quickly exceed the localStorage limit which is only 5mb. I would also question the decision to use HTTP for this purpose instead of WebSockets.

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.

I'm surprised no one mentions xhr streaming, if your pipe is only one way i.e server notifies client, then xhr streaming is quite easy to use and as fast as websockets.

Re: Kinto – open-source alternative to Firebase and Parse

#87
post #86

Earlier quoted context omitted.

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.

I'm surprised no one mentions xhr streaming, if your pipe is only one way i.e server notifies client, then xhr streaming is quite easy to use and as fast as websockets.

I assume most people consider XHR a kind of HTTP request. It is in the name, after all.

Re: Kinto – open-source alternative to Firebase and Parse

#88

Earlier quoted context omitted.

main feature of firebase for me are the "realtime" updates

I recently tried Parse's Push Notification (which go through GCM on Android). I was shocked by how long the messages seems to take when on cellular. If anyone has tips, I'm all ears.

Full disclosure: former Parse Push tech lead, current Firebase engineer. If your slowdown is only while the device is on mobile, it's almost certainly due to something outside of the Parse stack. Push notifications have grown to be an async information pipe, but never a real-time or reliable one. The most common example of this is APNs (Apple's push network)--Apple only buffers the most recent undelivered notification for an (app, device) pair and messages without UI (aka "silent push") must be sent at a low priority which will likely incur extra delays. If your goal for silent push is to help improve cache hits by pre-populating an app with useful data, don't worry about the slowdown. If you're using push for something that must be reliable or real time, you're probably using the wrong tool. Consider something like Firebase for this instead. If you're already deeply invested in Parse, I've seen people use Parse Cloud Code to replicate writes against Firebase and use Firebase to build a client sync layer.

Re: Kinto – open-source alternative to Firebase and Parse

#89
post #33

Does anybody know about databases that talk WebSockets rather than HTTP? For frontend apps it seems more logical to use WebSockets. Dealing with AJAX and understanding how to manage all of that on the client is still a huge dilemma in the React/Flux/Angular community.

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

Re: Kinto – open-source alternative to Firebase and Parse

#90
post #82

Earlier quoted context omitted.

Personally, I'm looking for a database with: - strong consistency (cross-node transactions!) - strong access controls (don't want clients to see data they're not allowed to!) - the ability to seamlessly replicate a view from the server to a web client without me having to think about it (although only read-only) So far none of the web nosql databases I've looked at support these. Strong consistency seems to be unfash…

The Couchbase Mobile Sync Gateway tackles fine grained access control head on. Basically you write a function that stripes your data into channels, and manages access on a per channel basis. There are a few things that are challenging to model this way, but for 80% of use cases it's the right simplification. Intro documentation: http://developer.couchbase.com/documentation/mobile/current/...

Sync Gateway looks very plausible... but having to run an extra server just as access control to the main database? That's so ugh.

It also looks like this requires me to annotate each document with ACLs. I was rather hoping to be able to just sync a view, so that changing the database would cause players with changed views to automatically resync. I'm not terribly happy with having to recalculate the views of all players and then update the ACLs of all documents manually on every database mutation; that's a lot of writes.

Post reply on HN