Overview

## Server and Client Side

### Combining the front-end with the back-end
BindKraft combines the server(s) and the browser into a platform for small and big projects where the pieces developed can act as separate applications working concurrently in an OS-like environment. The end-result may look like a desktop or like a traditional WEB application depending on the design, but behind the scenes everything is organized on multiple levels into logical structures designed to build upon each other in the best traditions of OOP. 

At the same time, reusable component APIs are defined on all levels and components can be created for both universal and project-based reusability. The workspace of a BindKraft system is comprised of normal framework components and can be designed to fit custom needs and user interface strategies virtually without limits – e.g. you can have a desktop-like environment where users launch apps to do their work, but one can go into a different direction and make the workspace resemble an application that opens the other apps in specific slots as if they are just part of it, the isolation will still be there, but the looks and user experience can differ.

### The Client Side
Applications with a user interface usually consist of some background linking logic, visual containers ordered, nested, various control elements, forms and views where the actual work is done by the user. The BindKraft JS framework provides the base classes, services and API for that, presenting it as Apps/Application, windows – containers and views plus view-like pieces to enable the developers to manage application functionality on any level – general (app – the hub and controller of it all), wireframe – the containers for the rest and granular level – views, active elements, controls, manual binding, etc. 

This is the client side of the framework. It offers a number of solutions and an API to enable developers to build any number of fairly isolated application constructs that run in a single WEB page together. Depending on the purpose of the project, they may resemble the desktop of an operating system or look like a single application, but still keep their isolation. Being what they are – applications running on the client, one can say that they view the server (and other servers) like the usual desktop applications see the API for file or network access. Still, we saw an enormous opportunity for improvement in bringing some patterns and standards to this communication layer, so that client side applications can not only gain portability, but also (and most importantly) implement their functionality with minimum effort. 

We are defining standards and building reference implementations for them. Our goal is to cover the few basic kinds of server access from which almost everything else can be created. Having a standard for each of them, the framework on the client can offer ready solutions, services and building components which otherwise one needs to design explicitly.

### Client side - OOP from top to bottom

Too often Object-Oriented Programming remains just a slogan in many programming environments. In BindKraft JavaScript it is used to the fullest extent for everything. Whatever you do it is done by inheriting the right classes and slapping additional ready-to-use functionality on them by using implementers and even simple interfaces. OOP here has your usual class inheritance and interfaces, but also adds the so-called interface implementers and helpers to form something we can call hybrid inheritance which gives the developer most of the good sides of multiple inheritance, but still keeps the overall logical structure close to the simpler and easier to understand single class inheritance. This technique allows for less deeper hierarchies and much more flexible functionality reuse/implementation than traditional single inheritance. 

With BindKraft JS we had to decide what to do with Javascript – try to run away from its weirdness by employing compiled to Javascript languages, or stick to the latest versions of the language on one hand, or on the contrary – use the strangeness in Javascript to enhance it in a way that can make OOP more powerful and easier to use, and the lack of strict typing a blessing instead of a curse. We chose the latter – enhance Javascript by using its own features. Among other benefits this also eliminates the need for additional preprocessors and build steps.

### The Server Side

WEB applications have to have a main server from which they are loaded or at least a server that takes care of the main data. Most often this applies even to very networked applications that, by design, communicate with a number of services provided by various servers and for typical business applications that server is even built together with them. 

The particular application architecture can be anything between the classic and the microservices state of things. It will be able to still obtain data and save it back with changes, add data and so on. So, we decided to identify patterns of usage and build standard frameworks for them. The client side uses adapters (very much like drivers) that deal with the specifics, but beyond that there are established principles that form the basis for the standard and this way allow the client framework to integrate/bind with the server in a deterministic manner, which allows for ready-to-use components and features, and eliminates trivial and repeated work. 

Everybody knows that behind the famous “business logic” we often end up with huge piles of code doing the mundane and repetitive tasks of spilling data from model to model and deciding what to call to load or save it. Why do that when we can track the state of the data and automatically channel it to the right places. Our data access mechanism is based on shared state tracking between the server and the client and works with trees of data enabling small and big chunks of data to be transferred and processed automatically. 

The size of the data depends on the developer’s decision and can vary from simple flat collections to complex trees and pieces of them – both the basic functionality and the plugins for it work seamlessly no matter the size, no matter if you deal only with whole trees or glue/split them in various ways. As long as you send/get each piece from the right (obvious to determine) node, most of the work you usually associate with this will happen automatically.