Cookies improve the way our website works, by using this website you are agreeing to our use of cookies. For more information see our privacy policy. OK

Web Applications That Operate in a Whole New Way

Web applications that use nyssr.net work completely differently than we are used to. This also opens up entirely new possibilities, such as distributed applications, load balancing at the dialog level, high performance, and more.

How can web applications with nyssr.net be categorized?

Web applications under nyssr.net consist of distributed Micro UIs and Nano UIs. They are made up of small services executed across a network of nodes. The frontend modules are completely independent from one another, just like the backend services. They can be freely deployed on any node within the mesh network and communicate seamlessly without configuration. For the client on the website, no difference is noticeable.

Micro-UI and Nano-UI with <ss-nn1>nyssr</ss-nn1><ss-nn2>.net</ss-nn2> and <ss-rs1>Remote</ss-rs1><ss-rs2>Skin</ss-rs2>

Micro and nano frontends with nyssr.net and RemoteSkin.

What is different?

Webserver
The web server of a nyssr.net node is a plugin that is only 8 KBytes in size.
Operation of the web server
Our web server delivers a static framework webpage without any content. After that, it only serves images and files that it does not possess at startup.
Communication with the browser
The static webpage contains a small JavaScript program (21 KBytes). This establishes a WebSocket connection to another plugin of the node when the webpage starts.
The WebSocket plugin on the node
This plugin is approximately 150 KBytes in size and forwards the content from the node network to the browser. Browser events are relayed to the node network.
The application
The application is merely a small microservice on another node. It is primarily understood as a starting point for an application. Typically, it does not display any content in the browser, leaving that to other microservices.
The application has the address of the WebSocket plugin and can pass it on to other microservices that represent dialogs. Any service that has this address can modify the internal DOM tree of the browser, thereby displaying dialogs and widget groups.
Event processing
The content-generating microservices register the HTML element IDs they are interested in with the WebSocket plugin. Events from elements with these IDs are forwarded to the microservices via messages.
Distribution
Application and dialog microservices can be executed as plugins on any nodes in the network. They are typically installed redundantly on different nodes. This enables the system to perform load balancing at the dialog level. It distributes the load and provides fault tolerance through redundancy. No configuration is required.
Starting a dialog
Starting a dialog is done by sending a message to the corresponding microservice. The message contains:
  • the microservice ID (the resolution of the service is handled by the system)
  • the address of the WebSocket plugin (for modifying the DOM in the browser)
  • the session token (obtained through the login before starting the application)
  • the parent HTML element ID (everything within this HTML element belongs to the microservice)
The microservice can freely communicate with the caller, as well as with the rest of the system.
Javascript
A dialog microservice can easily install its own scripts. When the dialog is closed, these are removed.
Stylesheets
A dialog microservice can easily install its own stylesheets. When the dialog is closed, these are removed.
Files (images, videos, documents)
Files are usually not yet available on the web server node. They are located on one of the many file stores of the nodes. By sending appropriate messages to the WebSocket plugin, it downloads the files from the file stores and saves them in a directory of the web server. After that, the browser can download them normally.
Real distributed micro frontends on mesh of nodes with <ss-rs1>Remote</ss-rs1><ss-rs2>Skin</ss-rs2>

Real distributed micro frontends on mesh of nodes with RemoteSkin

What advantages does this offer?

Distribution
Dialogs are distributed across the nodes. They are located where the load is highest, or near the resources they use (e.g., databases), or where their responsible team works.
Load Balancing
Load balancing occurs at the dialog level, not at the application level.
Redundancy
The same dialog on different nodes increases the fault tolerance of the network.
KISS principle (Keep It Simple, Stupid)
Small modules are easy to understand, even after years and for new programmers. No one accidentally breaks applications when a dialog is modified. This allows a single programmer to manage hundreds of dialogs.
Configuration
This is not required. This makes it possible to divide an application into hundreds of services.
Performance
The performance of the applications is extremely high, even though microservices are executed on nodes that are far away or connected with low bandwidth.
The reason for this is
  • the use of 100% asynchronous messages
  • the small size of the messages
  • the use of compressed messages
  • the high performance of the mesh network
  • the load balancing
  • the absence of the connection setup
  • The file size of all components involved
Time-to-Market
The system promotes very rapid development of new services and dialogs.
Costs
Through rapid development, easy maintenance, and quick onboarding of personnel, they save a lot of effort and money.