Point of Sale Software: App vs Browser

I was able to face the comparison between cash points created with Apps or on browsers back in 2014 in aKite – Cloud POS: App vs. Browser but I return to it because in the meantime both fields have evolved and I still hear people saying that “a cash register on a browser is light”. That may be true, but only in extreme cases, as I’ll try to explain. First let’s clear the field of consumer applications focused mainly on smartphones. WhatsApp, Facebook, Linkedin and others are Apps for the best performance and “User Experience” and also for offline operation. The less frequently used applications are instead based on Browsers because the operations of accessing a “store”, downloading and installing a new App require an application and several minutes. The new Progressive Web Apps (PWAs) try to combine the immediacy of a web page with the performance that only a little local intelligence can provide, by downloading code in the background that gradually installs itself inside the browser. Let’s now move on to the professional world, where a device is used continuously for years and where the few minutes to initially install an App with a click from a web page seem like a dream compared to the intervention, even of hours, of a specialist for installation of a traditional program. What matters are performance even with cheap devices, safety and resilience in the event of failures, needs that also involve architectural choices.

The paradigm shift of the Cloud

Before the Cloud, the cash points were part of the “departmental” system of the shop, capable of functioning autonomously and periodically exchanging data with the center of the chain. With the Internet, “centralized” systems, also known as “hosting”, have spread, where data and intelligence are exclusively at the centre. The risk of total blockage of activities is often mitigated by a backup database in each POS, with additional costs and complications. Even a redundant line can become null in case of blockage of the central server. True Cloud Computing has introduced real paradigm shifts, such as PaaS (Platform as a Service), multi-tenant Microservices orchestrated by SW such as Kubernetes and “distributed” architectures, so as to give birth to open technologies such as DAPR (Distributed App Portable Runtime). The browser was born as a multiplatform viewer of centrally managed content, but the computing power and memory of any device present in the POS (smartphones, terminals, tablets and PCs) allows you to perform many local operations without additional costs, just like the Apps do Redesigning a form on a central server and sending the instruction to the device’s browser to change a few pixels, when it could do everything by itself, is the reason why intelligence is brought to the periphery. In Apps, execution is direct and optimized while inside browsers, languages ​​such as JavaScript are used that access device resources only indirectly. I remind you that even bits are subject to the laws of physics: they require energy to travel and cannot exceed the speed of light. Everything that can be done locally avoids delays for forwards and backwards of data and work on central servers, with an improvement in performance and environmental sustainability. By “distributing” even a copy of the most frequently used and least subject to change data to the periphery (in a cash point: products, prices, customers and promotions), you further reduce time and energy in data exchange and, more importantly, the normal sales operations take place quickly and undisturbed even in the event of a connection failure or problems with central services. Sales data is automatically queued and transmitted as soon as normality returns. Local data synchronization (also necessary in a “centralized with local back-up” system) must be reliable and efficient. The “cloud-native” mode is based on asynchronous messages generated by events. In this way the update is immediate and limited without resorting to periodic replications of entire databases, sometimes completely useless and sometimes late.

The Comparison

In this diagram I try to represent the memory occupation and interactions with the cloud, with the relative pros and cons. The data are averages obtained from personal observations and are intended to give a relative order of magnitude. Assuming a centralized architecture, local code in the browser is reduced and data exchange with the cloud is elevated. A distributed architecture implemented on the browser would further increase the memory footprint, where smaller = more efficient. In addition to the lower memory usage of the Apps, the main advantage lies in being optimized for the O.S. chosen and not to require additional processing by the browser. Pros and Cons mirror each other.