kissjs architecture overview

In my previous post I explained why I'm building another js framework called kissjs. In this post I'm going to explain the architecture behind it.
I stated that kiss will be another javascript framework. But after some thinking, I came to the conclusion that this is not fully true. I think I'm going to call it a progressive code generator with integrated backend services. The reason for that is, that there is nearly nothing 'new' or special about kissjs code. It's more of a combination of different tools that already exist, glued together in a way that makes them easy and fast to use.

Let's start with the different layers of a kiss application:

• View Layer
• Logic Layer
• Data Layer

Sounds pretty standard? It is! But what I found a lot when looking at react codebases is, that there is a lot of logic and datahandling mixed into the view layer. I really don't like that. Kiss will provide a clear seperation betweeen the different layers (at least between the view layer and the other layers).

I have my background in game development with Unity and C#. We are developing with what we call the 'manager pattern'. Every feature in a game has a manager that handles all the business logic for the feature by fetching the needed data from services and manipulating them. The view just asks for the data it needs and displays them. We have had very good experiences going that way.
In web development it's basically the same, just that most apps don't follow that pattern strictly.

So let's translate it to kissjs:

View:
The View layer consists of standard react components, wrapped by mobx observers if needed. Nothing more. If a view needs data, it imports a kiss logic component and has immediate access to it's data. No need for fancy data loading hooks and all that stuff that blows up almost every react component.
Kiss uses ionic as it's view layer. That way you get native mobile views without any work.

Logic layer:
I call them Blocs. Bloc stands for Business logic component. Normally I would just call them managers, but this terminology is not as common in the web dev world. Blocs are just instances of regular typescript classes that get registered at the central kiss core. Whenever a class needs access to a bloc it can easily get a reference to it by calling kiss.bloc("blocname"). Most blocs will get hooked to the data layer (but no need for that. There can also exist blocs that only do calculations). Once the connection between a datastore and a bloc got established, all relevant data gets synced in realtime between them. All the data a bloc holds that should get exposed to views will be mobx observables. Kissjs will be smart about that and already take care of most of this when blocs get generated with the cli.

Data Layer:
This is where kiss really shines. Like every other dataservice, kiss datastores are responsible for loading and saving data. What I'm planning for kiss datastores is, that they all implement a common interface. This way they will be fully interchangable. There will be different datastores for different use cases. If your data need to be persisted to a database, you can use the SyncedDatastore and everything will get saved and loaded automatically. Do you need a datastore that holds relational data? Use the Relationaldatastore and it automatically retrieves and aggregates data from different datastores.
The grand plan is to have a bunch of different stores and blocs that can get put together and give you a fully working data layer without writing any code (almost).

This is just a rough overview of the kiss architecture and there really isn't anything groundbreaking. What I want to achieve is, that by providing a clean and scalable architecture, code generation and scaffolding works as expected in every stage of a project.