A look under the hood
Because of the popularity and frequent use of open source software, GEZINSMAN.NL is able to produce web applications in a short amount of time according to the customer requirements. In this proces, short development cycles are applied, so that the customer and end-user directly see the end-result and therefore are able to guide the development process as earle as possibe.
A complex multi-user, multi-device application like GEZINSMAN.NL consists of mulitple layers. This can be illustrated as an iceberg as follows:
- The top of the iceberg is the user interface. This is all what the user sees and runs in a Chrome browser on the hardware of the end-user (PC, tablet or mobile). With the aid of modern webtechniques (PWA, service workers), a look and feel of an regular application is experienced by the end-user.
- The data on the server can be retrieved through a rest-api. Multiple servers are available for this purpose in a scalable architecture, over which the client connections will be divided. When the number of connections increases, more servers will get online to divide the load.
- The data on the server is stored in a cluster of databases, which are configured in a redundant master/slave configuration. In this configuration the database is replicated on multiple servers. This increases the reliability and maintainability significantly.
A selection of our tools and techniques
- Full Calendar
- Linux servers
- Cloud deployment
GEZINSMAN.NL guarantuees a high system reliablity and user experience with the help of
- clustering of redundant databases
- distribution of functionality
- client-side loadbalancing
- progressive web apps.
A cluster of data servers ensures a fast, reliable and scalable data interface. This cluster also has a local network, which is used to synchronize the databases between the multiple servers.
A web hosting provider hosts the domain and the static files.
With this architecture, a system and database upgrade is possible with zero downtime.
In below illustration this is illustrated in 7 stepsp.
- Initial condition, in which gm02 is replicating from master gm01
- gm02 is offline, al R/W connections are rerouted to gm01
- gm02 is updated to the new datamodel dm02
- data from gm02 is recovered by copying the data from dm01 to dm02
- gm02 is online, gm01 is offline and all connections are rerouted to master gm02
- gm01 is updated to new datamodel dm02 and is now operating as replicating slave server
- Finally all connections are restored. However the roles has been turned around: gm01 is now replicating from master gm02!
The gezinsman.nl infrastructure can be depicted as follows:
Our back-end system runs in the cloud on a Java Runtime Engine and consist of multiple microservices, for example the familyman and budgetcoach. Each microservice is responsible for a certain specific functionality of the system.
In this system overview, each microservice consist of a cluster of servers. Thesse servers operate in a master/slave configuration, also known as active/passive. The system can have multiple slaves (or passive) servers. Each client has both write- and readconnections. The write connection is always to the master server. The read connection can be any server in the configuration. Which one it is, is determined to system itself by online measuring and comparing the CPU and network load of each server.
Because of the distruted nature of the system, instead of monolithic, the system is scalable, fault tolerang and redundant. A distributed system is also more capable to divide the system load among the available resources.
Inversion of Control
With Inversion of Control (IoC) the so-called "Don't call us, we call you." principle is used. Each proces leaves a reference to a function at another process, which is called when this the data of that process has changed. The main advantage of this principle is that a process does not need to poll periodically for data. IoC is also known as publish/subscribe. The publish/subscribe mechanisme is used by the microservices to exchange data between the different services. For example, the user and session tabels, which are maintained by the gezinsman microservice, is also used by the budgetcoach microservice.
In above example the publish/subscribe mechanisme illustrated. It starts with a process in the budgetcoach microservice, which subscribes to the tables of the gezinsman database. With this subscription, an endpoint URL is included, to which the gezinsman microsrver can post data to. As soon as a create, update or delete (CRUD) action takes place on the subscribed tables of gezinsman, the changed data is publiced to the endpoint URL and will be handled.
Each microservice consists of a number of servers, which operate in a master/slave configuration. The microservice has as goal to execute one or a limited amount of functionalities. For example the gezinsman microservice executes the tasks administration, exchange mom, calender and geotracker. The budgetcoach microservice executes the tasks groceries, dinnerclub and budgetcoach. The advantage of a microservice is the splitting up of a large system into smaller, controllable subsystems. Each subsystem has it's own datamodel, which is maintained indepently. By splitting up a large system in microservices, it is possible to keep a large and complex system clear, scalable and maintainable. Each microservice has it's own software tree and independent version control.
A distributed system has as advantage, that it will remain functional in case system errors occur. If for any reason a microservice fails, then only one system will become unavailable. The majority of the system will still operate (degraded functionality). In a monolithic system, one sinle error will probably lead to a total system failure.
Another advantage is that each microservice can be deployed differently and in another location. They don't even have to be on the same server or datacenter. One microservice can be hosted in a datacenter in Rotterdam on a virtuele private server and a second in Gouda on dedicated hardware so to speak.
With traditional loadbalancers a central organ on the server-side determines which physical server is used by a client session. This can be compared to a system that is often used in government buildings, like a city hall. You enter the building, take a number from a machine and take place in the waiting room until your number is up. The central system looks which operators are available and determines for you, which one to take. The Achilles heel in this system is of course the central system. If it fails and is not replaced, chaos will arise.
GEZINSMAN.NL uses client-side loadbalancing. In this system, a client session determines on it's own which servers he will use. The session uses an algoritme, which takes multiple real-time system parameters from the server to do this. This can be compared with a supermarket, in which multiple cash registers are open. Customers pick the cash registers on the basis of own observations (length customers in line, shopping cart's load in line,
speed of the cash register operator, etc.).
Also when a new cash register is opened, a number of customers, who are especially at the end of the waiting lines, will change to this new cash register. The advantage of this system is that the intelligence of loadbalancing is distributed over the clients and that the total system has become more fault-tolerant.
Progressive Web App
The progressive web app (PWA) has the advantage of a website, but the look and feel of a native android or IOS app. The PWA can be seperately installed from within the webbrowser and has a (limited) offline functionality. With a good PWA the user will get a native app experience.
There are a lot of advantages for a PWA when compared to a native app. Here is a list of the most important ones:
- Next to that are updates more often and significantly more simple to realize. For cosmetic changes, only an update of CSS and HTML files on the webserver is needed. This is often combined with an update of the back-end, which is made possible with zero down-time, thanks to our microservices and master/slave architecture.
- The PWA stores an amount of received data from server in a temporary storage (cache). This allows the app to function in limited offline mode
- In contrast with a native app, only SSL communication is allowed. This means that it is impossible for outsiders to intercept any communication between the client and the server.
- The PWA can be easily installed from within the webbrowser with one single button action. When a user visits the website, a pop-up is shown, in which is asked to install the PWA. The user will get, just like a native app an icon on the desktop, which starts the PWA in a webbrowser. The user will get the experience, that a native app is started.
- As last advantage, that has to be mentioned, of a PWA in comparison with a native app is the findabilty. The app will just like regular websites be indexed by webcrawlers. And if you cleaverly define certain keywords on your site, you can accomplish that your app can quickly be found by those for who the PWA has been made.