GEZINSMAN.NL

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. .This is l In onderstaande schema is dit geillustreerd in 7 stappen.

In below illustration this is illustrated in 7 stepsp.

1. Initial condition, in which gm02 is replicating from master gm01
2. gm02 is offline, al R/W connections are rerouted to gm01
3. gm02 is updated to the new datamodel dm02
4. data from gm02 is recovered by copying the data from dm01 to dm02
5. gm02 is online, gm01 is offline and all connections are rerouted to master gm02
6. gm01 is updated to new datamodel dm02 and is now operating as replicating slave server
7. Finally all connections are restored. However the roles has been turned around: gm01 is now replicating from master gm02!

The system is fully distributed, in which Java Microservices and Javascript Engines are used.
The gezinsman.nl infrastructure can be depicted as follows:

Our front-end system runs locally on the Javascript Engine in a webbrowser on your laptop, tablet or smartphone and consists of multiple controllers and services, of which the restservice is the most important. It takes care of the encrypted communication with the back-end. The front-end takes care, with the help of the controllers, of the user interaction.

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.

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 unanavailable. The majority of the system will still operate (in degraded functionality). In a monolithic system, one single 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.

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:

• First of all the development time and costs. These are for the front-end development significantly less, because one only have to deal with standard webbrowser techniques like HTML, javascript and CSS.
• 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 is responsive. With javascript libraries like angularjs, hammerjs, bootstrap, jquery, popperjs and openlayers it is possible to create a native look and feel. Next that, you also get the advantage that the app will be device independent! It will functions as easily on an android phone/tablet as on a IOS iphone/ipad in portrait or landscape mode.
• 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.