Hacker News new | comments | show | ask | jobs | submit login
Kinto by Mozilla – An open-source Parse alternative (github.com)
537 points by yarapavan 418 days ago | hide | past | web | 73 comments | favorite



CouchDB is so underrated in this space.

I get it: CouchDB was a very early (the first real?) document-based database, and it got some things wrong, or at least weird early on (e.g. map/reduce queries, a reduce step to the map/reduce query that is actually one-to-many (on purpose! there are concrete reasons in real life you want this!), etc.).

But they also got so much right:

   - The database is all HTTP, all the time. Connecting up your
     choice language takes about an hour.
   - Offline replication and database streaming, standardized at the
     protocol level, which allows you to use various combinations of
     CouchDB, Couchbase, Coucbase Lite, and PouchDB without interop
     problems. Plus, it means in the early part of an app (like the 0.X
     bit), I can trivially replicate the prod DB down when I'm trying
     to repro something.
   - You can store your HTTP assets right alongside the DB for 
     Firebase-like asset hosting. Throw it behind a caching service
     for prod if you want.
   - You can store full-blown files, which is great for lots of practical
     app these days.
   - Trivial replication. The scaling of CouchDB itself is honestly a
     bit crappy, but Couchbase has great scaling, and since they speak
     the same protocol, you can easily scale from CouchDB to Couchbase
     without missing a beat.
CouchDB is actually my favorite "I just wanna hack something" database for the above reasons. No, I have not and do not know if I'd seriously recommend using CouchDB 1.6 in prod for something you expected to grow huge, but it's a great "get it done" platform like Parse or Firebase, and you can really trivially move to Couchbase as you scale up if you need to.


PouchDB and CouchDB are great for prototyping of apps, but access restriction in CouchDB is broken by design: it is hard to make it correct, CouchDB is open by default, user can store anything in DB it has access to, including pr0n.

If CouchDB will close DB by default AND it will be easy to specify politics by REST path AND it will be easy to restrict document schema by REST path, then I will use it in production.


Lots of databases are open by default, especially in this space (Mongo, RethinkDB, Redis, Riak, and I believe Cassandra), and Fauxton has huge warnings that you've got access turned on globally if you haven't adjusted the setting, so I'm not sure I agree with you that that's an instant fail, but I get your point.

That said, in CouchDB 2, it'll be easy to programmatically restrict document information in a similar method to Firebase. I can't find the CouchDB 2 documentation itself, but https://github.com/rcouch/rcouch/wiki/Validate-documents-on-... , from rcouch, is the current plan. Do note that CouchDB doesn't do Firebase-like OAuth workflows, so you'd still need a thin shim in prod to handle that if you don't want to have all bespoke user accounts, all the time. (There's probably a clever way to make this work using client-side OAuth workflows, but I've never actually thought about it much.)


> Major security alert as 40,000 MongoDB databases left unsecured on the internet http://www.information-age.com/technology/security/123459001...

Yes, it is great for prototyping, but it is bad for production.


The access control limitations in Apache CouchDB are a big part of what we addressed in Couchbase Sync Gateway. Info about our Sync Function API http://developer.couchbase.com/documentation/mobile/1.1.0/ge...


Are there any whitepapers or case studies of large-scale production applications using and maintaining a sync function? After using sync gateway with access control for a while, it became more clear to me that writing my own access control API (via node.js or something like that) on top of MongoDB would give better readability and maintainability over a sync function.

(edit) specify mongodb


[Architect from Couchbase]

The formatting and modularization of your sync function code will strongly influence both it's readability and maintainability.

I've published and example of one that is well formatted and modularized. The example includes Navigation Flow, Wireframes, Data Modeling, and a Sync Function (which is the security layer).

https://github.com/waynecarter/couchbase-mobile-examples/wik...

Let me know if you have any other questions around this and I will add it to the example.


Oh, that's awesome! I'd never actually looked carefully at the sync layer, but that seems like a really direct equivalent.


