Best practices for developing complex Wolfram Cloud apps?

Question

It seems like the Wolfram Cloud now provides all the functionality needed to implement complex server-side web applications. It can handle HTTP requests (via APIFunction) and function calls directly from, say, a Mathematica notebook on a client computer; it can use a network of Wolfram Language functions to implement server-side logic and decision-making; and it can store persistent data natively (via, e.g., CloudObject and CloudExpression), or interface with a RDBMS. So, the Wolfram Cloud can, in principle, do anything that Apache plus PHP plus MySQL (or any other server app stack) can do.

BUT: Very few people code nontrivial web apps by cobbling together HTML files, PHP scripts, and hand-crafted SQL queries. Instead, we use carefully architected frameworks to manage all the complexity: Django, or Ruby on Rails, or WordPress, or Zope, or etc. (Does anyone remember UserLand Frontier?)

I haven't been able to find any advice about or support for developing complex web apps with the Wolfram Cloud. So, my question: What relevant "best practices" or other advice can this community recommend for developing a web app back-end entirely in Wolfram Cloud? (I'm imagining using a Mathematica notebook for the front end, but could also see using a web browser.) How should one organize and keep track of the pieces, and avoid losing or confusing those ugly UUIDs? Store persistent data efficiently without concurrency problems? Authenticate users and avoid security holes? Prototype and test locally, and then deploy? Etc…

And a subsidiary question: How might one organize a WC-based "web application framework"?

Answer 1

• I have little experience with any web application framework, but my past year or so of experimentation with the Wolfram Development Platform suggests that it may to possible to modify your favorite web application framework to work with an all Wolfram Language server stack. Typically I deploy an API or FormFunction from a desktop notebook and then send it a test post with URLFetch again from my desktop. (Post multipart/form-data to an API that needs a filename with the Zach Bjornson hack.) This suggests that it's in principle possible to have an EmbedCode like function that would take web application framework client side code and convert it into the necessary Wolfram Language code to paste into a client notebook. Yes, I admit that this is starting with a pretty slim thread because there's still the probably larger problem of converting the framework's server side code into Wolfram Language code.

• At Joel Klein's Wolfram Technology Conference 2015 Cloud Programming talk, he mentioned Wolfram Tweet a Program as an example of a web application that must handle concurrent computation.

• The FileNameJoin[{$CloudRootDirectory, "sensible-cloud-object-file-path", "sensible-cloud-object-name"}] construct should reduce the need to keep track of cloud object UUIDs.