Kinto – open-source alternative to Firebase and Parse(kinto.readthedocs.org) |
Kinto – open-source alternative to Firebase and Parse(kinto.readthedocs.org) |
http://gun.js.org/ / https://github.com/amark/gun / https://gitter.im/amark/gun
But do I have to pay for it?
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.
I asked him if he meant "flying Nimbus?" Apparently, something was lost in translation (I'm in the US, he's in France).
http://developer.couchbase.com/documentation/mobile/1.1.0/de...
I've never made the jump to use Parse or Firebase in production though because inevitably I have to write some custom server code to do some integration. For example - payments with Stripe. Charges should only occur on your server (not on the client) but I've yet to see anyone allow you to configure a payment trigger in one of these services.
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)
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.
EDIT: 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
Do you have a gitter channel or something?
Would love to talk shop about the design decisions! Email me at chris at ramses dot tech.
(I'm one of the devs of http://ramses.tech)
Why does the repo readme says this? What does it mean? I mean, why Parse kinda service is related and attached to Firefox account?
Kinto - Mozilla, CloudKit - Apple, Parse - Facebook, Firebase - Google, Azure Mobile Services - Microsoft, Mobile Hub - Amazon, Usergrid - Apache Foundation
... and many, many startups.
I would also question the decision to use HTTP for this purpose instead of WebSockets.
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.
Otherwise, HTTP works best. It has better tooling and will soon be even faster due to HTTP/2.
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.)
In my extremely biased position (as the maintainer of PouchDB) I would really have liked to still see this based on the CouchDB protocol / PouchDB codebase, it is true that neither Couch or PouchDB have particularly expressive and powerful permission systems (which is what the main downside looks to be) however I have been very aware of that building PouchDB and have made a lot of effort to ensure a powerful and flexible permissions system can be built on top of it (for example https://github.com/thaliproject/node_acl_pouchdb)
I do think that when you are tasked with providing cloud services for existing Mozilla products that there is a lot more risk involved in leveraging an existing established ecosystem like Couch / PouchDB however so its fairly likely that for Mozilla services this was the best choice (the same in reverse is true however also when looking at this as a generic library).
As for a disclaimer, I am a maintainer of PouchDB and a Mozilla developer. I have worked / talked to this team about Kinto, work on some features that use it and they are doing awesome stuff, some of which Pouch may possibly look to do as well.
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 Couch/Pouch - e.g. any messaging app or a Twitter clone. How would you select which data goes to which user? Or do you just want to put all tweets, globally, on everybody's phone?
All of this is absolutely peanuts on Firebase.
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.
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
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.
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
[1] https://www.firebase.com/blog/2015-05-29-announcing-mobile-o...
If anyone has tips, I'm all ears.
- 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 unfashionable, presumably because it's hard to shard. 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. Aren't access controls part of the core competency of a multi-user database?
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/...
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.
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.
Access control is managed via channels, and you configure the gateway with a JS function that determines which channels a document belongs to, so you don't ACL annotations, the ACL is determined dynamically by your code at write time.
There's a tiny bit of write amplification as we persist channel membership in an index, but that's to avoid massive read amplification of irrelevant records when clients sync their subset of channels.
When you store everything in a big centralized system, the risk of that data being compromised increases greatly. Right now, the reason why no one is hacking Firebase is because the data which is being stored in there is low-value.
If banks and hospitals started storing data in Firebase, you can be sure that it would attract the attention of hackers and you can be sure that they would find an exploit eventually.
You can't possibly place all of the world's high-value data inside one or two systems. Every single change made to the codebase is a potential security vulnerability.
Also, I imagine that employees of Firebase have access to all your data - What if one of them decided to share your data with a competitor. Humans are corruptable - This is too much power to put in the hands of so few people.
Is health data actually worth that much to hackers? Genuine question.
Data related to a person's education/intelligence is valuable too.
If you could get a list of all emails of people in the world with IQ < 70, you could easily take advantage of those people by sending them scam emails (for example).
Also, someone's preference for particular adult content is highly valuable (for blackmail).
A person's location data might also be quite valuable (especially if that person is a politician/celebrity).
Scammers could use the info to find targets (Fake hospital bills, "new medications", ... are easier to sell with correct information. Financial scams might work better on families that are desperate to pay expensive bills)
Publicly shaming or attacking people with "bad" or "disgraceful" health issues. (HIV, gender operations, mental issues...)
...and even if they did, the technical requirements of HIPAA compliance go much further than what Parse has to offer. You'd be much better suited building an application and hosting it on Catalyze[1], which covers every aspect of HIPAA compliance and has a HITRUST certification.