I couldn't agree more here and it is sharing the same protocol with Couchbase Mobile. For me, mobile apps and offline storage with Sync is the value add. I know with Parse, push notification was the big thing for them but also it was expensive overall. This is something where you can do with Couchbase and it is all free too.


Yap.

No other database I found has build-in master-to-master replications that works as well.

Another strong aspect is crash-only data storage model. Because it uses append-only file writes, I trust it to handle power loss (VM hard stops), crashes etc.

There is 2.0 coming out which will have a clustered option, so it can allow scaling a db easier (vs say making your own replicated topology + load balancer).


What about Riak?


Here is a comparison table with Parse, Firebase, CouchDB and others for easy reference: http://kinto.readthedocs.org/en/latest/overview.html#compari...


That's not a very fair comparison. The table is missing almost all of the features that make parse so great. Parse is easy to use on any platform. There is a parse SDK for android, iOS, JavaScript, C... The focus of parse as a product is usability for devs.

Kinto may have parity with parse features in terms of technical details, but the usability is not even close.


It seems like you should update self-hostable for Parse. They did such a good job that one of our guys in Developer Relations put up https://cloud.google.com/nodejs/resources/frameworks/parse-s... with instructions in just a few hours (mostly writing it up).


PouchDB is missing. It is implementation of CouchDB but in javascript, for both client side (as in-browser database) and server side (as replacement for CouchDB). PouchDB + CouchDB are great, especially with Mongo-like queries.


They list "Fine-grained permissions", but AFAICT, they don't support custom (programmable) permission rules. Is that correct?


That's correct. Permissions apply on a matrix of {buckets, collections, records} x {read, write, create}.


I'd like to point out that Ramses (http://ramses.tech) has these abilities: https://nefertari-guards.readthedocs.org/en/stable/acl_filte...

Looks like we need to start marketing better :)


Great! We were thinking on moving to CouchDB. Do you know if they have any client side code, like PouchDB ¿?


If you move to the Couch ecosystem, you'll also have the option to use Couchbase Lite for iOS, Android, .NET, etc. As well as Sync Gateway which has dynamic fine grained permissions. Of course the whole ecosystem is open source under the Apache license.

Info on the mobile clients http://developer.couchbase.com/mobile


What's the Couch ecosystem look like these days?

I poked around with CouchDB over the Christmas holiday but it seemed kinda dead. Is Couchbase still going strong?


It's quite active, though most development is going into the 2.0 release (which adds things like clustering). Here's the alpha if you're interested. https://couchdb-ci.s3-eu-west-1.amazonaws.com/release-candid...


Cool, is there an ETA on 2.0?

I remember not being able to find much of a roadmap when I was doing this evaluation, but that's probably just my fault.


Don't think there's an ETA, but there's a list of issues which are blocking the release. https://issues.apache.org/jira/browse/COUCHDB-2932?jql=proje...

FWIW, it shouldn't be difficult to upgrade from 1.x to 2.0 as you'll be able to replicate from a single-node database to a clustered database.


Yes see the other comments here and the comments on the Parse announcement. Couchbase Mobile is being used by major airlines as well as General Electric. And a bunch of start ups and other brands.



> Offline-first JavaScript client

> Python client

from here : http://kinto.readthedocs.org/en/latest/overview.html


check out http://hood.ie for a client-side api backed by couch


One thing that possibly could be added to that comparison: rethinkdb.


Rethink doesn't have a native http API though (as in for frontend/clients, I know it has an admin UI over http)


Meteor Livequery / DDP should really be on that list.

https://www.meteor.com/livequery


Does it really compare to Parse tho? Like one of the amazing things about Parse was how easy it was for a nub to pick up. (I know from first hand exp)


Their website says this is a storage service. http://kinto.readthedocs.org/en/latest/

Parse is much more. https://parse.com/docs/android/guide


Exactly. This looks great, but it is only a fraction of what Parse offered. They seem to be getting there though:

