11 comments

[ 3.4 ms ] story [ 48.5 ms ] thread
I originally planned it as a commercial project, but then decided to open source it. Let's see if that was a good idea and people actually need it.
I'm not totally thrilled about having a 'secret' key embedded in the app that's distributed publicly.

I had a brief skim over the code and I can't see any access control stuff so I'm guessing this key has full access.

If that's the case, I can't see how this could ever be suitable for use in any real app.

What's the difference to the "clientKey" of Parse's SDK? The requests should be served over SSL anyway, so if your point is you don't want to distribute a key you got the same problem with Parse. You can obfuscate the key though.
It doesn't matter whether you use SSL or not. If it's in your app, it can be found quite easily.

Parse provides you with a few different keys and also offers ACL functionality. I'm still not too crash hot on expecting the client to setup an ACL on their own objects though...

can you propose how an client can authenticate with this type of service without a key?
I am interested with all the tools running above Node.js, but what is exactly the purpose of this web app backend? Using a database? Some explanations would be welcomed. I found only a list of classes.
You don't need to implement APIs anymore. You can use the DataKit classes to interact with the web/db backend.
I too find that a rationale and list of problems it solves is needed. Sell me on the added value of your creation.
(comment deleted)
Maybe I'm missing something obvious, but I can't find this in the docs: Does this handle users and permissions, as, I believe, Parse can? I can't have just any user able to change any data.