What's a good back-end for a stateful client/server app that uses Mathematica for a front end?

Question

I'm strategizing the design of a kind of client/server "learning management system" to support a computational physics course. I want the student side to be entirely implemented in Mathematica, through a combination of custom notebook-based interfaces and package code I write. As students complete assignments (in custom notebooks) and submit them (by having the notebooks send appropriate data to the server), the back-end will verify and track their progress and send new assignments (new notebooks) as appropriate.

I'm wondering what the best back-end system would be. It'll need some kind of persistent database to track student progress; authentication of user identity; and logic to validate student activity and make decisions about what to send next. I would absolutely love to implement all that in Mathematica, so that the entire system would be Mathematica front-to-back, and the front-end bits could just call remote Mathematica functions on the server.

I'm imagining that perhaps the front-end bits can invoke remote Mathematica functions on a server (or in the Wolfram Cloud?), and perhaps those back-end bits can talk to a database (for user state tracking) and file store (to call up new files to send to the user). In other words, Mathematica would be playing the role of a web server, just like (say) Apache-plus-PHP or Rails or etc. Is this a reasonable, wise thing to do? Is Wolfram's new cloud stuff meant to support that kind of interaction?

It seems like the Wolfram Cloud might be promising, but I haven't been able to get my head around it successfully. The examples I've seen don't really speak to my kind of use case...

Thanks for any wisdom!

Update: To be more concrete, let's consider the following situation. The user (student) has downloaded a notebook I created that contains instructions (programming challenges) and cells in which to enter his/her responses (solutions to those challenges). It also has a big red "Test it!" button, and a docked status bar at the top. An initialization cell in the notebook loads an accompanying package (via URL from my server) providing code that runs a battery of unit-test-like checks on the user's responses when he/she clicks the "Test it!" button and provides diagnostic feedback, or hearty congratulations if everything passes all tests. It also updates the status bar with the current state of the notebook (incomplete, errors, all correct), and with the student's current status in the overall course (e.g., number of assignments completed and current point total) which is obtained via some kind of query to my server.

When the student runs the tests and everything passes, I'd like the notebook (via code contained in the initialization package it's loaded) to send that fact to my server, along with the student's authenticated identity and a serialization of the entire notebook for verification purposes. My server will note that this particular student passed this particular assignment, so that future status-bar queries report accordingly. Also, it will make the next assignment notebook available to be downloaded and attempted.

In addition, I need administrative tools (ideally in my own Mathematica notebooks, or alternatively via web browser) to monitor student progress.

I've already figured out how to do the local part: How to create notebooks and accompanying packages that automatically test student-entered code and provide diagnostic feedback, and set a fail/win flag in a docked status bar. What I don't know how to do is to have the notebook reliably report student progress information to a back-end server, how to safely store that information, and how to use it to make decisions about how to respond to future queries from the same user (via the same or another notebook).

Wolfram Cloud objects and data drops seem tempting, but I don't see any tools for organizing suites of them into larger systems, and I'm afraid that trying to develop and maintain a growing system of interacting Cloud functions, data drops, static files, etc. will be a nightmare. I guess I'm hoping there's a way to do something like Ruby on Rails, but with Mathematica…

Answer 1

I'd say the architecture should depend largely on three things:

• Your available budget
• The number of students that the app would have to serve
• The degree of your proficiency / familiarity with some modern web frameworks / technologies

An immediate disclaimer is that I haven't yet used Wolfram Cloud to build anything serious, so you can take my words with a grain of salt.

---

If you don't care all that much about the money (needed to buy enough cloud credits), or if there won't be too many students (simultaneous requests), then it might be easier to base everything on Wolfram Cloud. You would have to store the student records somewhere (it could be a Databin, CloudObject / file in the cloud, or a real database - could use SQLite, for example), and implement all the server logic in Mathematica.

In case if you don't have too many simultaneous requests, and the overall number of requests (say, per month) won't be too large, this may work well. Since you basically need only the API, and the clients will be written in and used from Mathematica, and since your business logic doesn't sound too complicated, you may get away with implementing all that in Mathematica and deploying to the cloud.

Actually, I'd probably start by trying this option first. You will need to:

