Using the Wolfram Language in a Commercial Product
Preface
I feel inclined to answer because I live in both of the worlds you are describing. For one, I work in science where it is more than typical to write software that has sophisticated algorithms under the hood, but cannot be compared to modern apps. This software is rarely "market-ready" in terms of user experience, let alone the principles like web-first. Due to my work on Jetbrains plugins, but also by working on, e.g. JabRef, I know how hard it is to write software that is used by many people.
Please take the following for what it is: An opinion from someone who loves Mathematica and used the system for over 15 years but doesn't think the Wolfram Language is the best tool for everything.
Answers to your statements
I am by no means an expert in Mathematica, but from what I can see the MMA prototype code is monolithic [..]
That is not true. Finished Mathematica applications or libraries should be developed as so-called packages which can contain many modular files, private functions and things that are exposed to the user. Like in other languages too, these packages are then loaded in your session and you can use the functionality. Same as import in Java or Python.
It is my understanding that Mathematica is a front-end for the Wolfram language that is best suited to presentations and prototypes. If this is an incorrect assumption, please put me right!
Yes, Mathematica consists of the front end that stores computations as notebooks and has all kinds of nice features for dealing with, e.g. graphics or laying out graphs. However, the computations are done in the kernel which is nowadays called Wolfram Engine and which is connected to the front end. The front end, however, is essential if you want to interact with graphics, images, sound, etc. or want to make dynamic plots or UI.
I'm also facing a number of challenges getting the Mathematica notebook format working in any useful way with source control (git).
Just don't. Working with plain-text packages solves these problems. Look for instance at the IGraphM package of Szabolcs which is an excellent show-case of a modular Mathematica package which is actively developed for a long time.
As for integrations, I have looked at .Net / Link, but have not yet tested it to see if it's suitable. Any comments on experiences around this would also be welcome
The links to Java and C work excellent, and I'm sure .Net is only a wrapper around the C link (called MathLink or nowadays WSTP) and works equally well. However, the crucial part is that when you use Mathematica functionality, you will always need a Wolfram Engine in the back that evaluates your requests. So your users will either need a local license or if you are running a web-service, you will need some of the cloud-stuff or a webMathematica. You should not forget that this means you have running costs. To say it plainly: You cannot deploy a Wolfram package which integrates into your app without needing a Wolfram Engine.
My advice
If the Wolfram code doesn't need to be extended in the future and it doesn't use advanced algorithms available in Mathematica, I would think hard if it isn't better to re-implement it. This has the following advantages:
- You don't need a WolframEngine in the back which saves money and prevents you from errors/hangs/slowness which are not under your control
- You can debug and maintain code in a language you are used to and you won't run into surprises from a "black box" Wolfram code
- You can ship your app to whichever system you like. I might be wrong, but I haven't heard that the WolframEngine runs on Android phones
Therefore, in a first step you should carefully assess the Mathematica code you are dealing with. The big question is, does it use advanced functionality that will be hard to re-implement? You should look out for the usage of
- complex plots or visualizations. For instance,
ContourPlot,RegionPlot, but others as well contain sophisticated algorithms to create what is finally displayed as graphics or 3D graphics. - symbolic calculations like
Integrate, solving differential equations, optimization (Minimize), or working with statistical distributions. But also stuff like simplifying large symbolic expressions or the usage of special functions - advanced numerical algorithms used for optimization, statistical testing, integration, image processing, etc.
Update: What you could do, hopefully without breaking any NDA, is to share the list of system functions your monolithic notebook is using. This would help to point out potential problem-functions. You can use something like this:
file = "/path/to/your/notebook.nb";
Cases[
NotebookImport[file, "Input" -> "HeldExpression"],
s_Symbol /; Context[s] =!= "Global`" :> HoldForm[s],
Infinity,
Heads -> True
] // Union
This would give a first glimpse of what you are dealing with.
To give you a specific use-case: If all your Wolfram code is doing is handling data and calculating, e.g. statistical things like mean, median, variance, etc., I'm sure you can easily re-implement this. However, if you are relying on a ContourPlot3D, you need algorithms to find the contour of a possibly complicated function, create the polygons and display them as nicely as Mathematica does. That's more work to re-implement or find appropriate libraries.
The next question is, how likely is it that your client will make changes on the Wolfram code or incorporate new features? If the functionalities are final and you can re-implement all algorithms, then I would opt for a re-implementation. However, be aware that only one single line of Mathematica code that needs to be updated can bring you in big trouble on the .Net side because things like TextRecognize will be hard to re-implement in the same way they work in Mathematica.
The full product is part of a cloud-based enterprise solution and will be a cross-platform mobile app and / or SaaS web application that heavily integrates with an in-situ RESTful API (data lookups, data storage, federated identity / security etc). It may also potentially require integration with mobile device hardware, depending on how the requirements pan out.
I might be wrong here, but I'm not aware that the Wolfram Engine runs on mobile devices. Therefore, you will very likely need to call it on a server running the Wolfram Engine. This is a bit out of my comfort zone but this should mean your server needs to provide computational Wolfram power to many requests with low latency, right? I would think really hard if I need to go down this path.
I guess that's most of the things I can say without looking at the actual code you are dealing with. If you have further questions, let me know.
I agree with the comments above, that is, using packages written as pure text .wl files. Integrating Wolfram Language code as part of an enterprise solution is not an easy task. I recommend contacting Wolfram Technical Services. They have significant experience in development and integration at this scale.
http://www.wolfram.com/technical-services/?source=frontpage-features