3 ms·
> The trick here is designing an API that is simple and easy to use that still works for a large set of use cases, and this is a very difficult task. Security i
by Animus7 15y ago
> The trick here is designing an API that is simple and easy to use that still works for a large set of use cases, and this is a very difficult task. Security is complicated, so making a generic, simple API tends to lead to APIs that apply to a reduced set of problems.
I completely agree, and I think you understand the issue.
I'm just not convinced that any meaningful definition of app-specific "security" can be achieved concurrently with the kind of simplicity that underpins your value prop.
If I have to go and cook up logic validation, ACLs, and who knows what just to make sure my app isn't trivially broken by anyone with a JS console, aren't I basically doing the server-side programming that your pitch says you're trying to eliminate? Except in a less familiar fashion?
I'm not saying this is unfixable; I hope you have novel insights, and I want to be wrong. But I've always been sceptical of the free lunch.
- mayop100 15y agoWe're working hard to make this possible! Hopefully you'll be impressed with what we're cooking up when it's ready.
- buu700 15y agoOut of curiosity, how complete is your security system right now? As in, if the code were frozen and documented as-is, would it be generally acceptable to use in production as far as you've tested (ignoring the occasional non-critical hiccup here and there)? I noticed that your FAQ offers beta testers the option of trying out what you have. Does this mean that it's at least functional for simple/common use cases?