Coming Soon:

  - Web Administration
  - Automatic service discovery
  - Push notifications using the Push API
https://github.com/Kinto/kinto/wiki/Roadmap


Realtime - Firebase, Meteor, GUN[0], PouchDB. People should NOT consider Kinto, RethinkDB, and Parse as realtime because you have to manually add that functionality yourself.

Permissions/Auth - Firebase, Parse. The way these two services do permissions is very different than everybody else (correct me if I am wrong). Therefore others are not comparable.

Graph - GUN. I think this is an important comparison for people to think about, all the other databases are essentially document stores. Graph data allows you to do key/value, relational, document oriented data, as well as have circular references.

[0] http://github.com/amark/gun Full disclosure: I'm the author.


At this point, Parse is open source, too. Why an open source clone if you can have the original?


An open source project needs active developers and maintainers in order to stay healthy and grow.

Parse is now open source in the sense of "here's a bunch of code we're throwing over the wall on our way out". Presumably (after the 1-year deadline) it's not going to be maintained or further developed by the original Parse team, who are now working for Facebook and will likely be reassigned to other roles.

Who is going to maintain the Parse source after that? A bunch of people that were using Parse specifically because they did not want to write their own backends to begin with?


Yes open source projects do, and Kinto is currently a well supported project at Mozilla. The folks who made Kinto are awesome, and do awesome things at Mozilla, but my personal experience from working at Mozilla is that Mozilla is an awesome steward of open source projects for users. The devtools team is doing a much better job of becoming stewards of tools for developers, but Mozilla has traditionally been less than ideal steward of projects for use by third parties.


The value of Parse is entirely in the client SDKs that would take forever to build and not in the server (which is a simple rest API over MongoDB).


It sounds like some of the more valuable aspects of the server (push notifications, dashboard, analytics) weren't open sourced. But the same caveats apply to the client side code.


This is not a feature complete replacement AFAIK. No push , no cloud code , no webhooks , no admin panel , no analytics though I'm sure people will contribute to the project and add some of these features.

EDIT: Hi folks, I was obviously talking about Parse, not Kinto. Kinto seems to have more features than Parse Server for now ! Looks like an awesome replacement.


You are correct that there is no push currently (we are exploring some ways to make it possible) and no admin panel (we are also exploring a lite admin panel), and no analytics (you should just use something like Mixpanel).

For cloud code, it's not true that parse-server doesn't support it - you can write cloud code directly in the node server.

For a full rundown on what's compatible, check out the migration guide: https://parse.com/docs/server/guide#migrating

The core functionality is there, and I highly recommend trying out the official Parse open source solution first, as it will be the easiest for most apps that want to migrate.


There is actually an admin console (http://kinto.github.io/kinto-admin/) and webhooks are currently in the pipe (https://github.com/Kinto/kinto-webpush)


There's an admin panel https://github.com/Kinto/kinto-admin Push: https://github.com/Kinto/kinto-webpush and https://github.com/leplatrem/cliquet-pusher

What do you mean by "cloud code"?

Anyway yeah, we're expecting help from the community to bring what's missing :)


I think the parent was talking about the open sourced parse code not being feature complete.


My understanding was that Parse (the company) has open-sourced an API-compatible re-implementation of their product as an act of kindness towards everyone currently using their system.

I may be way off base here, but there is no indication that this open source release from Parse is in any way a derivative of their commercial product... at this point whichever reimplementation of the Parse API gains the most developer mind share will survive as the winner. (Of course, Parse the company has a lot of inertia behind their own.)


It's API compatible, but even then not all API endpoints work. It's NOT their commercial product.


The quality of the code is a factor. Parsed wasn't originally intended to be open source.


You still have to host and manage it.


We have a one click deploy to heroku button http://kinto.readthedocs.org/en/latest/get-started.html#depl...

It's not entirely satisfying, but that just proves we could integrate with many hosting platforms.