• Implement the actual system to generate notebooks, test results, etc, on the server (cloud). In the MVC terms, that would be a part of your model, since it will contain the business logic of your app.
• Connect that to a persistence device of your choice (could be just a file or a real db, in the cloud - for example, SQLite. But in fact, you could as well use .mx files, which are very fast to load, and reasonably fast also to save). You will probably need to care about concurrent requests which try to write to your db / file from different kernels. Whichever method you pick, I'd implement some kind of lightweight ORM, like a custom object that would have methods to read and write data - to abstract away the persistence.
• Design, implement and deploy your API that would process requests from the clients, and return responses. In MVC terms, this part will basically be the controller(s). They can return responses to the client(s) as complete Mathematica expressions (actually, this is the default for APIFunction).
• Implement the authentication system that would check that the users don't try to cheat the system.
• Perhaps, also would need some code to manage collections of files in the cloud, if you decide to store e.g. generated notebooks and reports as files.
• Implement two clients - one for your students, and another one for yourself. In MVC terms, these will be views. I'd create two different APIs, so that you could set the permissions on your private API accordingly. Your client would also need to have an admin, that would allow you to view and change the records.
• Some of the things you may need may require setting up scheduled tasks in the cloud. The current pricing options with this feature (as well as db connectivity) start with the Producer plan

None of that sounds too complicated, so I'd first try this option. Even if you later decide to switch to a separate server that would carry the main infrastructure of your app, you will already have a working prototype. It's hard for me to say what kind of problems you may face down this road, and you will be pretty much on your own since there hasn't yet been accumulated enough experience with it in the community. But it may be worth it - you can save lots of time by not having to develop and maintain a separate server infrastructure in a different language. This can be particularly important in the initial / prototyping stage.

---

But if you want to make the app both scalable (anticipate lots of students / requests), and low - cost, then I would agree with your design hunch to have a separate server to carry all the infrastructure and manage the state of students records. Here is the way I'd do that (disclaimer: I don't have any experience in building such hybrid apps, but do have web. dev. experience):

• Minimal restful backend using some of the server technologies (Rails, Django, whatever). This part would manage everything, and run continuously
• Wolfram Cloud can be used to process certain requests which would require Mathematica to run, for example verify on the server that the stident passes the test, by processing their notebook. Or, generate new notebook with tests.

• The more of the UI you could move to Mathematica, the easier things will be - it takes at least an order of magnitude more time to produce responsive UI in js than in Mathematica (unless you have expert knowledge of modern javascript frameworks). And what is more, you won't really need the capabilities of HTML / CSS / js if you only build a UI for yourself - Mathematica FE should be more than adequate for that.

  This would mean that you create two clients for your app - one for the students and the other one for yourself.

Here are some of the advantages of this scheme

• Good separation of concerns

  The overall management of a web app is left for a dedicated server / backend, and the Wolfram Cloud is only used as a service. The frameworks like Rails or Django are mature and time-tested, and have everything you need to develop and maintain scalable and robust web apps.

• Cost reduction & scalability

  If you base everything on Wolfram Cloud, you will send a lot of requests there which don't need Mathematica, and that would cost you credits. Also, they may not be as fast as appropriate, if you use cloud for some trivial updates of the records, since every time a fresh kernel would have to start up / be initilized in the cloud.

  Further cost reduction could be achieved (if necessary) since you could accumulate data from requests on the server, and then process them in Mathematica / Wolfram Cloud, in a batch.

• Security

  Your students won't interact with Wolfram Cloud directly. They would send their data to your server, where you can enforce a necessary security level and perform checks.

---

I am personally a big fan of Django / Python, for a number of reasons. I do realize that this choice can't be objective, but here are some things that I like about it:

• Transparency. Everything in Django is rather explicit, and while you do get a lot out of the box, there isn't so much magic, and it is easy to understand what is happening and why.

• Modularity. You can use parts of Django, and replace what you don't need with your own. Very roughly, Django has these parts: ORM, templating, routing, automation of request / response handling, and forms. You can use any combination of these, they are very loosely coupled. For example, if you just need a RESTful backend, you can just use the ORM, routing and request / response automation, and you won't need forms and templates.And as I said, everything is very explicit.

• Python as a language is just great. It is very straightforward and for me, it is enough to have just one language which allows to solve a problem in a zillion of ways (Mathematica) in my stack.

• Django has an integrated admin app, which is a totally killer feature. Basically, in most cases it allows you to only care about your models, and the (pretty sophisticated) admin interface is generated for them automatically.

---

As I said, I'd first try to base everything on Wolfram Cloud. Judging by your description, your app server logic doesn't sound too complicated, and it should be possible to build a working app pretty fast. You can later switch to the separate server model, if you see that the app is too expensive or does not scale as well as you need.

If you decide to take this separate server route, then, judging by your description, you should be able to get the server part up and running in just a couple of days at the most, and then simply add more features. Even in this case, having a fully working prototype based entirely on Wolfram Cloud would help you, so that time won't be wasted. If you decide to pick Python / Django, I can give more detailed information about how to get started.