Ziniki
Ziniki transforms the web development experience by capturing, embedding and refining the lessons we have learned over the past two decades.
There are two complementary offerings:
• The functional actor-based language, FLAS, provides a consistent way of defining actors which can be deployed on client or server side.
• The microservice container and environment, Ziniki, provides a consistent environment on both server and client in which to embed microservices.
Ziniki includes core modules such as data and content stores, together with third-party integrations with services such as Twitter.
FLAS is based on the actor abstraction: cards, services and agents.
Cards encapsulate data, message handling, event handling and UI.
Services allow new, rich microservices to be defined on the server side.
Design and Code are built separately using the most appropriate tools.
Compiler brings the two together, statically checking for consistency.
HTML ids are used to connect code to elements.
In common programming languages, designers and engineers work together through communication rather than collaboration.
A design must be completed and then handed off to engineers for conversion to a special markup format before it can be included in the product.
Alternatively, designers must deal directly with complex and awkward tools and languages.
FLAS solves this by automating this conversion process, only putting the burden of including FLAS-specific ids on individual elements that are referenced from the code.
The compiler statically checks that all the ids referenced in the code are actually present - and have the correct role - in the design.
Ziniki Server can easily be deployed to the cloud.
Server automatically serves provisioned applications.
FLAS has direct, language-level support for unit and system tests.
Units are defined as actors: cards, services or agents.
System tests model interactions between actors without infrastructure.
Existing programming languages do not have native support for testing. They depend on writing tests in the same language, with the same set of facilities as production code.
FLAS directly supports unit testing. Most importantly, it defines what constitutes a "unit": the actor, a card, service or agent.
Tests are written in their own sub-language, similar to the main language but with specific constructs to enable both arrange-assert and mock testing.
The functional nature of FLAS itself supports testing through clarity, controlled state and message passing.
The self-contained nature of actors means that all side-effects can be explicitly declared and captured in any given test.
FLAS supports system level testing by permitting the definition of tests which involve multi-step interactions between actors without having to configure or provision any infrastructure.
The system tests enable developers to confirm that their individual components work in the way they intended.
Simple test double support for system infrastructure enables tests to be easily configured and analyzed.
Ziniki has security built in.
Secure access is at the lowest levels.
Basic security handled automatically.
All FLAS actors are reactive by default.
The infrastructure directly handles display updating.
Code and display are decoupled through the current state.
Reactive, event-driven, push programming has been part of everyday programming for decades now. But languages are still stuck with an "imperative by default" model with the consequent assumption of a "pull" model.
FLAS alters this by putting message passing front and center - it is the only way for actors to communicate and state can only be updated at the end of processing a single message.
The current state of an actor - only visible within methods on that actor - can only be updated from within methods on the card.
The display is generated by combining the current state with a provided set of HTML and CSS files.
Cards have explicit syntax to handle UI events.
Ziniki Servers can be deployed independently.
But can communicate and reference remote data.
Security is handled seamlessly.
Common interaction patterns are part of the language.
Syntax is lean and based on white space.
Programmers spend a lot of time writing boilerplate of one kind or another.
The most common kind revolves around telling the compiler what you want to do. As much as possible, that is eliminated in FLAS by using lean syntax and using white space to define the relationships between items.
But a lot of effort also goes into developing, and interacting with, containers, libraries and frameworks. FLAS automatically includes messaging passing and UI frameworks with direct, implicit framework support, obviating the need to even think about that boilerplate.
Similarly, the common language and data structures, together with native support for data storage, mean that transformation layers such as ORMs are irrelevant.
Multiple Services offered in base Ziniki.
Data and Content storage.
Integration with other services such as Twitter.
Developers can run one or more Ziniki servers locally.
Deployment possible to Ziniki Network using IAAS.
Or you can deploy your own instance with a supported cloud.
One Language for Server, Browser and Apps.
Single Data Definition from data storage to UI.
Code can be shared anywhere.
It is possible to consider that JavaScript can be used on both client and server side, but in reality the differences between the runtime environments mean that almost no code can be shared.
With FLAS, all elements other than the actual cards and services themselves can be used seamlessly wherever needed.
Likewise, data may be stored or transmitted with the same data definitions being shared at every level of the system from data store to card.
Because of the message passing model, the same environment exists everywhere - the only difference is the (very real) performance charactertistic of location.
Static Types allow compile-time errors.
Type inference reduces boilerplate.
Many languages have static type checking, but it often comes with significant overheads in terms of defining types.
FLAS requires type clarity, but can generally infer types. A type needs to be declared in one place (for example, a contract definition) but then it can be copied to other locations.
For those occasions when you really don't know, FLAS offers "top" types such as Any and a cast operator.
Can target multiple back ends.
In particular can generate web site and mobile apps.
Because FLAS is a higher-order language, it is not natively ready for deployment to any platform.
But for the same reason, the compiler is capable of converting the code to any suitable back end framework, such as HTML/JavaScript, Android, iOS/Swift or WASM.