- Protected by authentication and authorization
- Client-server communication
- “Intelligent clients”
- Capability of working offline
- For enterprise applications: Use of multiple screens and Multiple modules / sub-applications
Besides the underlying technology, a major difference is the interaction with the server. The database connection of the old rich clients is replaced by the stateless REST communication.
With business critical applications, users use these applications intensively. The UI needs to be highly optimized in terms of workflow, but also in terms of displaying the right information. The speed of responsiveness is very important. If you are navigating through the screens and making changes hundreds of times a day, you do not want to wait seconds for the next screen to appear. The next screen should appear immediately. This is achieved by keeping the state in the client and only transferring changes to the server in the form of JSON documents.
This allows for a different design of the REST interfaces and data handling. It results in a different type of client application. A progress web app (PWA), e. g. defines a set of technologies used to deliver not just a web application that runs in the browser, but a complete application that can be installed and run as a standalone application. A progressive web app is an app that’s built using web platform technologies, but that provides a user experience like that of a platform-specific app.
One element of a PWA application is its offline capability. The architecture pattern behind is to store data always locally and perform the communication asynchronously in the background. The application is mainly using the data available locally. The usage of the application is independent if a network connection is available or not, of if the network is limited. This allows not only the application to be used when offline, but also makes the application much faster to use. As the data is stored locally and therefore available, a response to a user interaction is directly answered with data that is locally available. The local data is stored in memory (e.g. Redux store) and index DB for long term persistence. As there is data on the client and data on the server, a synchronization mechanism is required. This means that changes on the client are send to the sever and the client receives new changes form the server. Normally a generic logic is used, which can take care of data synchronization independent of the type of data. If the data synchronization is based on JSON objects, only the most recent changes are sent. Older versions of the changed objects are no longer needed and are discarded.
Depending on the data and how offline is handled, there are several ways to synchronize data with a backend system: If you have complete JSON objects, every changed object can be sent to the backend server. An alternative is to send only the delta information (e.g. changed fields) or to use an event source based mechanism.
From a high-level perspective, having data available offline and doing all the data synchronization in the back end sounds simple – but it is not. When data is kept offline and is synchronized to a backend server, and the data is based on regular business entities used by multiple users, conflicts can arise, which must be handled by the application or the synchronization layer.
As data is processed asynchronously in the client, a queue mechanism can be used to manage the data processing. E. g. can an inbound and outbound queue decouple the sending and receiving of data from the stored data. It also decouples the persistence technology from the synchronization logic and allows specific implementation for persistence or encrypted data. Using a Redux store in a React-based application also allows the UI component also to react to changes in the Redux store.
Advantages of offline capabilities
Once a data synchronization mechanism is in place, in addition to the offline capability, it enables three scenarios as shown in the following figure:
- UI updates when new data is received from the back end
- Synchronization not only between a client and a server, but also between two clients (via a server)
- Event-driven architecture by sending commands in JSON objects over the synchronised data objects.
The data synchronization mechanism described above, which allows offline use, is not suitable for all types of applications. There are applications where you want the changes to take effect immediately, such as user management, or if you have a control UI for a switch. Also, if you have an application where you need a lot of data, for example for reporting, then the effort to keep the data available offline and to synchronize the data is much higher.
Having a data synchronization at your fingertips is a very powerful technology for business applications. As a developer, you can simply work with a local database and save any changes you make in the application against to the local database. For a new use case, only the new type of data must be defined, which is automatically stored. The data synchronization is independent of the data type, any data can be synchronized. No new REST interface must be implemented. This speeds up client development. The interface to the backend system is the data structure, which can be even treated type-safe if TypeScript is used.
The communication to the server is done asynchronously. No direct return / response codes can be used. The event driven architecture is based on events which are processed. The result can be events again. In case the result is an error, the error can be passed on as an event back to the client.
The question is how to execute, e. g. a “publish” command in case of an offline first application. One approach is to use the command pattern and trigger actions on the server side. The command “publish” is part of the JSON documents amongst the data itself. The result of the operation can be also stored in the JSON document. The “result” is an event of the same document, which was received, just with the result of the operation included. For example, if a travel claim form is submitted, the status may be ‘sent’ when it is still locally stored. Once the document is synchronized with the backend and therefore “received” by the backend system, the status can be changed to ‘sent’ or ‘received’ to ‘processed’ once the claim form has been processed by the backend system. The single JSON document therefore always contains all the required data, as well as the status and any messages and meta-information. The event-driven approach perfectly fits to the Redux technology in the client and the JMS technology in the server:
An offline first application is not only usefully when the application has to work in offline scenarios, but also offers other advantages like better user experience and less effort implementing individual REST interfaces. An offline-first approach also requires asynchrony communication, which must be managed by your application. This can be achieved by combining the offline-first application with the event-driven architecture that can form the basis of a reliable and resilient modern web application.