I just created a PR to deploy Kinto on Google App Engine (Managed VMs).

https://github.com/GoogleCloudPlatform/python-docs-samples/p...

If there's interest I'll try to flesh it out more.


http://deepstream.io/ seems as a more complete alternative [disclaimer: I'm a contributer]


This looks interesting. I love firebase (never used Parse) but deepstream looks a decent replacement of Firebase.



An equivalent to Parse would be:

http://usergrid.apache.org/ or http://www.baasbox.com/

Both are open source and try to have the same functionalities like Parse.


Great! Thanks for sharing


Good day to make everyone aware of this project as parse is closing down:

http://blog.parse.com/announcements/moving-on/

:)


The benefit of services like Parse aren't that they provide a JSON API. That's easy to do.

The benefit was that they would worry about scaling and caching the api to get the best performance and not have to worry about a backend.

Releasing open source JSON APIs isn't solving the real problem in my opinion.


Also they released the ParseServer. https://github.com/ParsePlatform/parse-server this can give community a way to continue on with it.


Given Mozilla's track record on new projects, I really have to wonder how long this will last.


So my problem with kinto and couchDB/couchbase is that as a newbie indie developer I have no idea how to get started with these.

AT least with Parse they had an iOS SDK and tutorials. With kinto or couchdb/couchbase i don't even know where to begin.


[Architect from Couchbase]

We hear you and we're working on that. A good place to start is w/ our mini-hacks. Here is an iOS one that I think could help: https://github.com/couchbaselabs/mini-hacks/tree/master/kitc...


From the announcement on the Parse blog, it sounds like Parse might in fact be the open source Parse alternative:

> Second, we’re releasing the open source Parse Server, which lets you run most of the Parse API from your own Node.js server.


I've been looking at dreamfactory for a while (http://dreamfactory.com).

Would anyone here be interested in putting together a "awesome mbaas" list like awesome django [1] ?

I'm willing to setup on my github there. lmk

[1] - https://github.com/rosarior/awesome-django


Mozilla project under Apache-2.0. Nice!


Remember when they killed Mozilla Persona?

Oh, look, here they go again.


I found this guy come very close to Parse: http://www.baasbox.com/

They have Push notifications and "Cloud Code" which most other alternatives don't have


We will be offering Parse Hosting through our new service: http://parsehosting.net to support both our existing clients and other developers


oh okay!


Here is a proposal...

Some of the folks here have pointed out that Parse provides more functionality than Kinto. Why does Mozilla provide resources to keep working on Parse, if Kinto is designed to be an alternative to Parse? It is open source after all. It sounds like Parse is still relevant and needs to be continued.


Why Python rather than something like Rust instead?

The phrase "lightweight" is thrown around, but the [requirements.txt](https://github.com/Kinto/kinto/blob/master/requirements.txt) is anything but lightweight and that's before you consider carrying around python itself.

It seems like compiled version would be more efficient and much smaller.

EDIT:

Their FAQ seems to make this question even more interesting

> Why did you chose to use Python rather than X?

> We love Python because it’s a concise & expressive language with powerful data structures & easy to learn, so it was an obvious choice for the development team.

> In addition, the Operations team at Mozilla is comfortable with deploying and managing Python applications in production.

> However, Python is just an implementation detail per se. Kinto is defined by an HTTP protocol that could be implemented in any language.

If your end-user is hitting a HTTP API, then Python being "easy to learn" is a non-goal. Rust (or even JS + Node) is just as "expressive". This really makes it sound like their team is inexperienced with DB design (not very confidence inspiring). I find it equally mystifying that operations would dictate python rather than whatever language the team thought would be best.


> This really makes it sound like their team is inexperienced with DB design

Huh, can't see any obvious relation between PL and DB design. Your comment makes it really sound you're inexperienced with constructive commenting anyway.


Why not re-write EVERYTHING in Rust?

Because we all know new languages are silver bullets, right?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: