No.3063
>>378>if thats the case, i don't see why the app shouldnt be written as a monolithic app in a jvm language which calls cockshott's code,Is anyone ITT /are you familiar with a JVM backend framework? If so, you could go ahead and start prototyping. I would get onboard if it picked up some steam. I know Java pretty well, though I've never touched Spring or w/e. The main drawback is, when you pick a lang+framework and write a lot of code in it, there's a lot of inertia against rewrites or changing to something faster or nicer. Facebook even made a PHP-to-C++ transpiler for this reason. >after it scales or is worked on for a while the labor time calc/harmonization could be a separate service/program written in RUST or another low level language. After its done calculating it can update the DB with the new labor values.A fine option, though it could increase deployment complexity. Would give me the option to keep working on my project, and if it's just a service, the scope is more manageable.>>380>I assume this is going to be accessable via RESTful api? I plan to write a REST API, yeah. I'm working on a simpler (in terms of data layouts/consistency) project using Actix right now to learn it.>The type of programming we are doing here is very different than the usual 'take stuff out of a database and show it to the user' type web programming as it is involved with computationally expensive computations.Yes, but not only that. There are a number of issues when it comes to consistency:- Need to regularly save the whole data set to have a "price" history- Any update to a dependency quantity that increases the quantity (and only this kind of update) requires three calculation runs on the entire data set to determine whether it is valid (at least with my current dependency checking algorithm)- Need to translate the ID key in the database to the index of the Vec element (what if a product is removed?)- some other issues I don't have off the top of my head