Flexbase

This section explains the control flow in applications built using Flexbase.

The API layer is written on top of Flexbase. Flexbase imposes no constraint on front end use. It could be JavaScript, it could be swift app, it could be a cross platform mobile app, it could be a robot, really doesn’t matter.

A request from front end reaches the controller. Request is authenticated at the controller.

The basic request content is validated and the request is passed onto the service. Service is an orchestrator.

A service invokes Flexi-sequence. Flexi-sequence is a sequence of plugins. Flexi-sequence follows what is called a pipeline pattern.

The sequence makes sure that every plugin is invoked with data packet. Each plugin does its job by picking whatever input it needs from data packet. It assumes that the input that is required by plugin is available in the data packet. Once the plugin has done its job, it drops error / success status in the data packet. Note that each plugin does one and only one job. This follows the single responsibility principle.

When all plugins have done their job, the data packet goes back to the service. The service examines the data packet for errors. Note that the service had no idea which plugins were called, what each plugin did, which plugin threw any error, if at all. All it knows is to examine data packet for any errors. If the service finds any errors then it returns failure back to the controller by providing all errors that were found. If however none of plugins returned an error it means all business rules are passed and the request is now valid.

Flexbase control flow

Here, Flexbase adopts an asynchronous processing pattern. It does not process the request in terms of persistence or communication with any other 3rd party system in real time. It is because such real time communication mechanisms are inherently error prone.

Flexbase implements eventual consistency. The service encapsulates the data packet into a command, and drops the command into a service bus. The service can return a success flag back to the controller, which communicates it into the front end. At this point in time, the request has not yet been fully processed, however the request has been validated and found to be correct. It is now the job of the system, to make sure that the request is put through and here the enterprise service bus feature of Flexbase kick in.

A command handler automatically picks up the command and processes the command. Once the command handler has successfully processed command, it drops an event back into the enterprise bus. A command is a direction, it is always worded in the imperative. For example “Initiate Fund Transfer”. An event is however, something that has happened in the past. Always worded in the past tense. For example “Fund Transfer Initiated”. Events can be handled by one or more handlers, this follows a pattern called “Publish -Subscribe”.

All of handlers which are to process an event are automatically invoked by Flexbase. They pick up the event and process the event adhering to the single responsibility principle. Each event handler can in turn drop its own event and the circle can continue. A very complex functionality can very easily be implemented using events and event handlers. At atomic level each class is doing exactly one thing. Touching one class doesn’t affect anything else.

The system is guaranteed to be stable even when there are changes happening in the system. Suppose a command handler or an event handler fails to run, a retry mechanism is configured in Flexbase. Flexbase makes sure that the command handler will run multiple times as configured until the request is successful. If however that is deemed that the handler cannot process request after the maximum number of tries, command or event is thrown into the error queue for appropriate error processing.

This way Flexbase architecture ensures that the request flow is asynchronous from controller to the end of the processing of the request / generation of response. There is no blocking request, because of which the end users’ experience of performance is smooth and fast.

All read-writes in Flexbase are done async and handlers can be easily scaled to sit across distributed machines. It can leverage parallel CPUs.

We are talking about developing application which is asynchronous, parallel, distributed, adhering to the single responsibility principle and having a standard coding pattern simply by following the Flexbase architecture design.

Now let's add to it - speed. All the magic of Flexbase that handles these non-functional requirements can be automatically generated by Flexstudio and Flexgen. This means you don't even have to write the plumbing code.

In next section we discuss how Flexstudio & Flexgen make the magic happen.