For a tablet deployment, which this is in part intended to facilitate, I think it’s reasonable to expect that the server performance will greatly exceed the client. Even when the clients are computers, it’s not unlikely that the server machine will be more performant than the client machines, which in at least one case that I’m very familiar with, are mostly old donated laptops.
I think the first question to answer here is which kinds of devices and resolutions we support. This is a great topic to discuss - worthy of creating an RFC proposal for. I don’t know much about OpenMRS’ current approach to mobile/tablet. Here are some open questions that I think an RFC should discuss:
- which combination of phone, tablet, desktop do we want to support? What is min resolution we support?
- Does feature parity for desktop and mobile make sense? Some features might be better suited for only one or the other.
- single codebase that’s fully responsive? A separate codebase for mobile vs desktop?
- Have there been any talks of native phone/tablet app? If so, that might change answers to other questions.
Client rendering performance
The answers to the above questions would inform our decisions about what we should shoot for with our network perf, cpu, and memory usage.
Generally speaking, phones and tablets are 100% capable of doing client rendering very well and efficiently. They have been doing so ever since smartphones and tablets have existed. Unless we’re supporting very very old phones, client rendering by itself will work just fine. That said, we will want to make sure we don’t let browser memory and network usage get out of hand. One thing I’m proposing that will help with this is the creation and use of common dependencies, which prevents large shared libraries from having to be downloaded and executed more than once.
I’ve been viewing the shift toward a new UI as an opportunity to do smarter data management and reduce the number of independent AJAX requests, which presently is in the zillions.
@joeldenning is against having a consolidated client-side data store, arguing that this would constrain apps too much and be fragile.
I’m against having a shared redux store, because of the implicit contracts that arise between the microfrontends, the actions, and the shape of the data in the store. But I am in favor of preventing duplicate network requests via other strategies, such as a global, in-memory cache of highly used data. Another option is to have a core frontend module “own” the data. Or even using global variables. Preventing lots of duplicate network requests is something I’m committed to.
CPU/RAM: This will probably mostly depend on choice of frameworks, right? Should developers be thinking about some of the lesser-known-but-faster frameworks like Preact, Elm, and Svelte?
Summary of this ^^ is that the major frameworks (react, vue, angular) all are used on many existing mobile sites and they do fine (or even great). First step for us at OpenMRS is to figure out what types of devices and resolutions we want to support. I doubt that we’ll run into a situation where the extra gzipped 100kb to download React (instead of Preact) would be so inhibitive that we couldn’t use React.