State-based Software Development from a Data Model – onto the outer layers is old idea with variety of environments within and even outside of the coding world. This mode of organizing some type of information into reactive and responsive software and architectures is not a coincidence. It brings stability, security, scalability, ease of use and many more features.
First I’ve encountered state based thing outside of programming. I worked as Administrator/Operator in an Internet Coffee. The clients needed safe, clean, working computers for temporary use. With no extra additional software I was fixing the computers from time to time after bad users. The leftover files were a privacy and security risk – personal documents, downloaded porn, junk files, potentially harmful programs and files, etc.
Around year 2007 the he management introduced a Deep Freeze Software. With it – after each restart Windows started clean – configured once and saved as an image. This introduced problems with clients that failed to save documents until their time finished. But, it minimized our IT support work to a bare minimum.
The very same deep freeze concept has the docker image – just the image is a minimal Linux environment [even not exactly an entire OS] with predefined additional software, applications and settings. The dev-ops specialist or the System Administrator configures one script for multiple servers – in most cases with a relatively simple docker file. It could be used to instantiate multiple instances of the same application with the same settings and environment. This brings up scalability to the sky/clouds – literally. Especially key moment that allows scalability was the move of User Authentication and Authorization state away from the back-end – making this way the application server stateless.
By expanding the docker images onto the Micro Service Architecture you arrive at Kubernetes or other Platform where Services are capsulized into small chunks and easily scaled up (only the heavy loaded part – not the whole server). The Architecture of the Cloud Server or Service Environment is often configured with simple setup files, where limits are placed because of over billing. In some sense – it is a state based system administration /dev-ops/. Just the state are the config files or the scripts – not some “deep” source code.
The Java Desktop Visual Framework is hard to be imagined as a State Based Machine. But in same deeper sense it is. The Java User Interface is visualized by the dispatcher (main user interface thread). Touching it from another will bring glitches, bugs, crashes and inconsistencies. The source of the – “What and How to Display – may be some variables, state or some logic. This standardization, recommendation is analogical to how state based graphical user interface frameworks draw – only and preferably through a single channel.
Google Introduced AAC several years ago. MVVM + LiveData is literal direct implementation of state based visualization of whatever state onto Activity Wrapped or Fragment Wrapped Views. The View Model Wraps the state and pushes changes onto the User Interfaces with the Help of LiveData. LiveData is a reactive /Listener Design Pattern/ component that integrates with the Lifecycle of Android User Interface Views. It has the purpose to minimize the out of scope changes that often trigger illegal state exceptions or null pointer exceptions.
Flutter has Stateless Widget – that visualizes the incoming parameters without the possibility of change. Immutable states in/and objects are often embedded for optimal low and high level programming usage. This opens the hand of compilers for optimizations and increases the bug-free components and programs. That’s why it is in the core of Flutter and Dart. There is also a Stateful Widget in Flutter, although, the state is often out-sourced to outer – better architected components. In their core is located a state with reactive package that is reflecting on a user interface, or something else.
Angular Components & React or React Native Components
Angular and React are in their core – nothing more than the Object Oriented Paradigm onto the Web (and React Native and the other Cross-Platform Frameworks – onto the Mobile and other Platforms). The Components have State (or just final-immutable properties) that is reflected onto UI.
Integration of Rest Services / WSDL
Integration of State Based architectures within Rest Services and Web Services is something that I can’t talk with practical personal experience. But, as everything else from the low level source code, to the high level server setup has become state-based, it’s a matter of implementing the REST Data Model to an app. The state of the app could be injected with config files, with command line or database scripts or via web interfaces.
The Data Model of a service contains – URL, (HTTP) Method, List of Key-Value Headers, List of Key-Value Parameters, Content-Type, Body of varying type. All of the above objects, could be expected (configured) on the Input Side and from the Outer side. The Output of one Service and the Input of another could be potentially declaratively (or via Web Interface) glued together – Just Like Sex. But in software terms – these things could create chains or flows of processes.
These chains will probably start from the User and end to the User, but the back-end could have unlimited phases. I think I have seen such Systems, but I’m not exactly sure that their core Data Model was Rest/WS Based.
As software evolves, you will probably find more and different types of state-based development and implementations in more and more environments. You could ping me up to add them in this article if you wish.