The pMD Blog

Welcome to the
pMD Blog...

where we cover interesting and relevant news, insights, events, and more related to the health care industry and pMD. Most importantly, this blog is a fun, engaging way to learn about developments in an ever-changing field that is heavily influenced by technology.

Weekly Byte: Client-Server Architecture and Finding the Right Balance
Since the beginning of the year, the number of secure messages pMD processes everyday has increased by 300 percent. One of the key characteristics of any messaging platform is speed and providing the right feedback to the senders and recipients of messages. From amazing user feedback during the same period, we've built quite a few bells and whistles into our platform, letting doctors and staff overcome some of their longstanding communication and workflow challenges. As a developer, however, continually adding features to a system with very tight performance constraints always makes me doubly scrutinize our architectural choices.

It's easy to write a feature that significantly slows down what was once a snappy application. This is in fact all too common in the software industry. We've all experienced the first version of an app that is often fast, but a few years later, after 100s of new features, the system has slowed to a crawl. Typically as consumers, we take faith in Moore's law and simply buy newer and faster phones and personal computers just to keep up. SaaS providers can often times employ the same strategy with their servers by regularly upgrading hardware. Sometimes this makes economic sense, but often times it does not. Instead, it is usually best to try to mitigate the performance hit or simply avoid it with better code.

One interesting strategy that’s been on my mind recently is how to distribute code complexity between the server and clients. The server can often times handle an immense load but can also lead to centralized bottlenecks that become much more difficult to build around and maintain. Finding the right components of a feature that can be implemented on the client side can sometimes bring about immense gains, although not without some trade offs. In terms of maintainability, it is often considered that building server code provides faster iteration times. Because after all, we control the server while all upgrades to native clients like iOS and Android are governed not only by the end user but the respective companies (Apple and Google) as well. This can sometimes provide a huge incentive to keep the client software 'dumb' and merely a consumer and displayer of information.

Pushing complexity into web clients has its own challenges compared to smartphones. There was a brief period a few years ago when everyone wanted to build full html5 and javascript apps with the same functionality as native Objective-C and Java code. The results were discouraging in terms of performance, usability, and maintainability. Part of the challenge had been that for a long period of time javascript, the language of the browser, had been viewed as inappropriate for serious or intense work. Yet the language's renaissance in the last few years, and the astonishingly rich ecosystem of innovative VMs, frameworks, and tooling is breaking many people's assumptions of how complex and maintainable javascript code can and should get. Frameworks like angular and backbone help abstract away a great deal of the incidental complexity and let developers focus on the solutions to their problems instead.

In one of our recent projects, we’re planning on distributing some of the computational needs of a protocol to the web client while utilizing some modern frameworks. The result will attempt to capture the current sweet spot of where an application should live, and perhaps lead to both ‘smart’ clients and servers. Yet as the last few years have shown, this balance is always shifting and needs to be constantly reavaluated.