Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kinto by Mozilla – An open-source Parse alternative

github.com

Post reply on HN
Print view View original

71–77 of 77 posts

Re: Kinto by Mozilla – An open-source Parse alternative

#71

Post by nodamage »

tbrock wrote: post #69
nodamage wrote: post #46

Earlier quoted context omitted.

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…

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.

Re: Kinto by Mozilla – An open-source Parse alternative

#72

Post by 0k1n »

hajile wrote: post #63

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…

> 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.

Re: Kinto by Mozilla – An open-source Parse alternative

#73

Post by wayneacarter »

enos_feedler wrote: post #67
jchrisa wrote: post #53

Earlier quoted context omitted.

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.

Re: Kinto by Mozilla – An open-source Parse alternative

#75

Post by OOPMan »

hajile wrote: post #63

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…

Why not re-write EVERYTHING in Rust?

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

Re: Kinto by Mozilla – An open-source Parse alternative

#77

Post by OvermindDL1 »

rdtsc wrote: post #59
gecko wrote: post #40

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.…

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?
Post reply on HN