I have a client-server system modelling an interactive business process with the following four constraints:-
The client may have stale data, and/or the client may be untrustworthy. All client-side commands must be validated on the server before their effects become "truth".
The client's user experience (though not normally the process itself) is sensitive to latency, the connection between the client and server is not reliable, and users need to be able to continue their workflow while outside of network range. The client must (to an extent) be able to update its own view of the state without making a round-trip to the server on every command - though the server may eventually reject those commands once communication is re-established.
The client and server hardware do not share a platform. My ability to share an implementation between client and server is severely limited.
The process is complicated, multi-step, and interactive - far out of scope of e.g. annotation-based validation frameworks.
My current intention is to build a system resembling the client-side prediction used in e.g. computer games. This necessitates building a "copy" of a sufficiently complete portion of the state of the system on the client, having the client evaluate commands against this cached copy of the state, and then synchronise those commands with the server as and when the connection is available.
To achieve this, it is necessary to essentially build the entire system - state, commands, rules, and events - twice. Once on the server platform, and once on the client platform.
I've come up against similar requirements previously, but never with all four of these constraints. I've always been able to either a) accept that the client might be untrustworthy, b) accept that the client must check-in with the server on every action, c) use the same implementation of the process on both client and server (e.g. shared binaries, or node), or d) coerce the model into something simple enough to use a validation framework.
I'm investigating transpiling, and also somehow invoking a compatible scripting environment from the server. While those investigations are ongoing, my initial conclusions are that doing so will be more challenging than maintaining two "copies" of the process.
Before I embark on this folly: are there any other strategies for interactive client-server processes that minimise the requirement for duplicate implementation?