You're right - as long as one player announces "I'm playing Mirror Move", then it can be verified that the move that actually gets played was valid. The actually played move doesn't have to be in the state committed at the beginning.
Randomness as in the case of Metronome can be decided upon in the same way that other move randomness is handled.
Interesting - things like extra Dynamaxing moves should therefore be considered part of the initial state that's committed to. Clients could also check to make sure that the Dynamaxing moves aren't being used outside of the 3 turn limit.
Where I think this could be taken to the next level of reusability is in modularising the front-end into API-specific components. For example, the login behaviour could depend on FastAPI-Users, with a sibling frontend library containing components that implement the same login flow. Adding user behaviour is then a matter of using the same third-party library on the front and back end.
I've been using FastAPI for a while, and think that the API-driven approach that it endorses is a good paradigm for building web applications.
Since the design of FastAPI programs is often modular, with libraries and modules extending the API with additional routes, it seems to make sense to build front-end components according to the same module structure. I'm yet to see any of these for popular libraries, but I'd be up for helping build some in libraries like Vue.
Does anyone know of existing projects/server frameworks where backend modules are coupled with front-end components that consume their API?
Randomness as in the case of Metronome can be decided upon in the same way that other move randomness is handled.