This might be premature, but I think what you're doing here is brilliant. I know so many designers-come-web-developers who struggle with the back-end portion of web development. Many use cases simply don't need the full flexibility of a web app framework, but do need more than what you can cobble together with outside tools like the various embeddable form tools and widgets.

IMO, the authentication & authorization portion of your app is going to make or break the result. I'd like to make a suggestion. There is an authorization library for Rails named CanCan. It uses a declarative definition for authorization that is similar (loosely) to what you've got going right now. There is also an extension for CanCan called Cantango, which builds out the concept of roles as packages of permissions.

Again, I'm speaking really loosely here, but it looks like you're still working on this portion of the product, and these libraries work in a way that I think makes sense to your target market. The declarative style is a good fit for font end developers. You simply describe how you'd like users to interact with the API, and you're done. If you incorporated some of the ideas from these two libraries, I'd be really thrilled :)

Can't wait to recommend this.

https://github.com/ryanb/cancan

https://github.com/kristianmandrup/cantango

Thanks a ton for the kind words!

I'm not familiar with CanCan-- it looks very expressive. A role based system is a pretty significant departure from our current ACL per model approach. I think I need some more input, in the form of practical use cases where ACLs can't do the trick. I'm sure they exist, but we'd need to consider the added complexity of role based access and weigh that against the kinds of apps it would unlock.

Regardless I'll spend some more time looking into these libraries.

Awesome! Took about 60 seconds to get an app running with live updating.

The dropbox deployment is fantastically easy and I can see myself using this for quick front-end mockups. As for the backend portion of your service, it'd be nice to see an example or a link to an example on the front page. It wasn't immediately clear to me that you were a backend-as-a-service and I thought this was just a Dropbox deploy service, even after looking at the homepage. Good luck!

Small typo on the "What's next?" page after you create a new app:

``They will be in your Dropbox folder under the followng path:``

Should be "following", not "followng".

How is this done atomically? e.g. a scattering of html/js/css coming down in random order is going to cause issues, for sure.

With Backlift, you explicitly set the order that the files should be linked or concatenated in the config.yml file.

When assets are sent over via dropbox, backlift compiles each source file into a separate js or css product. Then all files are concatenated and minified using the order from config.yml.

Does that answer the question, or am I missing something?

I think newobj is referring to the non-atomic nature of dropbox sync: there is no "commit" or singular upload, but rather a continuous sequence of changes. The question then is: how does this affect deployment? For example you might see markup changes deployed without the corresponding css changes.

I would guess the answer is that the "deployment" is so lightweight and fast (minify a few text files and copy them somewhere) that it's ok to re-run the deployment step at every single new file change.

I'm a big fan of this workflow. Good job Cole!

Yes. The worst you might see is a few seconds of mismatched styling, or an occasional error that would resolve when the next dropbox cycle pushes a refresh. The only deployment operations that involve inter-file dependencies at this time are the minification and concatenation that occur during optimization. And we don't recommend turning on optimization during development-- it does slow things down, and we haven't implemented source mapping yet so you'd have to debug obfuscated code.

Man the live updating is pretty sweet.