FullJS - User contributions [en]

Application Server

2025-09-22T05:38:05Z

Guttmann: /* Request and Response Handling */

The FullJS application server provides a robust, modular, and secure foundation for running server-side services. It combines modern architectural principles with deep Linux integration to deliver enterprise-grade capabilitie

= Microservice Architecture =
The FullJS applications server follows a microservice-based server architecture with deep systemd integration. The application server is represented as a Systemd target ([application].target), with each individual microservice corresponding to a systemd unit instance ([application]@[microservice]).

== Adding and Removing Microservices from the Application Server ==

To add a microservice (a.k.a systemd unit instance) to the application server (a.k.a systemd target):

<code>
sudo systemctl enable [application]@[microservice]
</code>

To remove a microservice from the application server group:

<code>
sudo systemctl disable [application]@[microservice]
</code>

''Note:'' Enabling a microservice only registers it with the application server for automatic start at boot. It does **not** start the microservice immediately in the current session.

== Starting and Stopping a Microservice ==
Each microservice runs as a separate systemd unit instance ([application]@[microservice]).
To start a microservice:

<code>
sudo systemctl start [application]@[microservice]
</code>

To stop a microservice:

<code>
sudo systemctl stop [application]@[microservice]
</code>

''Note:'' starting a microservice only affects the current session and does not configure it to start automatically at boot.

== Checking the Status of a Microservice ==
Each microservice runs as a separate systemd unit instance (<code>[application]@[microservice]</code>).

* To check the current status of a microservice instance:

<code>
sudo systemctl status [application]@[microservice]
</code>

This command shows whether the service is running, stopped, or failed, along with recent log entries.

== Starting and Stopping the application server ==
To start the application server use systemd’s start command.

<code>
sudo systemctl start [application].target
</code>

To stop a running application server, you can use:

<code>
sudo systemctl stop [application].target
</code>

Keep in mind that starting an application server only affects the current session and does not configure it to start automatically at boot.

== Enabling and Disabling the application server ==
To start the application server automatically at boot, you must enable it.

To start the application server at boot:

<code>sudo systemctl enable [application].target</code>

To disable the application service from starting automatically:

<code>sudo systemctl disable [application].target</code>

Keep in mind that enabling an application server does not start it in the current session.

= Filesystem Layout =
The application conforms to the Linux Filesystem Hierarchy Standard (FHS). Executables, data, runtime state, and configuration are separated cleanly:

* <code>/srv/[application]/[microservice]/</code> – contains the deployed application
* <code>/run/[application]/[microservice]/**</code> – runtime files (e.g., sockets, PID files)
* <code>/var/lib/[application]/[microservice]/**</code> – persistent state data (e.g., storage files)
* <code>/etc/[application]/[microservice]/**</code> – configuration files (if any)

= Plugin-based architecture =

Note: This documentation is not final and may be updated as the architecture evolves.

The plugin-based architecture allows the application server and other modules to be extended and customized by dynamically enabling plugins. Each plugin is a self-contained module and encapsulates a specific functionality, such as HTTP handling, authentication, permission management, systemd integration. This design decouples core module logic from optional features, making it easier to maintain, test, and evolve the system.

'''How it works:'''

# '''Core Server Class''': The main ''Server'' class provides the infrastructure for running the application and managing plugins.
# '''Plugin Registration''': Plugins are registered using the <code>@enable</code> decorator, which associates a plugin class with optional configuration options.
# '''Static Initialization''': The static initialization ensures the server is instantiated immediately upon class definition.

<syntaxhighlight lang="JavaScript">
/* @babel ES2025 */

import { Server, enable } from "appserver";
import { ApplicationServer } from "appserver";
import { HttpServer, http } from "appserver";
import { AuthenticationService, auth } from "appserver";
import { PermissionManager, perm } from "appserver";
import { SystemdIntegration } from "appserver";
import { HAProxyIntegration } from "appserver";
import { ApplicationConsole } from "appserver";

@enable( ApplicationConsole )
@enable( HAProxyIntegration, {port: 8080, endpoint: /^(?!.*\.jss$).*/, slot: "http_slot00"} )
@enable( SystemdIntegration )
@enable( HttpServer, {port: 8080} )
@enable( ApplicationServer )
@enable( AuthenticationService )
@enable( PermissionManager )
class MyServer extends Server {

static {
new this();
}

constructor(...args) {
super(...args);
}

}

</syntaxhighlight>

== Notes ==

# The <code>@enable</code> decorator can be applied multiple times to register different plugins.
# Plugin options can configure ports, endpoints, or internal slots for routing.

= HttpPlugin =

The '''HttpPlugin''' extends the core '''Server''' class with HTTP capabilities.
When this plugin is enabled, the server can listen on a given port and expose REST-like endpoints.

This makes it possible to build fully functional web APIs directly on top of the server, using standard '''Request''' and '''Response''' handling from the Web API specification.

== Decorator-Based Routing ==
Once the '''HttpPlugin''' is enabled, endpoints can be defined directly in the server class using decorators.
Each decorator corresponds to a specific HTTP method.

=== Supported Decorators ===
* '''@http.get(path)''' – Declares a GET endpoint for the given path. Used for fetching resources or data.
* '''@http.post(path)''' – Declares a POST endpoint for the given path. Used for creating new resources or submitting data.
* '''@http.put(path)''' – Declares a PUT endpoint for the given path. Used for updating or replacing an existing resource.
* '''@http.patch(path)''' – Declares a PATCH endpoint for the given path. Used for partially updating an existing resource.
* '''@http.delete(path)''' – Declares a DELETE endpoint for the given path. Used for removing resources.
* '''@http.head(path)''' – Declares a HEAD endpoint for the given path. Similar to GET but returns only headers without the body.
* '''@http.options(path)''' – Declares an OPTIONS endpoint for the given path. Used for describing communication options, often in CORS scenarios.

The path may be a string for an exact match or a RegExp for flexible matching.

== Request and Response Handling ==
The plugin uses standard Web API classes:

* '''Request''' – represents the incoming HTTP request (method, URL, headers, body).
* '''Response''' – represents the outgoing HTTP response (status, headers, body).

Once a request is routed, the method must return a new <code>Response</code> object so that the server can properly send the HTTP response back to the client.
This ensures full compatibility with modern JavaScript patterns for handling HTTP.

<syntaxhighlight lang="javascript">
/* @babel ES2025 */

import { Server, enable } from "appserver";
import { ApplicationServer } from "appserver";
import { HttpServer, http } from "appserver";
import { AuthenticationService, auth } from "appserver";
import { PermissionManager, perm } from "appserver";
import { SystemdIntegration } from "appserver";
import { HAProxyIntegration } from "appserver";
import { ApplicationConsole } from "appserver";

@enable( ApplicationConsole )
@enable( HAProxyIntegration, {port: 8080, endpoint: /^(?!.*\.jss$).*/, slot: "http_slot00"} )
@enable( SystemdIntegration )
@enable( HttpServer, {port: 8080} )
@enable( ApplicationServer )
@enable( AuthenticationService )
@enable( PermissionManager )
class MyServer extends Server {

static {
new this();
}

constructor(...args) {
super(...args);
}

@http.get("/myendpoint")
async handleRequest(request) {
return new Response("Hello world", {
status: 200,
headers: {
"Content-Type": "text/plain"
}
});
}

}

</syntaxhighlight>

Application Server

2025-09-22T05:37:29Z

Guttmann: /* Notes */

The FullJS application server provides a robust, modular, and secure foundation for running server-side services. It combines modern architectural principles with deep Linux integration to deliver enterprise-grade capabilitie

= Microservice Architecture =
The FullJS applications server follows a microservice-based server architecture with deep systemd integration. The application server is represented as a Systemd target ([application].target), with each individual microservice corresponding to a systemd unit instance ([application]@[microservice]).

== Adding and Removing Microservices from the Application Server ==

To add a microservice (a.k.a systemd unit instance) to the application server (a.k.a systemd target):

<code>
sudo systemctl enable [application]@[microservice]
</code>

To remove a microservice from the application server group:

<code>
sudo systemctl disable [application]@[microservice]
</code>

''Note:'' Enabling a microservice only registers it with the application server for automatic start at boot. It does **not** start the microservice immediately in the current session.

== Starting and Stopping a Microservice ==
Each microservice runs as a separate systemd unit instance ([application]@[microservice]).
To start a microservice:

<code>
sudo systemctl start [application]@[microservice]
</code>

To stop a microservice:

<code>
sudo systemctl stop [application]@[microservice]
</code>

''Note:'' starting a microservice only affects the current session and does not configure it to start automatically at boot.

== Checking the Status of a Microservice ==
Each microservice runs as a separate systemd unit instance (<code>[application]@[microservice]</code>).

* To check the current status of a microservice instance:

<code>
sudo systemctl status [application]@[microservice]
</code>

This command shows whether the service is running, stopped, or failed, along with recent log entries.

== Starting and Stopping the application server ==
To start the application server use systemd’s start command.

<code>
sudo systemctl start [application].target
</code>

To stop a running application server, you can use:

<code>
sudo systemctl stop [application].target
</code>

Keep in mind that starting an application server only affects the current session and does not configure it to start automatically at boot.

== Enabling and Disabling the application server ==
To start the application server automatically at boot, you must enable it.

To start the application server at boot:

<code>sudo systemctl enable [application].target</code>

To disable the application service from starting automatically:

<code>sudo systemctl disable [application].target</code>

Keep in mind that enabling an application server does not start it in the current session.

= Filesystem Layout =
The application conforms to the Linux Filesystem Hierarchy Standard (FHS). Executables, data, runtime state, and configuration are separated cleanly:

* <code>/srv/[application]/[microservice]/</code> – contains the deployed application
* <code>/run/[application]/[microservice]/**</code> – runtime files (e.g., sockets, PID files)
* <code>/var/lib/[application]/[microservice]/**</code> – persistent state data (e.g., storage files)
* <code>/etc/[application]/[microservice]/**</code> – configuration files (if any)

= Plugin-based architecture =

Note: This documentation is not final and may be updated as the architecture evolves.

The plugin-based architecture allows the application server and other modules to be extended and customized by dynamically enabling plugins. Each plugin is a self-contained module and encapsulates a specific functionality, such as HTTP handling, authentication, permission management, systemd integration. This design decouples core module logic from optional features, making it easier to maintain, test, and evolve the system.

'''How it works:'''

# '''Core Server Class''': The main ''Server'' class provides the infrastructure for running the application and managing plugins.
# '''Plugin Registration''': Plugins are registered using the <code>@enable</code> decorator, which associates a plugin class with optional configuration options.
# '''Static Initialization''': The static initialization ensures the server is instantiated immediately upon class definition.

<syntaxhighlight lang="JavaScript">
/* @babel ES2025 */

import { Server, enable } from "appserver";
import { ApplicationServer } from "appserver";
import { HttpServer, http } from "appserver";
import { AuthenticationService, auth } from "appserver";
import { PermissionManager, perm } from "appserver";
import { SystemdIntegration } from "appserver";
import { HAProxyIntegration } from "appserver";
import { ApplicationConsole } from "appserver";

@enable( ApplicationConsole )
@enable( HAProxyIntegration, {port: 8080, endpoint: /^(?!.*\.jss$).*/, slot: "http_slot00"} )
@enable( SystemdIntegration )
@enable( HttpServer, {port: 8080} )
@enable( ApplicationServer )
@enable( AuthenticationService )
@enable( PermissionManager )
class MyServer extends Server {

static {
new this();
}

constructor(...args) {
super(...args);
}

}

</syntaxhighlight>

== Notes ==

# The <code>@enable</code> decorator can be applied multiple times to register different plugins.
# Plugin options can configure ports, endpoints, or internal slots for routing.

= HttpPlugin =

The '''HttpPlugin''' extends the core '''Server''' class with HTTP capabilities.
When this plugin is enabled, the server can listen on a given port and expose REST-like endpoints.

This makes it possible to build fully functional web APIs directly on top of the server, using standard '''Request''' and '''Response''' handling from the Web API specification.

== Decorator-Based Routing ==
Once the '''HttpPlugin''' is enabled, endpoints can be defined directly in the server class using decorators.
Each decorator corresponds to a specific HTTP method.

=== Supported Decorators ===
* '''@http.get(path)''' – Declares a GET endpoint for the given path. Used for fetching resources or data.
* '''@http.post(path)''' – Declares a POST endpoint for the given path. Used for creating new resources or submitting data.
* '''@http.put(path)''' – Declares a PUT endpoint for the given path. Used for updating or replacing an existing resource.
* '''@http.patch(path)''' – Declares a PATCH endpoint for the given path. Used for partially updating an existing resource.
* '''@http.delete(path)''' – Declares a DELETE endpoint for the given path. Used for removing resources.
* '''@http.head(path)''' – Declares a HEAD endpoint for the given path. Similar to GET but returns only headers without the body.
* '''@http.options(path)''' – Declares an OPTIONS endpoint for the given path. Used for describing communication options, often in CORS scenarios.

The path may be a string for an exact match or a RegExp for flexible matching.

== Request and Response Handling ==
The plugin uses standard Web API classes:

* '''Request''' – represents the incoming HTTP request (method, URL, headers, body).
* '''Response''' – represents the outgoing HTTP response (status, headers, body).

Once a request is routed, the method must return a new <code>Response</code> object so that the server can properly send the HTTP response back to the client.
This ensures full compatibility with modern JavaScript patterns for handling HTTP.

<syntaxhighlight lang="javascript">
/* @babel ES2025 */

import {Server, use} from "appserver";
import {AppServerPlugin} from "appserver";
import {SystemdPlugin} from "appserver";
import {HttpPlugin, http} from "appserver";
import {AuthPlugin, auth} from "appserver";
import {PermPlugin, perm} from "appserver";
import {DebugConsolePlugin} from "appserver";
import {HAProxyPlugin} from "appserver";

@use( DebugConsolePlugin )
@use( HAProxyPlugin, {port: 8080, endpoint: /^(?!.*\.jss$).*/, slot: "http_slot00"} )
@use( SystemdPlugin )
@use( HttpPlugin, {port: 8080} )
@use( AppServerPlugin )
@use( AuthPlugin )
@use( PermPlugin )
class MyServer extends Server {

static {
new this();
}

constructor(...args) {
super(...args);
}

@http.get("/myendpoint")
async handleRequest(request) {
return new Response("Hello world", {
status: 200,
headers: {
"Content-Type": "text/plain"
}
});
}

}

</syntaxhighlight>

Application Server

2025-09-22T05:37:10Z

Guttmann: /* Plugin-based architecture */

The FullJS application server provides a robust, modular, and secure foundation for running server-side services. It combines modern architectural principles with deep Linux integration to deliver enterprise-grade capabilitie

= Microservice Architecture =
The FullJS applications server follows a microservice-based server architecture with deep systemd integration. The application server is represented as a Systemd target ([application].target), with each individual microservice corresponding to a systemd unit instance ([application]@[microservice]).

== Adding and Removing Microservices from the Application Server ==

To add a microservice (a.k.a systemd unit instance) to the application server (a.k.a systemd target):

<code>
sudo systemctl enable [application]@[microservice]
</code>

To remove a microservice from the application server group:

<code>
sudo systemctl disable [application]@[microservice]
</code>

''Note:'' Enabling a microservice only registers it with the application server for automatic start at boot. It does **not** start the microservice immediately in the current session.

== Starting and Stopping a Microservice ==
Each microservice runs as a separate systemd unit instance ([application]@[microservice]).
To start a microservice:

<code>
sudo systemctl start [application]@[microservice]
</code>

To stop a microservice:

<code>
sudo systemctl stop [application]@[microservice]
</code>

''Note:'' starting a microservice only affects the current session and does not configure it to start automatically at boot.

== Checking the Status of a Microservice ==
Each microservice runs as a separate systemd unit instance (<code>[application]@[microservice]</code>).

* To check the current status of a microservice instance:

<code>
sudo systemctl status [application]@[microservice]
</code>

This command shows whether the service is running, stopped, or failed, along with recent log entries.

== Starting and Stopping the application server ==
To start the application server use systemd’s start command.

<code>
sudo systemctl start [application].target
</code>

To stop a running application server, you can use:

<code>
sudo systemctl stop [application].target
</code>

Keep in mind that starting an application server only affects the current session and does not configure it to start automatically at boot.

== Enabling and Disabling the application server ==
To start the application server automatically at boot, you must enable it.

To start the application server at boot:

<code>sudo systemctl enable [application].target</code>

To disable the application service from starting automatically:

<code>sudo systemctl disable [application].target</code>

Keep in mind that enabling an application server does not start it in the current session.

= Filesystem Layout =
The application conforms to the Linux Filesystem Hierarchy Standard (FHS). Executables, data, runtime state, and configuration are separated cleanly:

* <code>/srv/[application]/[microservice]/</code> – contains the deployed application
* <code>/run/[application]/[microservice]/**</code> – runtime files (e.g., sockets, PID files)
* <code>/var/lib/[application]/[microservice]/**</code> – persistent state data (e.g., storage files)
* <code>/etc/[application]/[microservice]/**</code> – configuration files (if any)

= Plugin-based architecture =

Note: This documentation is not final and may be updated as the architecture evolves.

The plugin-based architecture allows the application server and other modules to be extended and customized by dynamically enabling plugins. Each plugin is a self-contained module and encapsulates a specific functionality, such as HTTP handling, authentication, permission management, systemd integration. This design decouples core module logic from optional features, making it easier to maintain, test, and evolve the system.

'''How it works:'''

# '''Core Server Class''': The main ''Server'' class provides the infrastructure for running the application and managing plugins.
# '''Plugin Registration''': Plugins are registered using the <code>@enable</code> decorator, which associates a plugin class with optional configuration options.
# '''Static Initialization''': The static initialization ensures the server is instantiated immediately upon class definition.

<syntaxhighlight lang="JavaScript">
/* @babel ES2025 */

import { Server, enable } from "appserver";
import { ApplicationServer } from "appserver";
import { HttpServer, http } from "appserver";
import { AuthenticationService, auth } from "appserver";
import { PermissionManager, perm } from "appserver";
import { SystemdIntegration } from "appserver";
import { HAProxyIntegration } from "appserver";
import { ApplicationConsole } from "appserver";

@enable( ApplicationConsole )
@enable( HAProxyIntegration, {port: 8080, endpoint: /^(?!.*\.jss$).*/, slot: "http_slot00"} )
@enable( SystemdIntegration )
@enable( HttpServer, {port: 8080} )
@enable( ApplicationServer )
@enable( AuthenticationService )
@enable( PermissionManager )
class MyServer extends Server {

static {
new this();
}

constructor(...args) {
super(...args);
}

}

</syntaxhighlight>

== Notes ==

# The <code>@use</code> decorator can be applied multiple times to register different plugins.
# Plugin options can configure ports, endpoints, or internal slots for routing.

= HttpPlugin =

The '''HttpPlugin''' extends the core '''Server''' class with HTTP capabilities.
When this plugin is enabled, the server can listen on a given port and expose REST-like endpoints.

This makes it possible to build fully functional web APIs directly on top of the server, using standard '''Request''' and '''Response''' handling from the Web API specification.

== Decorator-Based Routing ==
Once the '''HttpPlugin''' is enabled, endpoints can be defined directly in the server class using decorators.
Each decorator corresponds to a specific HTTP method.

=== Supported Decorators ===
* '''@http.get(path)''' – Declares a GET endpoint for the given path. Used for fetching resources or data.
* '''@http.post(path)''' – Declares a POST endpoint for the given path. Used for creating new resources or submitting data.
* '''@http.put(path)''' – Declares a PUT endpoint for the given path. Used for updating or replacing an existing resource.
* '''@http.patch(path)''' – Declares a PATCH endpoint for the given path. Used for partially updating an existing resource.
* '''@http.delete(path)''' – Declares a DELETE endpoint for the given path. Used for removing resources.
* '''@http.head(path)''' – Declares a HEAD endpoint for the given path. Similar to GET but returns only headers without the body.
* '''@http.options(path)''' – Declares an OPTIONS endpoint for the given path. Used for describing communication options, often in CORS scenarios.

The path may be a string for an exact match or a RegExp for flexible matching.

== Request and Response Handling ==
The plugin uses standard Web API classes:

* '''Request''' – represents the incoming HTTP request (method, URL, headers, body).
* '''Response''' – represents the outgoing HTTP response (status, headers, body).

Once a request is routed, the method must return a new <code>Response</code> object so that the server can properly send the HTTP response back to the client.
This ensures full compatibility with modern JavaScript patterns for handling HTTP.

<syntaxhighlight lang="javascript">
/* @babel ES2025 */

import {Server, use} from "appserver";
import {AppServerPlugin} from "appserver";
import {SystemdPlugin} from "appserver";
import {HttpPlugin, http} from "appserver";
import {AuthPlugin, auth} from "appserver";
import {PermPlugin, perm} from "appserver";
import {DebugConsolePlugin} from "appserver";
import {HAProxyPlugin} from "appserver";

@use( DebugConsolePlugin )
@use( HAProxyPlugin, {port: 8080, endpoint: /^(?!.*\.jss$).*/, slot: "http_slot00"} )
@use( SystemdPlugin )
@use( HttpPlugin, {port: 8080} )
@use( AppServerPlugin )
@use( AuthPlugin )
@use( PermPlugin )
class MyServer extends Server {

static {
new this();
}

constructor(...args) {
super(...args);
}

@http.get("/myendpoint")
async handleRequest(request) {
return new Response("Hello world", {
status: 200,
headers: {
"Content-Type": "text/plain"
}
});
}

}

</syntaxhighlight>

Application Server

2025-09-19T16:36:07Z

Guttmann: /* Supported Decorators */

The FullJS application server provides a robust, modular, and secure foundation for running server-side services. It combines modern architectural principles with deep Linux integration to deliver enterprise-grade capabilitie

= Microservice Architecture =
The FullJS applications server follows a microservice-based server architecture with deep systemd integration. The application server is represented as a Systemd target ([application].target), with each individual microservice corresponding to a systemd unit instance ([application]@[microservice]).

== Adding and Removing Microservices from the Application Server ==

To add a microservice (a.k.a systemd unit instance) to the application server (a.k.a systemd target):

<code>
sudo systemctl enable [application]@[microservice]
</code>

To remove a microservice from the application server group:

<code>
sudo systemctl disable [application]@[microservice]
</code>

''Note:'' Enabling a microservice only registers it with the application server for automatic start at boot. It does **not** start the microservice immediately in the current session.

== Starting and Stopping a Microservice ==
Each microservice runs as a separate systemd unit instance ([application]@[microservice]).
To start a microservice:

<code>
sudo systemctl start [application]@[microservice]
</code>

To stop a microservice:

<code>
sudo systemctl stop [application]@[microservice]
</code>

''Note:'' starting a microservice only affects the current session and does not configure it to start automatically at boot.

== Checking the Status of a Microservice ==
Each microservice runs as a separate systemd unit instance (<code>[application]@[microservice]</code>).

* To check the current status of a microservice instance:

<code>
sudo systemctl status [application]@[microservice]
</code>

This command shows whether the service is running, stopped, or failed, along with recent log entries.

== Starting and Stopping the application server ==
To start the application server use systemd’s start command.

<code>
sudo systemctl start [application].target
</code>

To stop a running application server, you can use:

<code>
sudo systemctl stop [application].target
</code>

Keep in mind that starting an application server only affects the current session and does not configure it to start automatically at boot.

== Enabling and Disabling the application server ==
To start the application server automatically at boot, you must enable it.

To start the application server at boot:

<code>sudo systemctl enable [application].target</code>

To disable the application service from starting automatically:

<code>sudo systemctl disable [application].target</code>

Keep in mind that enabling an application server does not start it in the current session.

= Filesystem Layout =
The application conforms to the Linux Filesystem Hierarchy Standard (FHS). Executables, data, runtime state, and configuration are separated cleanly:

* <code>/srv/[application]/[microservice]/</code> – contains the deployed application
* <code>/run/[application]/[microservice]/**</code> – runtime files (e.g., sockets, PID files)
* <code>/var/lib/[application]/[microservice]/**</code> – persistent state data (e.g., storage files)
* <code>/etc/[application]/[microservice]/**</code> – configuration files (if any)

= Plugin-based architecture =

Note: This documentation is not final and may be updated as the architecture evolves.

The plugin-based architecture allows the application server and other modules to be extended and customized by dynamically enabling plugins. Each plugin is a self-contained module and encapsulates a specific functionality, such as HTTP handling, authentication, permission management, systemd integration. This design decouples core module logic from optional features, making it easier to maintain, test, and evolve the system.

'''How it works:'''

# '''Core Server Class''': The main ''Server'' class provides the infrastructure for running the application and managing plugins.
# '''Plugin Registration''': Plugins are registered using the <code>@use</code> decorator, which associates a plugin class with optional configuration options.
# '''Static Initialization''': The static initialization ensures the server is instantiated immediately upon class definition.

<syntaxhighlight lang="JavaScript">
/* @babel ES2025 */

import {Server, use} from "appserver";
import {AppServerPlugin} from "appserver";
import {SystemdPlugin} from "appserver";
import {HttpPlugin, http} from "appserver";
import {AuthPlugin, auth} from "appserver";
import {PermPlugin, perm} from "appserver";
import {DebugConsolePlugin} from "appserver";
import {HAProxyPlugin} from "appserver";

@use( DebugConsolePlugin )
@use( HAProxyPlugin, {port: 8080, endpoint: /^(?!.*\.jss$).*/, slot: "http_slot00"} )
@use( SystemdPlugin )
@use( HttpPlugin, {port: 8080} )
@use( AppServerPlugin )
@use( AuthPlugin )
@use( PermPlugin )
class MyServer extends Server {

static {
new this();
}

constructor(...args) {
super(...args);
}

}

</syntaxhighlight>

== Notes ==

# The <code>@use</code> decorator can be applied multiple times to register different plugins.
# Plugin options can configure ports, endpoints, or internal slots for routing.

= HttpPlugin =

The '''HttpPlugin''' extends the core '''Server''' class with HTTP capabilities.
When this plugin is enabled, the server can listen on a given port and expose REST-like endpoints.

This makes it possible to build fully functional web APIs directly on top of the server, using standard '''Request''' and '''Response''' handling from the Web API specification.

== Decorator-Based Routing ==
Once the '''HttpPlugin''' is enabled, endpoints can be defined directly in the server class using decorators.
Each decorator corresponds to a specific HTTP method.

=== Supported Decorators ===
* '''@http.get(path)''' – Declares a GET endpoint for the given path. Used for fetching resources or data.
* '''@http.post(path)''' – Declares a POST endpoint for the given path. Used for creating new resources or submitting data.
* '''@http.put(path)''' – Declares a PUT endpoint for the given path. Used for updating or replacing an existing resource.
* '''@http.patch(path)''' – Declares a PATCH endpoint for the given path. Used for partially updating an existing resource.
* '''@http.delete(path)''' – Declares a DELETE endpoint for the given path. Used for removing resources.
* '''@http.head(path)''' – Declares a HEAD endpoint for the given path. Similar to GET but returns only headers without the body.
* '''@http.options(path)''' – Declares an OPTIONS endpoint for the given path. Used for describing communication options, often in CORS scenarios.

The path may be a string for an exact match or a RegExp for flexible matching.

== Request and Response Handling ==
The plugin uses standard Web API classes:

* '''Request''' – represents the incoming HTTP request (method, URL, headers, body).
* '''Response''' – represents the outgoing HTTP response (status, headers, body).

Once a request is routed, the method must return a new <code>Response</code> object so that the server can properly send the HTTP response back to the client.
This ensures full compatibility with modern JavaScript patterns for handling HTTP.

<syntaxhighlight lang="javascript">
/* @babel ES2025 */

import {Server, use} from "appserver";
import {AppServerPlugin} from "appserver";
import {SystemdPlugin} from "appserver";
import {HttpPlugin, http} from "appserver";
import {AuthPlugin, auth} from "appserver";
import {PermPlugin, perm} from "appserver";
import {DebugConsolePlugin} from "appserver";
import {HAProxyPlugin} from "appserver";

@use( DebugConsolePlugin )
@use( HAProxyPlugin, {port: 8080, endpoint: /^(?!.*\.jss$).*/, slot: "http_slot00"} )
@use( SystemdPlugin )
@use( HttpPlugin, {port: 8080} )
@use( AppServerPlugin )
@use( AuthPlugin )
@use( PermPlugin )
class MyServer extends Server {

static {
new this();
}

constructor(...args) {
super(...args);
}

@http.get("/myendpoint")
async handleRequest(request) {
return new Response("Hello world", {
status: 200,
headers: {
"Content-Type": "text/plain"
}
});
}

}

</syntaxhighlight>

Application Server

2025-09-19T16:30:26Z

Guttmann:

The FullJS application server provides a robust, modular, and secure foundation for running server-side services. It combines modern architectural principles with deep Linux integration to deliver enterprise-grade capabilitie

= Microservice Architecture =
The FullJS applications server follows a microservice-based server architecture with deep systemd integration. The application server is represented as a Systemd target ([application].target), with each individual microservice corresponding to a systemd unit instance ([application]@[microservice]).

== Adding and Removing Microservices from the Application Server ==

To add a microservice (a.k.a systemd unit instance) to the application server (a.k.a systemd target):

<code>
sudo systemctl enable [application]@[microservice]
</code>

To remove a microservice from the application server group:

<code>
sudo systemctl disable [application]@[microservice]
</code>

''Note:'' Enabling a microservice only registers it with the application server for automatic start at boot. It does **not** start the microservice immediately in the current session.

== Starting and Stopping a Microservice ==
Each microservice runs as a separate systemd unit instance ([application]@[microservice]).
To start a microservice:

<code>
sudo systemctl start [application]@[microservice]
</code>

To stop a microservice:

<code>
sudo systemctl stop [application]@[microservice]
</code>

''Note:'' starting a microservice only affects the current session and does not configure it to start automatically at boot.

== Checking the Status of a Microservice ==
Each microservice runs as a separate systemd unit instance (<code>[application]@[microservice]</code>).

* To check the current status of a microservice instance:

<code>
sudo systemctl status [application]@[microservice]
</code>

This command shows whether the service is running, stopped, or failed, along with recent log entries.

== Starting and Stopping the application server ==
To start the application server use systemd’s start command.

<code>
sudo systemctl start [application].target
</code>

To stop a running application server, you can use:

<code>
sudo systemctl stop [application].target
</code>

Keep in mind that starting an application server only affects the current session and does not configure it to start automatically at boot.

== Enabling and Disabling the application server ==
To start the application server automatically at boot, you must enable it.

To start the application server at boot:

<code>sudo systemctl enable [application].target</code>

To disable the application service from starting automatically:

<code>sudo systemctl disable [application].target</code>

Keep in mind that enabling an application server does not start it in the current session.

= Filesystem Layout =
The application conforms to the Linux Filesystem Hierarchy Standard (FHS). Executables, data, runtime state, and configuration are separated cleanly:

* <code>/srv/[application]/[microservice]/</code> – contains the deployed application
* <code>/run/[application]/[microservice]/**</code> – runtime files (e.g., sockets, PID files)
* <code>/var/lib/[application]/[microservice]/**</code> – persistent state data (e.g., storage files)
* <code>/etc/[application]/[microservice]/**</code> – configuration files (if any)

= Plugin-based architecture =

Note: This documentation is not final and may be updated as the architecture evolves.

The plugin-based architecture allows the application server and other modules to be extended and customized by dynamically enabling plugins. Each plugin is a self-contained module and encapsulates a specific functionality, such as HTTP handling, authentication, permission management, systemd integration. This design decouples core module logic from optional features, making it easier to maintain, test, and evolve the system.

'''How it works:'''

# '''Core Server Class''': The main ''Server'' class provides the infrastructure for running the application and managing plugins.
# '''Plugin Registration''': Plugins are registered using the <code>@use</code> decorator, which associates a plugin class with optional configuration options.
# '''Static Initialization''': The static initialization ensures the server is instantiated immediately upon class definition.

<syntaxhighlight lang="JavaScript">
/* @babel ES2025 */

import {Server, use} from "appserver";
import {AppServerPlugin} from "appserver";
import {SystemdPlugin} from "appserver";
import {HttpPlugin, http} from "appserver";
import {AuthPlugin, auth} from "appserver";
import {PermPlugin, perm} from "appserver";
import {DebugConsolePlugin} from "appserver";
import {HAProxyPlugin} from "appserver";

@use( DebugConsolePlugin )
@use( HAProxyPlugin, {port: 8080, endpoint: /^(?!.*\.jss$).*/, slot: "http_slot00"} )
@use( SystemdPlugin )
@use( HttpPlugin, {port: 8080} )
@use( AppServerPlugin )
@use( AuthPlugin )
@use( PermPlugin )
class MyServer extends Server {

static {
new this();
}

constructor(...args) {
super(...args);
}

}

</syntaxhighlight>

== Notes ==

# The <code>@use</code> decorator can be applied multiple times to register different plugins.
# Plugin options can configure ports, endpoints, or internal slots for routing.

= HttpPlugin =

The '''HttpPlugin''' extends the core '''Server''' class with HTTP capabilities.
When this plugin is enabled, the server can listen on a given port and expose REST-like endpoints.

This makes it possible to build fully functional web APIs directly on top of the server, using standard '''Request''' and '''Response''' handling from the Web API specification.

== Decorator-Based Routing ==
Once the '''HttpPlugin''' is enabled, endpoints can be defined directly in the server class using decorators.
Each decorator corresponds to a specific HTTP method.

=== Supported Decorators ===
* '''@http.get(path)''' – Declares a GET endpoint for the given path. Used for fetching resources or data.
* '''@http.post(path)''' – Declares a POST endpoint for the given path. Used for creating new resources or submitting data.
* '''@http.put(path)''' – Declares a PUT endpoint for the given path. Used for updating or replacing an existing resource.
* '''@http.patch(path)''' – Declares a PATCH endpoint for the given path. Used for partially updating an existing resource.
* '''@http.delete(path)''' – Declares a DELETE endpoint for the given path. Used for removing resources.
* '''@http.head(path)''' – Declares a HEAD endpoint for the given path. Similar to GET but returns only headers without the body.
* '''@http.options(path)''' – Declares an OPTIONS endpoint for the given path. Used for describing communication options, often in CORS scenarios.

== Request and Response Handling ==
The plugin uses standard Web API classes:

* '''Request''' – represents the incoming HTTP request (method, URL, headers, body).
* '''Response''' – represents the outgoing HTTP response (status, headers, body).

Once a request is routed, the method must return a new <code>Response</code> object so that the server can properly send the HTTP response back to the client.
This ensures full compatibility with modern JavaScript patterns for handling HTTP.

<syntaxhighlight lang="javascript">
/* @babel ES2025 */

import {Server, use} from "appserver";
import {AppServerPlugin} from "appserver";
import {SystemdPlugin} from "appserver";
import {HttpPlugin, http} from "appserver";
import {AuthPlugin, auth} from "appserver";
import {PermPlugin, perm} from "appserver";
import {DebugConsolePlugin} from "appserver";
import {HAProxyPlugin} from "appserver";

@use( DebugConsolePlugin )
@use( HAProxyPlugin, {port: 8080, endpoint: /^(?!.*\.jss$).*/, slot: "http_slot00"} )
@use( SystemdPlugin )
@use( HttpPlugin, {port: 8080} )
@use( AppServerPlugin )
@use( AuthPlugin )
@use( PermPlugin )
class MyServer extends Server {

static {
new this();
}

constructor(...args) {
super(...args);
}

@http.get("/myendpoint")
async handleRequest(request) {
return new Response("Hello world", {
status: 200,
headers: {
"Content-Type": "text/plain"
}
});
}

}

</syntaxhighlight>

Application Server

2025-09-19T16:24:52Z

Guttmann: /* Example */

The FullJS application server provides a robust, modular, and secure foundation for running server-side services. It combines modern architectural principles with deep Linux integration to deliver enterprise-grade capabilitie

= Microservice Architecture =
The FullJS applications server follows a microservice-based server architecture with deep systemd integration. The application server is represented as a Systemd target ([application].target), with each individual microservice corresponding to a systemd unit instance ([application]@[microservice]).

== Adding and Removing Microservices from the Application Server ==

To add a microservice (a.k.a systemd unit instance) to the application server (a.k.a systemd target):

<code>
sudo systemctl enable [application]@[microservice]
</code>

To remove a microservice from the application server group:

<code>
sudo systemctl disable [application]@[microservice]
</code>

''Note:'' Enabling a microservice only registers it with the application server for automatic start at boot. It does **not** start the microservice immediately in the current session.

== Starting and Stopping a Microservice ==
Each microservice runs as a separate systemd unit instance ([application]@[microservice]).
To start a microservice:

<code>
sudo systemctl start [application]@[microservice]
</code>

To stop a microservice:

<code>
sudo systemctl stop [application]@[microservice]
</code>

''Note:'' starting a microservice only affects the current session and does not configure it to start automatically at boot.

== Checking the Status of a Microservice ==
Each microservice runs as a separate systemd unit instance (<code>[application]@[microservice]</code>).

* To check the current status of a microservice instance:

<code>
sudo systemctl status [application]@[microservice]
</code>

This command shows whether the service is running, stopped, or failed, along with recent log entries.

== Starting and Stopping the application server ==
To start the application server use systemd’s start command.

<code>
sudo systemctl start [application].target
</code>

To stop a running application server, you can use:

<code>
sudo systemctl stop [application].target
</code>

Keep in mind that starting an application server only affects the current session and does not configure it to start automatically at boot.

== Enabling and Disabling the application server ==
To start the application server automatically at boot, you must enable it.

To start the application server at boot:

<code>sudo systemctl enable [application].target</code>

To disable the application service from starting automatically:

<code>sudo systemctl disable [application].target</code>

Keep in mind that enabling an application server does not start it in the current session.

= Filesystem Layout =
The application conforms to the Linux Filesystem Hierarchy Standard (FHS). Executables, data, runtime state, and configuration are separated cleanly:

* <code>/srv/[application]/[microservice]/</code> – contains the deployed application
* <code>/run/[application]/[microservice]/**</code> – runtime files (e.g., sockets, PID files)
* <code>/var/lib/[application]/[microservice]/**</code> – persistent state data (e.g., storage files)
* <code>/etc/[application]/[microservice]/**</code> – configuration files (if any)

= Plugin-based architecture =

Note: This documentation is not final and may be updated as the architecture evolves.

The plugin-based architecture allows the application server and other modules to be extended and customized by dynamically enabling plugins. Each plugin is a self-contained module and encapsulates a specific functionality, such as HTTP handling, authentication, permission management, systemd integration. This design decouples core module logic from optional features, making it easier to maintain, test, and evolve the system.

'''How it works:'''

# '''Core Server Class''': The main ''Server'' class provides the infrastructure for running the application and managing plugins.
# '''Plugin Registration''': Plugins are registered using the <code>@use</code> decorator, which associates a plugin class with optional configuration options.
# '''Static Initialization''': The static initialization ensures the server is instantiated immediately upon class definition.

<syntaxhighlight lang="JavaScript">
/* @babel ES2025 */

import {Server, use} from "appserver";
import {AppServerPlugin} from "appserver";
import {SystemdPlugin} from "appserver";
import {HttpPlugin, http} from "appserver";
import {AuthPlugin, auth} from "appserver";
import {PermPlugin, perm} from "appserver";
import {DebugConsolePlugin} from "appserver";
import {HAProxyPlugin} from "appserver";

@use( DebugConsolePlugin )
@use( HAProxyPlugin, {port: 8080, endpoint: /^(?!.*\.jss$).*/, slot: "http_slot00"} )
@use( SystemdPlugin )
@use( HttpPlugin, {port: 8080} )
@use( AppServerPlugin )
@use( AuthPlugin )
@use( PermPlugin )
class MyServer extends Server {

static {
new this();
}

constructor(...args) {
super(...args);
}

}

</syntaxhighlight>

== Notes ==

# The <code>@use</code> decorator can be applied multiple times to register different plugins.
# Plugin options can configure ports, endpoints, or internal slots for routing.

= HttpPlugin =

The '''HttpPlugin''' extends the core '''Server''' class with HTTP capabilities.
When this plugin is enabled, the server can listen on a given port and expose REST-like endpoints.

This makes it possible to build fully functional web APIs directly on top of the server, using standard '''Request''' and '''Response''' handling from the Web API specification.

== Decorator-Based Routing ==
Once the '''HttpPlugin''' is enabled, endpoints can be defined directly in the server class using decorators.
Each decorator corresponds to a specific HTTP method.

=== Supported Decorators ===
* '''@http.get(path)''' – Declares a GET endpoint for the given path. Used for fetching resources or data.
* '''@http.post(path)''' – Declares a POST endpoint for the given path. Used for creating new resources or submitting data.
* '''@http.put(path)''' – Declares a PUT endpoint for the given path. Used for updating or replacing an existing resource.
* '''@http.patch(path)''' – Declares a PATCH endpoint for the given path. Used for partially updating an existing resource.
* '''@http.delete(path)''' – Declares a DELETE endpoint for the given path. Used for removing resources.
* '''@http.head(path)''' – Declares a HEAD endpoint for the given path. Similar to GET but returns only headers without the body.
* '''@http.options(path)''' – Declares an OPTIONS endpoint for the given path. Used for describing communication options, often in CORS scenarios.

== Request and Response Handling ==
The plugin uses standard Web API classes:

* '''Request''' – represents the incoming HTTP request (method, URL, headers, body).
* '''Response''' – represents the outgoing HTTP response (status, headers, body).

This ensures full compatibility with modern JavaScript patterns for handling HTTP.

== Example ==
<syntaxhighlight lang="javascript">
/* @babel ES2025 */

import {Server, use} from "appserver";
import {AppServerPlugin} from "appserver";
import {SystemdPlugin} from "appserver";
import {HttpPlugin, http} from "appserver";
import {AuthPlugin, auth} from "appserver";
import {PermPlugin, perm} from "appserver";
import {DebugConsolePlugin} from "appserver";
import {HAProxyPlugin} from "appserver";

@use( DebugConsolePlugin )
@use( HAProxyPlugin, {port: 8080, endpoint: /^(?!.*\.jss$).*/, slot: "http_slot00"} )
@use( SystemdPlugin )
@use( HttpPlugin, {port: 8080} )
@use( AppServerPlugin )
@use( AuthPlugin )
@use( PermPlugin )
class MyServer extends Server {

static {
new this();
}

constructor(...args) {
super(...args);
}

@http.get("/myendpoint")
async handleRequest(request) {
return new Response("Hello world", {
status: 200,
headers: {
"Content-Type": "text/plain"
}
});
}

}

</syntaxhighlight>

Application Server

2025-09-19T16:19:54Z

Guttmann: /* Plugin-based architecture */

The FullJS application server provides a robust, modular, and secure foundation for running server-side services. It combines modern architectural principles with deep Linux integration to deliver enterprise-grade capabilitie

= Microservice Architecture =
The FullJS applications server follows a microservice-based server architecture with deep systemd integration. The application server is represented as a Systemd target ([application].target), with each individual microservice corresponding to a systemd unit instance ([application]@[microservice]).

== Adding and Removing Microservices from the Application Server ==

To add a microservice (a.k.a systemd unit instance) to the application server (a.k.a systemd target):

<code>
sudo systemctl enable [application]@[microservice]
</code>

To remove a microservice from the application server group:

<code>
sudo systemctl disable [application]@[microservice]
</code>

''Note:'' Enabling a microservice only registers it with the application server for automatic start at boot. It does **not** start the microservice immediately in the current session.

== Starting and Stopping a Microservice ==
Each microservice runs as a separate systemd unit instance ([application]@[microservice]).
To start a microservice:

<code>
sudo systemctl start [application]@[microservice]
</code>

To stop a microservice:

<code>
sudo systemctl stop [application]@[microservice]
</code>

''Note:'' starting a microservice only affects the current session and does not configure it to start automatically at boot.

== Checking the Status of a Microservice ==
Each microservice runs as a separate systemd unit instance (<code>[application]@[microservice]</code>).

* To check the current status of a microservice instance:

<code>
sudo systemctl status [application]@[microservice]
</code>

This command shows whether the service is running, stopped, or failed, along with recent log entries.

== Starting and Stopping the application server ==
To start the application server use systemd’s start command.

<code>
sudo systemctl start [application].target
</code>

To stop a running application server, you can use:

<code>
sudo systemctl stop [application].target
</code>

Keep in mind that starting an application server only affects the current session and does not configure it to start automatically at boot.

== Enabling and Disabling the application server ==
To start the application server automatically at boot, you must enable it.

To start the application server at boot:

<code>sudo systemctl enable [application].target</code>

To disable the application service from starting automatically:

<code>sudo systemctl disable [application].target</code>

Keep in mind that enabling an application server does not start it in the current session.

= Filesystem Layout =
The application conforms to the Linux Filesystem Hierarchy Standard (FHS). Executables, data, runtime state, and configuration are separated cleanly:

* <code>/srv/[application]/[microservice]/</code> – contains the deployed application
* <code>/run/[application]/[microservice]/**</code> – runtime files (e.g., sockets, PID files)
* <code>/var/lib/[application]/[microservice]/**</code> – persistent state data (e.g., storage files)
* <code>/etc/[application]/[microservice]/**</code> – configuration files (if any)

= Plugin-based architecture =

Note: This documentation is not final and may be updated as the architecture evolves.

The plugin-based architecture allows the application server and other modules to be extended and customized by dynamically enabling plugins. Each plugin is a self-contained module and encapsulates a specific functionality, such as HTTP handling, authentication, permission management, systemd integration. This design decouples core module logic from optional features, making it easier to maintain, test, and evolve the system.

'''How it works:'''

# '''Core Server Class''': The main ''Server'' class provides the infrastructure for running the application and managing plugins.
# '''Plugin Registration''': Plugins are registered using the <code>@use</code> decorator, which associates a plugin class with optional configuration options.
# '''Static Initialization''': The static initialization ensures the server is instantiated immediately upon class definition.

<syntaxhighlight lang="JavaScript">
/* @babel ES2025 */

import {Server, use} from "appserver";
import {AppServerPlugin} from "appserver";
import {SystemdPlugin} from "appserver";
import {HttpPlugin, http} from "appserver";
import {AuthPlugin, auth} from "appserver";
import {PermPlugin, perm} from "appserver";
import {DebugConsolePlugin} from "appserver";
import {HAProxyPlugin} from "appserver";

@use( DebugConsolePlugin )
@use( HAProxyPlugin, {port: 8080, endpoint: /^(?!.*\.jss$).*/, slot: "http_slot00"} )
@use( SystemdPlugin )
@use( HttpPlugin, {port: 8080} )
@use( AppServerPlugin )
@use( AuthPlugin )
@use( PermPlugin )
class MyServer extends Server {

static {
new this();
}

constructor(...args) {
super(...args);
}

}

</syntaxhighlight>

== Notes ==

# The <code>@use</code> decorator can be applied multiple times to register different plugins.
# Plugin options can configure ports, endpoints, or internal slots for routing.

= HttpPlugin =

The '''HttpPlugin''' extends the core '''Server''' class with HTTP capabilities.
When this plugin is enabled, the server can listen on a given port and expose REST-like endpoints.

This makes it possible to build fully functional web APIs directly on top of the server, using standard '''Request''' and '''Response''' handling from the Web API specification.

== Decorator-Based Routing ==
Once the '''HttpPlugin''' is enabled, endpoints can be defined directly in the server class using decorators.
Each decorator corresponds to a specific HTTP method.

=== Supported Decorators ===
* '''@http.get(path)''' – Declares a GET endpoint for the given path. Used for fetching resources or data.
* '''@http.post(path)''' – Declares a POST endpoint for the given path. Used for creating new resources or submitting data.
* '''@http.put(path)''' – Declares a PUT endpoint for the given path. Used for updating or replacing an existing resource.
* '''@http.patch(path)''' – Declares a PATCH endpoint for the given path. Used for partially updating an existing resource.
* '''@http.delete(path)''' – Declares a DELETE endpoint for the given path. Used for removing resources.
* '''@http.head(path)''' – Declares a HEAD endpoint for the given path. Similar to GET but returns only headers without the body.
* '''@http.options(path)''' – Declares an OPTIONS endpoint for the given path. Used for describing communication options, often in CORS scenarios.

== Request and Response Handling ==
The plugin uses standard Web API classes:

* '''Request''' – represents the incoming HTTP request (method, URL, headers, body).
* '''Response''' – represents the outgoing HTTP response (status, headers, body).

This ensures full compatibility with modern JavaScript patterns for handling HTTP.

== Example ==
<syntaxhighlight lang="javascript">
/* @babel ES2025 */

import {Server} from "appserver";
import {HttpPlugin, http} from "appserver";
import {Response} from "fetch";

new (class MyServer extends Server {

static {
MyServer.enablePlugin(HttpPlugin, { port: 8080 });
}

constructor(...args) {
super(...args);

this.start();
}

@http.get("/myendpoint")
async handleRequest(request) {
return new Response("Hello world", {
status: 200,
headers: {
"Content-Type": "text/plain"
}
});
}

})();
</syntaxhighlight>

Application Server

2025-09-02T07:28:08Z

Guttmann: /* Plugin-based architecture */

Application Server

2025-09-02T07:25:01Z

Guttmann: /* Plugin-based architecture */

Application Server

2025-09-02T07:24:54Z

Guttmann: /* Plugin-based architecture */

Application Server

2025-09-02T07:23:34Z

Guttmann: /* Plugin-based architecture */

Application Server

2025-09-02T07:23:21Z

Guttmann: /* Plugin-based architecture */

Application Server

2025-09-02T07:20:00Z

Guttmann: /* Plugin-based architecture */

Application Server

2025-09-02T07:18:54Z

Guttmann: /* Plugin-based architecture */

Application Server

2025-09-02T07:11:51Z

Guttmann: /* Plugin-based architecture */

Application Server

2025-09-02T07:09:39Z

Guttmann: /* Plugin-based architecture */

Application Server

2025-09-02T07:07:01Z

Guttmann: /* Plugin-based architecture */

Application Server

2025-09-02T07:03:59Z

Guttmann: /* Plugin-based architecture */

Application Server

2025-09-02T07:02:16Z

Guttmann: /* Plugin-based architecture */

Application Server

2025-09-02T07:00:38Z

Guttmann: /* Plugin-based architecture */

Application Server

2025-09-02T06:55:53Z

Guttmann: /* Plugin-based architecture */

Application Server

2025-09-02T06:55:11Z

Guttmann: /* Filesystem Layout */

The FullJS application server provides a robust, modular, and secure foundation for running server-side services. It combines modern architectural principles with deep Linux integration to deliver enterprise-grade capabilitie

= Microservice Architecture =
The FullJS applications server follows a microservice-based server architecture with deep systemd integration. The application server is represented as a Systemd target ([application].target), with each individual microservice corresponding to a systemd unit instance ([application]@[microservice]).

== Adding and Removing Microservices from the Application Server ==

To add a microservice (a.k.a systemd unit instance) to the application server (a.k.a systemd target):

<code>
sudo systemctl enable [application]@[microservice]
</code>

To remove a microservice from the application server group:

<code>
sudo systemctl disable [application]@[microservice]
</code>

''Note:'' Enabling a microservice only registers it with the application server for automatic start at boot. It does **not** start the microservice immediately in the current session.

== Starting and Stopping a Microservice ==
Each microservice runs as a separate systemd unit instance ([application]@[microservice]).
To start a microservice:

<code>
sudo systemctl start [application]@[microservice]
</code>

To stop a microservice:

<code>
sudo systemctl stop [application]@[microservice]
</code>

''Note:'' starting a microservice only affects the current session and does not configure it to start automatically at boot.

== Checking the Status of a Microservice ==
Each microservice runs as a separate systemd unit instance (<code>[application]@[microservice]</code>).

* To check the current status of a microservice instance:

<code>
sudo systemctl status [application]@[microservice]
</code>

This command shows whether the service is running, stopped, or failed, along with recent log entries.

== Starting and Stopping the application server ==
To start the application server use systemd’s start command.

<code>
sudo systemctl start [application].target
</code>

To stop a running application server, you can use:

<code>
sudo systemctl stop [application].target
</code>

Keep in mind that starting an application server only affects the current session and does not configure it to start automatically at boot.

== Enabling and Disabling the application server ==
To start the application server automatically at boot, you must enable it.

To start the application server at boot:

<code>sudo systemctl enable [application].target</code>

To disable the application service from starting automatically:

<code>sudo systemctl disable [application].target</code>

Keep in mind that enabling an application server does not start it in the current session.

= Filesystem Layout =
The application conforms to the Linux Filesystem Hierarchy Standard (FHS). Executables, data, runtime state, and configuration are separated cleanly:

* <code>/srv/fulljs/[instance]/</code> – contains the deployed application
* <code>/run/fulljs/[instance]/**</code> – runtime files (e.g., sockets, PID files)
* <code>/var/lib/fulljs/[instance]/**</code> – persistent state data (e.g., storage files)
* <code>/etc/fulljs/**</code> – configuration files (if any)

= Plugin-based architecture =

'''Description:'''
The plugin-based architecture allows the application server to be extended and customized by dynamically enabling modular plugins. Each plugin encapsulates a specific functionality, such as HTTP handling, authentication, permission management, systemd integration, or debugging tools. This design decouples core server logic from optional features, making it easier to maintain, test, and evolve the system.

'''How it works:'''

# '''Core Server Class''': The main ''Server'' class provides the infrastructure for running the application and managing plugins.
# '''Plugin Registration''': Plugins are registered via a static method, e.g., <code>enablePlugin(pluginClass, options)</code>. This allows the server to load specific functionality only when needed.
# '''Static Initialization''': A '''static block''' in the server class runs once when the class is defined. It is used to register all required plugins. This ensures that the server is fully configured before any instances are created (mostly one).

<syntaxhighlight lang="JavaScript">
import {Server} from "appserver";

import {AppServerPlugin} from "appserver";
import {SystemdPlugin} from "appserver";
import {HttpPlugin} from "appserver";
import {AuthPlugin} from "appserver";
import {PermPlugin} from "appserver";
import {DebugConsolePlugin} from "appserver";

new (class MyServer extends Server {

static {
MyServer.enablePlugin(SystemdPlugin);
MyServer.enablePlugin(HttpPlugin, {port: 8080, endpoint: /^(?!.*\.jss$).*/, slot: "http_slot00"});
MyServer.enablePlugin(AppServerPlugin);
MyServer.enablePlugin(AuthPlugin);
MyServer.enablePlugin(PermPlugin);
MyServer.enablePlugin(DebugConsolePlugin);
}

constructor(...args) {
super(...args);
}

})();
</syntaxhighlight>

# '''Plugin Isolation and Modularity''': Each plugin is a self-contained module, responsible for a particular aspect of server functionality. The server core interacts with plugins through a defined interface, enabling safe modularity and easy swapping or upgrading of features.
# '''Extensibility''': Developers can create new plugins without modifying the core server code. By simply calling <code>enablePlugin(NewPlugin)</code> in the static block, the new functionality is integrated seamlessly.

'''Benefits:'''
* '''Modular Design''': Features can be added or removed without touching the core logic.
* '''Reusability''': Plugins can be shared between different projects or server instances.
* '''Scalability''': Additional functionality can be loaded dynamically as the application grows.
* '''Maintainability''': Bugs or updates in one plugin do not affect other parts of the system.

Application Server

2025-09-02T06:54:36Z

Guttmann: /* Plugin-based architecture – Extend and customize backend functionality through a modular plugin system */

The FullJS application server provides a robust, modular, and secure foundation for running server-side services. It combines modern architectural principles with deep Linux integration to deliver enterprise-grade capabilitie

= Microservice Architecture =
The FullJS applications server follows a microservice-based server architecture with deep systemd integration. The application server is represented as a Systemd target ([application].target), with each individual microservice corresponding to a systemd unit instance ([application]@[microservice]).

== Adding and Removing Microservices from the Application Server ==

To add a microservice (a.k.a systemd unit instance) to the application server (a.k.a systemd target):

<code>
sudo systemctl enable [application]@[microservice]
</code>

To remove a microservice from the application server group:

<code>
sudo systemctl disable [application]@[microservice]
</code>

''Note:'' Enabling a microservice only registers it with the application server for automatic start at boot. It does **not** start the microservice immediately in the current session.

== Starting and Stopping a Microservice ==
Each microservice runs as a separate systemd unit instance ([application]@[microservice]).
To start a microservice:

<code>
sudo systemctl start [application]@[microservice]
</code>

To stop a microservice:

<code>
sudo systemctl stop [application]@[microservice]
</code>

''Note:'' starting a microservice only affects the current session and does not configure it to start automatically at boot.

== Checking the Status of a Microservice ==
Each microservice runs as a separate systemd unit instance (<code>[application]@[microservice]</code>).

* To check the current status of a microservice instance:

<code>
sudo systemctl status [application]@[microservice]
</code>

This command shows whether the service is running, stopped, or failed, along with recent log entries.

== Starting and Stopping the application server ==
To start the application server use systemd’s start command.

<code>
sudo systemctl start [application].target
</code>

To stop a running application server, you can use:

<code>
sudo systemctl stop [application].target
</code>

Keep in mind that starting an application server only affects the current session and does not configure it to start automatically at boot.

== Enabling and Disabling the application server ==
To start the application server automatically at boot, you must enable it.

To start the application server at boot:

<code>sudo systemctl enable [application].target</code>

To disable the application service from starting automatically:

<code>sudo systemctl disable [application].target</code>

Keep in mind that enabling an application server does not start it in the current session.

= Filesystem Layout =
The application conforms to the Linux Filesystem Hierarchy Standard (FHS). Executables, data, runtime state, and configuration are separated cleanly:

* <code>/srv/fulljs/[instance]/</code> – contains the deployed application
* <code>/run/fulljs/[instance]/**</code> – runtime files (e.g., sockets, PID files)
* <code>/var/lib/fulljs/[instance]/**</code> – persistent state data (e.g., storage files)
* <code>/etc/fulljs/**</code> – configuration files (if any)

= Plugin-based architecture

'''Description:'''
The plugin-based architecture allows the application server to be extended and customized by dynamically enabling modular plugins. Each plugin encapsulates a specific functionality, such as HTTP handling, authentication, permission management, systemd integration, or debugging tools. This design decouples core server logic from optional features, making it easier to maintain, test, and evolve the system.

'''How it works:'''

# '''Core Server Class''': The main ''Server'' class provides the infrastructure for running the application and managing plugins.
# '''Plugin Registration''': Plugins are registered via a static method, e.g., <code>enablePlugin(pluginClass, options)</code>. This allows the server to load specific functionality only when needed.
# '''Static Initialization''': A '''static block''' in the server class runs once when the class is defined. It is used to register all required plugins. This ensures that the server is fully configured before any instances are created (mostly one).

<syntaxhighlight lang="JavaScript">
import {Server} from "appserver";

import {AppServerPlugin} from "appserver";
import {SystemdPlugin} from "appserver";
import {HttpPlugin} from "appserver";
import {AuthPlugin} from "appserver";
import {PermPlugin} from "appserver";
import {DebugConsolePlugin} from "appserver";

new (class MyServer extends Server {

static {
MyServer.enablePlugin(SystemdPlugin);
MyServer.enablePlugin(HttpPlugin, {port: 8080, endpoint: /^(?!.*\.jss$).*/, slot: "http_slot00"});
MyServer.enablePlugin(AppServerPlugin);
MyServer.enablePlugin(AuthPlugin);
MyServer.enablePlugin(PermPlugin);
MyServer.enablePlugin(DebugConsolePlugin);
}

constructor(...args) {
super(...args);
}

})();
</syntaxhighlight>

# '''Plugin Isolation and Modularity''': Each plugin is a self-contained module, responsible for a particular aspect of server functionality. The server core interacts with plugins through a defined interface, enabling safe modularity and easy swapping or upgrading of features.
# '''Extensibility''': Developers can create new plugins without modifying the core server code. By simply calling <code>enablePlugin(NewPlugin)</code> in the static block, the new functionality is integrated seamlessly.

'''Benefits:'''
* '''Modular Design''': Features can be added or removed without touching the core logic.
* '''Reusability''': Plugins can be shared between different projects or server instances.
* '''Scalability''': Additional functionality can be loaded dynamically as the application grows.
* '''Maintainability''': Bugs or updates in one plugin do not affect other parts of the system.

Application Server

2025-09-02T06:02:21Z

Guttmann: /* Plugin-based architecture – Extend and customize backend functionality through a modular plugin system */

The FullJS application server provides a robust, modular, and secure foundation for running server-side services. It combines modern architectural principles with deep Linux integration to deliver enterprise-grade capabilitie

= Microservice Architecture =
The FullJS applications server follows a microservice-based server architecture with deep systemd integration. The application server is represented as a Systemd target ([application].target), with each individual microservice corresponding to a systemd unit instance ([application]@[microservice]).

== Adding and Removing Microservices from the Application Server ==

To add a microservice (a.k.a systemd unit instance) to the application server (a.k.a systemd target):

<code>
sudo systemctl enable [application]@[microservice]
</code>

To remove a microservice from the application server group:

<code>
sudo systemctl disable [application]@[microservice]
</code>

''Note:'' Enabling a microservice only registers it with the application server for automatic start at boot. It does **not** start the microservice immediately in the current session.

== Starting and Stopping a Microservice ==
Each microservice runs as a separate systemd unit instance ([application]@[microservice]).
To start a microservice:

<code>
sudo systemctl start [application]@[microservice]
</code>

To stop a microservice:

<code>
sudo systemctl stop [application]@[microservice]
</code>

''Note:'' starting a microservice only affects the current session and does not configure it to start automatically at boot.

== Checking the Status of a Microservice ==
Each microservice runs as a separate systemd unit instance (<code>[application]@[microservice]</code>).

* To check the current status of a microservice instance:

<code>
sudo systemctl status [application]@[microservice]
</code>

This command shows whether the service is running, stopped, or failed, along with recent log entries.

== Starting and Stopping the application server ==
To start the application server use systemd’s start command.

<code>
sudo systemctl start [application].target
</code>

To stop a running application server, you can use:

<code>
sudo systemctl stop [application].target
</code>

Keep in mind that starting an application server only affects the current session and does not configure it to start automatically at boot.

== Enabling and Disabling the application server ==
To start the application server automatically at boot, you must enable it.

To start the application server at boot:

<code>sudo systemctl enable [application].target</code>

To disable the application service from starting automatically:

<code>sudo systemctl disable [application].target</code>

Keep in mind that enabling an application server does not start it in the current session.

= Filesystem Layout =
The application conforms to the Linux Filesystem Hierarchy Standard (FHS). Executables, data, runtime state, and configuration are separated cleanly:

* <code>/srv/fulljs/[instance]/</code> – contains the deployed application
* <code>/run/fulljs/[instance]/**</code> – runtime files (e.g., sockets, PID files)
* <code>/var/lib/fulljs/[instance]/**</code> – persistent state data (e.g., storage files)
* <code>/etc/fulljs/**</code> – configuration files (if any)

= Plugin-based architecture – Extend and customize backend functionality through a modular plugin system =

'''Description:'''
The plugin-based architecture allows the application server to be extended and customized by dynamically enabling modular plugins. Each plugin encapsulates a specific functionality, such as HTTP handling, authentication, permission management, systemd integration, or debugging tools. This design decouples core server logic from optional features, making it easier to maintain, test, and evolve the system.

'''How it works:'''

# '''Core Server Class''': The main ''Server'' class provides the infrastructure for running the application and managing plugins.
# '''Plugin Registration''': Plugins are registered via a static method, e.g., <code>enablePlugin(pluginClass, options)</code>. This allows the server to load specific functionality only when needed.
# '''Static Initialization''': A '''static block''' in the server class runs once when the class is defined. It is used to register all required plugins. This ensures that the server is fully configured before any instances are created (mostly one).

<syntaxhighlight lang="JavaScript">
import {Server} from "appserver";

import {AppServerPlugin} from "appserver";
import {SystemdPlugin} from "appserver";
import {HttpPlugin} from "appserver";
import {AuthPlugin} from "appserver";
import {PermPlugin} from "appserver";
import {DebugConsolePlugin} from "appserver";

new (class MyServer extends Server {

static {
MyServer.enablePlugin(SystemdPlugin);
MyServer.enablePlugin(HttpPlugin, {port: 8080, endpoint: /^(?!.*\.jss$).*/, slot: "http_slot00"});
MyServer.enablePlugin(AppServerPlugin);
MyServer.enablePlugin(AuthPlugin);
MyServer.enablePlugin(PermPlugin);
MyServer.enablePlugin(DebugConsolePlugin);
}

constructor(...args) {
super(...args);
}

})();
</syntaxhighlight>

# '''Plugin Isolation and Modularity''': Each plugin is a self-contained module, responsible for a particular aspect of server functionality. The server core interacts with plugins through a defined interface, enabling safe modularity and easy swapping or upgrading of features.
# '''Extensibility''': Developers can create new plugins without modifying the core server code. By simply calling <code>enablePlugin(NewPlugin)</code> in the static block, the new functionality is integrated seamlessly.

'''Benefits:'''
* '''Modular Design''': Features can be added or removed without touching the core logic.
* '''Reusability''': Plugins can be shared between different projects or server instances.
* '''Scalability''': Additional functionality can be loaded dynamically as the application grows.
* '''Maintainability''': Bugs or updates in one plugin do not affect other parts of the system.

Application Server

2025-09-02T06:00:45Z

Guttmann: /* Plugin-based architecture – Extend and customize backend functionality through a modular plugin system */

The FullJS application server provides a robust, modular, and secure foundation for running server-side services. It combines modern architectural principles with deep Linux integration to deliver enterprise-grade capabilitie

= Microservice Architecture =
The FullJS applications server follows a microservice-based server architecture with deep systemd integration. The application server is represented as a Systemd target ([application].target), with each individual microservice corresponding to a systemd unit instance ([application]@[microservice]).

== Adding and Removing Microservices from the Application Server ==

To add a microservice (a.k.a systemd unit instance) to the application server (a.k.a systemd target):

<code>
sudo systemctl enable [application]@[microservice]
</code>

To remove a microservice from the application server group:

<code>
sudo systemctl disable [application]@[microservice]
</code>

''Note:'' Enabling a microservice only registers it with the application server for automatic start at boot. It does **not** start the microservice immediately in the current session.

== Starting and Stopping a Microservice ==
Each microservice runs as a separate systemd unit instance ([application]@[microservice]).
To start a microservice:

<code>
sudo systemctl start [application]@[microservice]
</code>

To stop a microservice:

<code>
sudo systemctl stop [application]@[microservice]
</code>

''Note:'' starting a microservice only affects the current session and does not configure it to start automatically at boot.

== Checking the Status of a Microservice ==
Each microservice runs as a separate systemd unit instance (<code>[application]@[microservice]</code>).

* To check the current status of a microservice instance:

<code>
sudo systemctl status [application]@[microservice]
</code>

This command shows whether the service is running, stopped, or failed, along with recent log entries.

== Starting and Stopping the application server ==
To start the application server use systemd’s start command.

<code>
sudo systemctl start [application].target
</code>

To stop a running application server, you can use:

<code>
sudo systemctl stop [application].target
</code>

Keep in mind that starting an application server only affects the current session and does not configure it to start automatically at boot.

== Enabling and Disabling the application server ==
To start the application server automatically at boot, you must enable it.

To start the application server at boot:

<code>sudo systemctl enable [application].target</code>

To disable the application service from starting automatically:

<code>sudo systemctl disable [application].target</code>

Keep in mind that enabling an application server does not start it in the current session.

= Filesystem Layout =
The application conforms to the Linux Filesystem Hierarchy Standard (FHS). Executables, data, runtime state, and configuration are separated cleanly:

* <code>/srv/fulljs/[instance]/</code> – contains the deployed application
* <code>/run/fulljs/[instance]/**</code> – runtime files (e.g., sockets, PID files)
* <code>/var/lib/fulljs/[instance]/**</code> – persistent state data (e.g., storage files)
* <code>/etc/fulljs/**</code> – configuration files (if any)

= Plugin-based architecture – Extend and customize backend functionality through a modular plugin system =

'''Description:'''
The plugin-based architecture allows the application server to be extended and customized by dynamically enabling modular plugins. Each plugin encapsulates a specific functionality, such as HTTP handling, authentication, permission management, systemd integration, or debugging tools. This design decouples core server logic from optional features, making it easier to maintain, test, and evolve the system.

'''How it works:'''

# '''Core Server Class''': The main ''Server'' class provides the infrastructure for running the application and managing plugins.
# '''Plugin Registration''': Plugins are registered via a static method, e.g., <code>enablePlugin(pluginClass, options)</code>. This allows the server to load specific functionality only when needed.
# '''Static Initialization''': A '''static block''' in the server class runs once when the class is defined. It is used to register all required plugins. This ensures that the server is fully configured before any instances are created (mostly one).

<syntaxhighlight>
import {Server} from "appserver";

import {AppServerPlugin} from "appserver";
import {SystemdPlugin} from "appserver";
import {HttpPlugin} from "appserver";
import {AuthPlugin} from "appserver";
import {PermPlugin} from "appserver";
import {DebugConsolePlugin} from "appserver";

new (class MyServer extends Server {

static {
MyServer.enablePlugin(SystemdPlugin);
MyServer.enablePlugin(HttpPlugin, {port: 8080, endpoint: /^(?!.*\.jss$).*/, slot: "http_slot00"});
MyServer.enablePlugin(AppServerPlugin);
MyServer.enablePlugin(AuthPlugin);
MyServer.enablePlugin(PermPlugin);
MyServer.enablePlugin(DebugConsolePlugin);
}

constructor(...args) {
super(...args);
}

})();
</syntaxhighlight>

# '''Plugin Isolation and Modularity''': Each plugin is a self-contained module, responsible for a particular aspect of server functionality. The server core interacts with plugins through a defined interface, enabling safe modularity and easy swapping or upgrading of features.
# '''Extensibility''': Developers can create new plugins without modifying the core server code. By simply calling <code>enablePlugin(NewPlugin)</code> in the static block, the new functionality is integrated seamlessly.

'''Benefits:'''
* '''Modular Design''': Features can be added or removed without touching the core logic.
* '''Reusability''': Plugins can be shared between different projects or server instances.
* '''Scalability''': Additional functionality can be loaded dynamically as the application grows.
* '''Maintainability''': Bugs or updates in one plugin do not affect other parts of the system.

Application Server

2025-09-02T05:57:01Z

Guttmann: /* Plugin-based architecture – Extend and customize backend functionality through a modular plugin system */

The FullJS application server provides a robust, modular, and secure foundation for running server-side services. It combines modern architectural principles with deep Linux integration to deliver enterprise-grade capabilitie

= Microservice Architecture =
The FullJS applications server follows a microservice-based server architecture with deep systemd integration. The application server is represented as a Systemd target ([application].target), with each individual microservice corresponding to a systemd unit instance ([application]@[microservice]).

== Adding and Removing Microservices from the Application Server ==

To add a microservice (a.k.a systemd unit instance) to the application server (a.k.a systemd target):

<code>
sudo systemctl enable [application]@[microservice]
</code>

To remove a microservice from the application server group:

<code>
sudo systemctl disable [application]@[microservice]
</code>

''Note:'' Enabling a microservice only registers it with the application server for automatic start at boot. It does **not** start the microservice immediately in the current session.

== Starting and Stopping a Microservice ==
Each microservice runs as a separate systemd unit instance ([application]@[microservice]).
To start a microservice:

<code>
sudo systemctl start [application]@[microservice]
</code>

To stop a microservice:

<code>
sudo systemctl stop [application]@[microservice]
</code>

''Note:'' starting a microservice only affects the current session and does not configure it to start automatically at boot.

== Checking the Status of a Microservice ==
Each microservice runs as a separate systemd unit instance (<code>[application]@[microservice]</code>).

* To check the current status of a microservice instance:

<code>
sudo systemctl status [application]@[microservice]
</code>

This command shows whether the service is running, stopped, or failed, along with recent log entries.

== Starting and Stopping the application server ==
To start the application server use systemd’s start command.

<code>
sudo systemctl start [application].target
</code>

To stop a running application server, you can use:

<code>
sudo systemctl stop [application].target
</code>

Keep in mind that starting an application server only affects the current session and does not configure it to start automatically at boot.

== Enabling and Disabling the application server ==
To start the application server automatically at boot, you must enable it.

To start the application server at boot:

<code>sudo systemctl enable [application].target</code>

To disable the application service from starting automatically:

<code>sudo systemctl disable [application].target</code>

Keep in mind that enabling an application server does not start it in the current session.

= Filesystem Layout =
The application conforms to the Linux Filesystem Hierarchy Standard (FHS). Executables, data, runtime state, and configuration are separated cleanly:

* <code>/srv/fulljs/[instance]/</code> – contains the deployed application
* <code>/run/fulljs/[instance]/**</code> – runtime files (e.g., sockets, PID files)
* <code>/var/lib/fulljs/[instance]/**</code> – persistent state data (e.g., storage files)
* <code>/etc/fulljs/**</code> – configuration files (if any)

= Plugin-based architecture – Extend and customize backend functionality through a modular plugin system =

'''Description:'''
The plugin-based architecture allows the application server to be extended and customized by dynamically enabling modular plugins. Each plugin encapsulates a specific functionality, such as HTTP handling, authentication, permission management, systemd integration, or debugging tools. This design decouples core server logic from optional features, making it easier to maintain, test, and evolve the system.

'''How it works:'''

# '''Core Server Class''': The main ''Server'' class provides the infrastructure for running the application and managing plugins.
# '''Plugin Registration''': Plugins are registered via a static method, e.g., <code>enablePlugin(pluginClass, options)</code>. This allows the server to load specific functionality only when needed.
# '''Static Initialization''': A '''static block''' in the server class runs once when the class is defined. It is used to register all required plugins. This ensures that the server is fully configured before any instances are created (mostly one).

<syntaxhighlight lang="javacript">
import {Server} from "appserver";

import {AppServerPlugin} from "appserver";
import {SystemdPlugin} from "appserver";
import {HttpPlugin} from "appserver";
import {AuthPlugin} from "appserver";
import {PermPlugin} from "appserver";
import {DebugConsolePlugin} from "appserver";

new (class MyServer extends Server {

static {
MyServer.enablePlugin(SystemdPlugin);
MyServer.enablePlugin(HttpPlugin, {port: 8080, endpoint: /^(?!.*\.jss$).*/, slot: "http_slot00"});
MyServer.enablePlugin(AppServerPlugin);
MyServer.enablePlugin(AuthPlugin);
MyServer.enablePlugin(PermPlugin);
MyServer.enablePlugin(DebugConsolePlugin);
}

constructor(...args) {
super(...args);
}

})();
</syntaxhighlight>

# '''Plugin Isolation and Modularity''': Each plugin is a self-contained module, responsible for a particular aspect of server functionality. The server core interacts with plugins through a defined interface, enabling safe modularity and easy swapping or upgrading of features.
# '''Extensibility''': Developers can create new plugins without modifying the core server code. By simply calling <code>enablePlugin(NewPlugin)</code> in the static block, the new functionality is integrated seamlessly.

'''Benefits:'''
* '''Modular Design''': Features can be added or removed without touching the core logic.
* '''Reusability''': Plugins can be shared between different projects or server instances.
* '''Scalability''': Additional functionality can be loaded dynamically as the application grows.
* '''Maintainability''': Bugs or updates in one plugin do not affect other parts of the system.

Application Server

2025-09-02T05:56:30Z

Guttmann: /* Plugin-based architecture – Extend and customize backend functionality through a modular plugin system */

The FullJS application server provides a robust, modular, and secure foundation for running server-side services. It combines modern architectural principles with deep Linux integration to deliver enterprise-grade capabilitie

= Microservice Architecture =
The FullJS applications server follows a microservice-based server architecture with deep systemd integration. The application server is represented as a Systemd target ([application].target), with each individual microservice corresponding to a systemd unit instance ([application]@[microservice]).

== Adding and Removing Microservices from the Application Server ==

To add a microservice (a.k.a systemd unit instance) to the application server (a.k.a systemd target):

<code>
sudo systemctl enable [application]@[microservice]
</code>

To remove a microservice from the application server group:

<code>
sudo systemctl disable [application]@[microservice]
</code>

''Note:'' Enabling a microservice only registers it with the application server for automatic start at boot. It does **not** start the microservice immediately in the current session.

== Starting and Stopping a Microservice ==
Each microservice runs as a separate systemd unit instance ([application]@[microservice]).
To start a microservice:

<code>
sudo systemctl start [application]@[microservice]
</code>

To stop a microservice:

<code>
sudo systemctl stop [application]@[microservice]
</code>

''Note:'' starting a microservice only affects the current session and does not configure it to start automatically at boot.

== Checking the Status of a Microservice ==
Each microservice runs as a separate systemd unit instance (<code>[application]@[microservice]</code>).

* To check the current status of a microservice instance:

<code>
sudo systemctl status [application]@[microservice]
</code>

This command shows whether the service is running, stopped, or failed, along with recent log entries.

== Starting and Stopping the application server ==
To start the application server use systemd’s start command.

<code>
sudo systemctl start [application].target
</code>

To stop a running application server, you can use:

<code>
sudo systemctl stop [application].target
</code>

Keep in mind that starting an application server only affects the current session and does not configure it to start automatically at boot.

== Enabling and Disabling the application server ==
To start the application server automatically at boot, you must enable it.

To start the application server at boot:

<code>sudo systemctl enable [application].target</code>

To disable the application service from starting automatically:

<code>sudo systemctl disable [application].target</code>

Keep in mind that enabling an application server does not start it in the current session.

= Filesystem Layout =
The application conforms to the Linux Filesystem Hierarchy Standard (FHS). Executables, data, runtime state, and configuration are separated cleanly:

* <code>/srv/fulljs/[instance]/</code> – contains the deployed application
* <code>/run/fulljs/[instance]/**</code> – runtime files (e.g., sockets, PID files)
* <code>/var/lib/fulljs/[instance]/**</code> – persistent state data (e.g., storage files)
* <code>/etc/fulljs/**</code> – configuration files (if any)

= Plugin-based architecture – Extend and customize backend functionality through a modular plugin system =

'''Description:'''
The plugin-based architecture allows the application server to be extended and customized by dynamically enabling modular plugins. Each plugin encapsulates a specific functionality, such as HTTP handling, authentication, permission management, systemd integration, or debugging tools. This design decouples core server logic from optional features, making it easier to maintain, test, and evolve the system.

'''How it works:'''

# '''Core Server Class''': The main ''Server'' class provides the infrastructure for running the application and managing plugins.
# '''Plugin Registration''': Plugins are registered via a static method, e.g., <code>enablePlugin(pluginClass, options)</code>. This allows the server to load specific functionality only when needed.
# '''Static Initialization''': A '''static block''' in the server class runs once when the class is defined. It is used to register all required plugins. This ensures that the server is fully configured before any instances are created (mostly one).

<source lang="javacript">
import {Server} from "appserver";

import {AppServerPlugin} from "appserver";
import {SystemdPlugin} from "appserver";
import {HttpPlugin} from "appserver";
import {AuthPlugin} from "appserver";
import {PermPlugin} from "appserver";
import {DebugConsolePlugin} from "appserver";

new (class MyServer extends Server {

static {
MyServer.enablePlugin(SystemdPlugin);
MyServer.enablePlugin(HttpPlugin, {port: 8080, endpoint: /^(?!.*\.jss$).*/, slot: "http_slot00"});
MyServer.enablePlugin(AppServerPlugin);
MyServer.enablePlugin(AuthPlugin);
MyServer.enablePlugin(PermPlugin);
MyServer.enablePlugin(DebugConsolePlugin);
}

constructor(...args) {
super(...args);
}

})();
</source>

# '''Plugin Isolation and Modularity''': Each plugin is a self-contained module, responsible for a particular aspect of server functionality. The server core interacts with plugins through a defined interface, enabling safe modularity and easy swapping or upgrading of features.
# '''Extensibility''': Developers can create new plugins without modifying the core server code. By simply calling <code>enablePlugin(NewPlugin)</code> in the static block, the new functionality is integrated seamlessly.

'''Benefits:'''
* '''Modular Design''': Features can be added or removed without touching the core logic.
* '''Reusability''': Plugins can be shared between different projects or server instances.
* '''Scalability''': Additional functionality can be loaded dynamically as the application grows.
* '''Maintainability''': Bugs or updates in one plugin do not affect other parts of the system.

Application Server

2025-09-02T05:51:01Z

Guttmann: /* Plugin-based architecture – Extend and customize backend functionality through a modular plugin system */

The FullJS application server provides a robust, modular, and secure foundation for running server-side services. It combines modern architectural principles with deep Linux integration to deliver enterprise-grade capabilitie

= Microservice Architecture =
The FullJS applications server follows a microservice-based server architecture with deep systemd integration. The application server is represented as a Systemd target ([application].target), with each individual microservice corresponding to a systemd unit instance ([application]@[microservice]).

== Adding and Removing Microservices from the Application Server ==

To add a microservice (a.k.a systemd unit instance) to the application server (a.k.a systemd target):

<code>
sudo systemctl enable [application]@[microservice]
</code>

To remove a microservice from the application server group:

<code>
sudo systemctl disable [application]@[microservice]
</code>

''Note:'' Enabling a microservice only registers it with the application server for automatic start at boot. It does **not** start the microservice immediately in the current session.

== Starting and Stopping a Microservice ==
Each microservice runs as a separate systemd unit instance ([application]@[microservice]).
To start a microservice:

<code>
sudo systemctl start [application]@[microservice]
</code>

To stop a microservice:

<code>
sudo systemctl stop [application]@[microservice]
</code>

''Note:'' starting a microservice only affects the current session and does not configure it to start automatically at boot.

== Checking the Status of a Microservice ==
Each microservice runs as a separate systemd unit instance (<code>[application]@[microservice]</code>).

* To check the current status of a microservice instance:

<code>
sudo systemctl status [application]@[microservice]
</code>

This command shows whether the service is running, stopped, or failed, along with recent log entries.

== Starting and Stopping the application server ==
To start the application server use systemd’s start command.

<code>
sudo systemctl start [application].target
</code>

To stop a running application server, you can use:

<code>
sudo systemctl stop [application].target
</code>

Keep in mind that starting an application server only affects the current session and does not configure it to start automatically at boot.

== Enabling and Disabling the application server ==
To start the application server automatically at boot, you must enable it.

To start the application server at boot:

<code>sudo systemctl enable [application].target</code>

To disable the application service from starting automatically:

<code>sudo systemctl disable [application].target</code>

Keep in mind that enabling an application server does not start it in the current session.

= Filesystem Layout =
The application conforms to the Linux Filesystem Hierarchy Standard (FHS). Executables, data, runtime state, and configuration are separated cleanly:

* <code>/srv/fulljs/[instance]/</code> – contains the deployed application
* <code>/run/fulljs/[instance]/**</code> – runtime files (e.g., sockets, PID files)
* <code>/var/lib/fulljs/[instance]/**</code> – persistent state data (e.g., storage files)
* <code>/etc/fulljs/**</code> – configuration files (if any)

= Plugin-based architecture – Extend and customize backend functionality through a modular plugin system =

'''Description:'''
The plugin-based architecture allows the application server to be extended and customized by dynamically enabling modular plugins. Each plugin encapsulates a specific functionality, such as HTTP handling, authentication, permission management, systemd integration, or debugging tools. This design decouples core server logic from optional features, making it easier to maintain, test, and evolve the system.

'''How it works:'''

# '''Core Server Class''': The main ''Server'' class provides the infrastructure for running the application and managing plugins.
# '''Plugin Registration''': Plugins are registered via a static method, e.g., <code>enablePlugin(pluginClass, options)</code>. This allows the server to load specific functionality only when needed.
# '''Static Initialization''': A '''static block''' in the server class runs once when the class is defined. It is used to register all required plugins. This ensures that the server is fully configured before any instances are created (mostly one).

<syntaxhighlight lang="javacript">
import {Server} from "appserver";

import {AppServerPlugin} from "appserver";
import {SystemdPlugin} from "appserver";
import {HttpPlugin} from "appserver";
import {AuthPlugin} from "appserver";
import {PermPlugin} from "appserver";
import {DebugConsolePlugin} from "appserver";

new (class MyServer extends Server {

static {
MyServer.enablePlugin(SystemdPlugin);
MyServer.enablePlugin(HttpPlugin, {port: 8080, endpoint: /^(?!.*\.jss$).*/, slot: "http_slot00"});
MyServer.enablePlugin(AppServerPlugin);
MyServer.enablePlugin(AuthPlugin);
MyServer.enablePlugin(PermPlugin);
MyServer.enablePlugin(DebugConsolePlugin);
}

constructor(...args) {
super(...args);
}

})();
</syntaxhighlight>

# '''Plugin Isolation and Modularity''': Each plugin is a self-contained module, responsible for a particular aspect of server functionality. The server core interacts with plugins through a defined interface, enabling safe modularity and easy swapping or upgrading of features.
# '''Extensibility''': Developers can create new plugins without modifying the core server code. By simply calling <code>enablePlugin(NewPlugin)</code> in the static block, the new functionality is integrated seamlessly.

'''Benefits:'''
* '''Modular Design''': Features can be added or removed without touching the core logic.
* '''Reusability''': Plugins can be shared between different projects or server instances.
* '''Scalability''': Additional functionality can be loaded dynamically as the application grows.
* '''Maintainability''': Bugs or updates in one plugin do not affect other parts of the system.

Application Server

2025-09-01T21:20:08Z

Guttmann: /* Plugin-based architecture – Extend and customize backend functionality through a modular plugin system */

The FullJS application server provides a robust, modular, and secure foundation for running server-side services. It combines modern architectural principles with deep Linux integration to deliver enterprise-grade capabilitie

= Microservice Architecture =
The FullJS applications server follows a microservice-based server architecture with deep systemd integration. The application server is represented as a Systemd target ([application].target), with each individual microservice corresponding to a systemd unit instance ([application]@[microservice]).

== Adding and Removing Microservices from the Application Server ==

To add a microservice (a.k.a systemd unit instance) to the application server (a.k.a systemd target):

<code>
sudo systemctl enable [application]@[microservice]
</code>

To remove a microservice from the application server group:

<code>
sudo systemctl disable [application]@[microservice]
</code>

''Note:'' Enabling a microservice only registers it with the application server for automatic start at boot. It does **not** start the microservice immediately in the current session.

== Starting and Stopping a Microservice ==
Each microservice runs as a separate systemd unit instance ([application]@[microservice]).
To start a microservice:

<code>
sudo systemctl start [application]@[microservice]
</code>

To stop a microservice:

<code>
sudo systemctl stop [application]@[microservice]
</code>

''Note:'' starting a microservice only affects the current session and does not configure it to start automatically at boot.

== Checking the Status of a Microservice ==
Each microservice runs as a separate systemd unit instance (<code>[application]@[microservice]</code>).

* To check the current status of a microservice instance:

<code>
sudo systemctl status [application]@[microservice]
</code>

This command shows whether the service is running, stopped, or failed, along with recent log entries.

== Starting and Stopping the application server ==
To start the application server use systemd’s start command.

<code>
sudo systemctl start [application].target
</code>

To stop a running application server, you can use:

<code>
sudo systemctl stop [application].target
</code>

Keep in mind that starting an application server only affects the current session and does not configure it to start automatically at boot.

== Enabling and Disabling the application server ==
To start the application server automatically at boot, you must enable it.

To start the application server at boot:

<code>sudo systemctl enable [application].target</code>

To disable the application service from starting automatically:

<code>sudo systemctl disable [application].target</code>

Keep in mind that enabling an application server does not start it in the current session.

= Filesystem Layout =
The application conforms to the Linux Filesystem Hierarchy Standard (FHS). Executables, data, runtime state, and configuration are separated cleanly:

* <code>/srv/fulljs/[instance]/</code> – contains the deployed application
* <code>/run/fulljs/[instance]/**</code> – runtime files (e.g., sockets, PID files)
* <code>/var/lib/fulljs/[instance]/**</code> – persistent state data (e.g., storage files)
* <code>/etc/fulljs/**</code> – configuration files (if any)

= Plugin-based architecture – Extend and customize backend functionality through a modular plugin system =

'''Description:'''
The plugin-based architecture allows the application server to be extended and customized by dynamically enabling modular plugins. Each plugin encapsulates a specific functionality, such as HTTP handling, authentication, permission management, systemd integration, or debugging tools. This design decouples core server logic from optional features, making it easier to maintain, test, and evolve the system.

'''How it works:'''

# '''Core Server Class''': The main ''Server'' class provides the infrastructure for running the application and managing plugins.
# '''Plugin Registration''': Plugins are registered via a static method, e.g., <code>enablePlugin(pluginClass, options)</code>. This allows the server to load specific functionality only when needed.
# '''Static Initialization''': A '''static block''' in the server class runs once when the class is defined. It is used to register all required plugins. This ensures that the server is fully configured before any instances are created (mostly one).

<pre>
import {Server} from "appserver";

import {AppServerPlugin} from "appserver";
import {SystemdPlugin} from "appserver";
import {HttpPlugin} from "appserver";
import {AuthPlugin} from "appserver";
import {PermPlugin} from "appserver";
import {DebugConsolePlugin} from "appserver";

new (class MyServer extends Server {

static {
MyServer.enablePlugin(SystemdPlugin);
MyServer.enablePlugin(HttpPlugin, {port: 8080, endpoint: /^(?!.*\.jss$).*/, slot: "http_slot00"});
MyServer.enablePlugin(AppServerPlugin);
MyServer.enablePlugin(AuthPlugin);
MyServer.enablePlugin(PermPlugin);
MyServer.enablePlugin(DebugConsolePlugin);
}

constructor(...args) {
super(...args);
}

})();
</pre>

# '''Plugin Isolation and Modularity''': Each plugin is a self-contained module, responsible for a particular aspect of server functionality. The server core interacts with plugins through a defined interface, enabling safe modularity and easy swapping or upgrading of features.
# '''Extensibility''': Developers can create new plugins without modifying the core server code. By simply calling <code>enablePlugin(NewPlugin)</code> in the static block, the new functionality is integrated seamlessly.

'''Benefits:'''
* '''Modular Design''': Features can be added or removed without touching the core logic.
* '''Reusability''': Plugins can be shared between different projects or server instances.
* '''Scalability''': Additional functionality can be loaded dynamically as the application grows.
* '''Maintainability''': Bugs or updates in one plugin do not affect other parts of the system.

Application Server

2025-09-01T21:17:50Z

Guttmann: /* Plugin-based architecture – Extend and customize backend functionality through a modular plugin system */

The FullJS application server provides a robust, modular, and secure foundation for running server-side services. It combines modern architectural principles with deep Linux integration to deliver enterprise-grade capabilitie

= Microservice Architecture =
The FullJS applications server follows a microservice-based server architecture with deep systemd integration. The application server is represented as a Systemd target ([application].target), with each individual microservice corresponding to a systemd unit instance ([application]@[microservice]).

== Adding and Removing Microservices from the Application Server ==

To add a microservice (a.k.a systemd unit instance) to the application server (a.k.a systemd target):

<code>
sudo systemctl enable [application]@[microservice]
</code>

To remove a microservice from the application server group:

<code>
sudo systemctl disable [application]@[microservice]
</code>

''Note:'' Enabling a microservice only registers it with the application server for automatic start at boot. It does **not** start the microservice immediately in the current session.

== Starting and Stopping a Microservice ==
Each microservice runs as a separate systemd unit instance ([application]@[microservice]).
To start a microservice:

<code>
sudo systemctl start [application]@[microservice]
</code>

To stop a microservice:

<code>
sudo systemctl stop [application]@[microservice]
</code>

''Note:'' starting a microservice only affects the current session and does not configure it to start automatically at boot.

== Checking the Status of a Microservice ==
Each microservice runs as a separate systemd unit instance (<code>[application]@[microservice]</code>).

* To check the current status of a microservice instance:

<code>
sudo systemctl status [application]@[microservice]
</code>

This command shows whether the service is running, stopped, or failed, along with recent log entries.

== Starting and Stopping the application server ==
To start the application server use systemd’s start command.

<code>
sudo systemctl start [application].target
</code>

To stop a running application server, you can use:

<code>
sudo systemctl stop [application].target
</code>

Keep in mind that starting an application server only affects the current session and does not configure it to start automatically at boot.

== Enabling and Disabling the application server ==
To start the application server automatically at boot, you must enable it.

To start the application server at boot:

<code>sudo systemctl enable [application].target</code>

To disable the application service from starting automatically:

<code>sudo systemctl disable [application].target</code>

Keep in mind that enabling an application server does not start it in the current session.

= Filesystem Layout =
The application conforms to the Linux Filesystem Hierarchy Standard (FHS). Executables, data, runtime state, and configuration are separated cleanly:

* <code>/srv/fulljs/[instance]/</code> – contains the deployed application
* <code>/run/fulljs/[instance]/**</code> – runtime files (e.g., sockets, PID files)
* <code>/var/lib/fulljs/[instance]/**</code> – persistent state data (e.g., storage files)
* <code>/etc/fulljs/**</code> – configuration files (if any)

= Plugin-based architecture – Extend and customize backend functionality through a modular plugin system =

'''Description:'''
The plugin-based architecture allows the application server to be extended and customized by dynamically enabling modular plugins. Each plugin encapsulates a specific functionality, such as HTTP handling, authentication, permission management, systemd integration, or debugging tools. This design decouples core server logic from optional features, making it easier to maintain, test, and evolve the system.

'''How it works:'''

# '''Core Server Class''': The main ''Server'' class provides the infrastructure for running the application and managing plugins.
# '''Plugin Registration''': Plugins are registered via a static method, e.g., <code>enablePlugin(pluginClass, options)</code>. This allows the server to load specific functionality only when needed.
# '''Static Initialization''': A '''static block''' in the server class runs once when the class is defined. It is used to register all required plugins. This ensures that the server is fully configured before any instances are created (mostly one).

<pre>
import {Server} from "appserver";

import {AppServerPlugin} from "appserver";
import {SystemdPlugin} from "appserver";
import {HttpPlugin} from "appserver";
import {AuthPlugin} from "appserver";
import {PermPlugin} from "appserver";
import {DebugConsolePlugin} from "appserver";

new (class MyServer extends Server {

static {
this.enablePlugin(SystemdPlugin);
this.enablePlugin(HttpPlugin, {port: 8080, endpoint: /^(?!.*\.jss$).*/, slot: "http_slot00"});
this.enablePlugin(AppServerPlugin);
this.enablePlugin(AuthPlugin);
this.enablePlugin(PermPlugin);
this.enablePlugin(DebugConsolePlugin);
}

constructor(...args) {
super(...args);
}

})();
</pre>

# '''Plugin Isolation and Modularity''': Each plugin is a self-contained module, responsible for a particular aspect of server functionality. The server core interacts with plugins through a defined interface, enabling safe modularity and easy swapping or upgrading of features.
# '''Extensibility''': Developers can create new plugins without modifying the core server code. By simply calling <code>enablePlugin(NewPlugin)</code> in the static block, the new functionality is integrated seamlessly.

'''Benefits:'''
* '''Modular Design''': Features can be added or removed without touching the core logic.
* '''Reusability''': Plugins can be shared between different projects or server instances.
* '''Scalability''': Additional functionality can be loaded dynamically as the application grows.
* '''Maintainability''': Bugs or updates in one plugin do not affect other parts of the system.

Application Server

2025-09-01T21:13:29Z

Guttmann: /* Plugin-based architecture – Extend and customize backend functionality through a modular plugin system */

The FullJS application server provides a robust, modular, and secure foundation for running server-side services. It combines modern architectural principles with deep Linux integration to deliver enterprise-grade capabilitie

= Microservice Architecture =
The FullJS applications server follows a microservice-based server architecture with deep systemd integration. The application server is represented as a Systemd target ([application].target), with each individual microservice corresponding to a systemd unit instance ([application]@[microservice]).

== Adding and Removing Microservices from the Application Server ==

To add a microservice (a.k.a systemd unit instance) to the application server (a.k.a systemd target):

<code>
sudo systemctl enable [application]@[microservice]
</code>

To remove a microservice from the application server group:

<code>
sudo systemctl disable [application]@[microservice]
</code>

''Note:'' Enabling a microservice only registers it with the application server for automatic start at boot. It does **not** start the microservice immediately in the current session.

== Starting and Stopping a Microservice ==
Each microservice runs as a separate systemd unit instance ([application]@[microservice]).
To start a microservice:

<code>
sudo systemctl start [application]@[microservice]
</code>

To stop a microservice:

<code>
sudo systemctl stop [application]@[microservice]
</code>

''Note:'' starting a microservice only affects the current session and does not configure it to start automatically at boot.

== Checking the Status of a Microservice ==
Each microservice runs as a separate systemd unit instance (<code>[application]@[microservice]</code>).

* To check the current status of a microservice instance:

<code>
sudo systemctl status [application]@[microservice]
</code>

This command shows whether the service is running, stopped, or failed, along with recent log entries.

== Starting and Stopping the application server ==
To start the application server use systemd’s start command.

<code>
sudo systemctl start [application].target
</code>

To stop a running application server, you can use:

<code>
sudo systemctl stop [application].target
</code>

Keep in mind that starting an application server only affects the current session and does not configure it to start automatically at boot.

== Enabling and Disabling the application server ==
To start the application server automatically at boot, you must enable it.

To start the application server at boot:

<code>sudo systemctl enable [application].target</code>

To disable the application service from starting automatically:

<code>sudo systemctl disable [application].target</code>

Keep in mind that enabling an application server does not start it in the current session.

= Filesystem Layout =
The application conforms to the Linux Filesystem Hierarchy Standard (FHS). Executables, data, runtime state, and configuration are separated cleanly:

* <code>/srv/fulljs/[instance]/</code> – contains the deployed application
* <code>/run/fulljs/[instance]/**</code> – runtime files (e.g., sockets, PID files)
* <code>/var/lib/fulljs/[instance]/**</code> – persistent state data (e.g., storage files)
* <code>/etc/fulljs/**</code> – configuration files (if any)

= Plugin-based architecture – Extend and customize backend functionality through a modular plugin system =

'''Description:'''
The plugin-based architecture allows the backend server to be extended and customized by dynamically enabling modular plugins. Each plugin encapsulates a specific functionality, such as HTTP handling, authentication, permission management, system integration, or debugging tools. This design decouples core server logic from optional features, making it easier to maintain, test, and evolve the system.

'''How it works:'''

# '''Core Server Class''': The main server class provides the infrastructure for running the application and managing plugins. For example, <code>Server</code> in the code acts as the base class.
# '''Plugin Registration''': Plugins are registered via a static method, e.g., <code>enablePlugin(pluginClass, options)</code>. This allows the server to load specific functionality only when needed.
# '''Static Initialization''': A '''static block''' in the server class runs once when the class is defined. It is used to register all required plugins at startup. This ensures that the server is fully configured before any instances are created.

<pre>
import {Server} from "appserver";
import {AppServerPlugin} from "appserver";
import {SystemdPlugin} from "appserver";
import {HttpPlugin} from "appserver";
import {AuthPlugin} from "appserver";
import {PermPlugin} from "appserver";
import {DebugConsolePlugin} from "appserver";

new (class MyServer extends Server {

static {
this.enablePlugin(SystemdPlugin);
this.enablePlugin(HttpPlugin, {port: 8080, endpoint: /^(?!.*\.jss$).*/, slot: "http_slot00"});
this.enablePlugin(AppServerPlugin);
this.enablePlugin(AuthPlugin);
this.enablePlugin(PermPlugin);
this.enablePlugin(DebugConsolePlugin);
}

constructor(...args) {
super(...args);
}

})();
</pre>

# '''Plugin Isolation and Modularity''': Each plugin is a self-contained module, responsible for a particular aspect of server functionality. The server core interacts with plugins through a defined interface, enabling safe modularity and easy swapping or upgrading of features.
# '''Extensibility''': Developers can create new plugins without modifying the core server code. By simply calling <code>enablePlugin(NewPlugin)</code> in the static block, the new functionality is integrated seamlessly.

'''Benefits:'''
* '''Modular Design''': Features can be added or removed without touching the core logic.
* '''Reusability''': Plugins can be shared between different projects or server instances.
* '''Scalability''': Additional functionality can be loaded dynamically as the application grows.
* '''Maintainability''': Bugs or updates in one plugin do not affect other parts of the system.

Application Server

2025-09-01T21:12:31Z

Guttmann: /* Plugin-based architecture – Extend and customize backend functionality through a modular plugin system */

The FullJS application server provides a robust, modular, and secure foundation for running server-side services. It combines modern architectural principles with deep Linux integration to deliver enterprise-grade capabilitie

= Microservice Architecture =
The FullJS applications server follows a microservice-based server architecture with deep systemd integration. The application server is represented as a Systemd target ([application].target), with each individual microservice corresponding to a systemd unit instance ([application]@[microservice]).

== Adding and Removing Microservices from the Application Server ==

To add a microservice (a.k.a systemd unit instance) to the application server (a.k.a systemd target):

<code>
sudo systemctl enable [application]@[microservice]
</code>

To remove a microservice from the application server group:

<code>
sudo systemctl disable [application]@[microservice]
</code>

''Note:'' Enabling a microservice only registers it with the application server for automatic start at boot. It does **not** start the microservice immediately in the current session.

== Starting and Stopping a Microservice ==
Each microservice runs as a separate systemd unit instance ([application]@[microservice]).
To start a microservice:

<code>
sudo systemctl start [application]@[microservice]
</code>

To stop a microservice:

<code>
sudo systemctl stop [application]@[microservice]
</code>

''Note:'' starting a microservice only affects the current session and does not configure it to start automatically at boot.

== Checking the Status of a Microservice ==
Each microservice runs as a separate systemd unit instance (<code>[application]@[microservice]</code>).

* To check the current status of a microservice instance:

<code>
sudo systemctl status [application]@[microservice]
</code>

This command shows whether the service is running, stopped, or failed, along with recent log entries.

== Starting and Stopping the application server ==
To start the application server use systemd’s start command.

<code>
sudo systemctl start [application].target
</code>

To stop a running application server, you can use:

<code>
sudo systemctl stop [application].target
</code>

Keep in mind that starting an application server only affects the current session and does not configure it to start automatically at boot.

== Enabling and Disabling the application server ==
To start the application server automatically at boot, you must enable it.

To start the application server at boot:

<code>sudo systemctl enable [application].target</code>

To disable the application service from starting automatically:

<code>sudo systemctl disable [application].target</code>

Keep in mind that enabling an application server does not start it in the current session.

= Filesystem Layout =
The application conforms to the Linux Filesystem Hierarchy Standard (FHS). Executables, data, runtime state, and configuration are separated cleanly:

* <code>/srv/fulljs/[instance]/</code> – contains the deployed application
* <code>/run/fulljs/[instance]/**</code> – runtime files (e.g., sockets, PID files)
* <code>/var/lib/fulljs/[instance]/**</code> – persistent state data (e.g., storage files)
* <code>/etc/fulljs/**</code> – configuration files (if any)

= Plugin-based architecture – Extend and customize backend functionality through a modular plugin system =

'''Description:'''
The plugin-based architecture allows the backend server to be extended and customized by dynamically enabling modular plugins. Each plugin encapsulates a specific functionality, such as HTTP handling, authentication, permission management, system integration, or debugging tools. This design decouples core server logic from optional features, making it easier to maintain, test, and evolve the system.

'''How it works:'''

# '''Core Server Class''': The main server class provides the infrastructure for running the application and managing plugins. For example, <code>Server</code> in the code acts as the base class.
# '''Plugin Registration''': Plugins are registered via a static method, e.g., <code>enablePlugin(pluginClass, options)</code>. This allows the server to load specific functionality only when needed.
# '''Static Initialization''': A '''static block''' in the server class runs once when the class is defined. It is used to register all required plugins at startup. This ensures that the server is fully configured before any instances are created.

<code>
import {Server} from "appserver";
import {AppServerPlugin} from "appserver";
import {SystemdPlugin} from "appserver";
import {HttpPlugin} from "appserver";
import {AuthPlugin} from "appserver";
import {PermPlugin} from "appserver";
import {DebugConsolePlugin} from "appserver";

new (class MyServer extends Server {

static {
this.enablePlugin(SystemdPlugin);
this.enablePlugin(HttpPlugin, {port: 8080, endpoint: /^(?!.*\.jss$).*/, slot: "http_slot00"});
this.enablePlugin(AppServerPlugin);
this.enablePlugin(AuthPlugin);
this.enablePlugin(PermPlugin);
this.enablePlugin(DebugConsolePlugin);
}

constructor(...args) {
super(...args);
}

})();
</code>

# '''Plugin Isolation and Modularity''': Each plugin is a self-contained module, responsible for a particular aspect of server functionality. The server core interacts with plugins through a defined interface, enabling safe modularity and easy swapping or upgrading of features.
# '''Extensibility''': Developers can create new plugins without modifying the core server code. By simply calling <code>enablePlugin(NewPlugin)</code> in the static block, the new functionality is integrated seamlessly.

'''Benefits:'''
* '''Modular Design''': Features can be added or removed without touching the core logic.
* '''Reusability''': Plugins can be shared between different projects or server instances.
* '''Scalability''': Additional functionality can be loaded dynamically as the application grows.
* '''Maintainability''': Bugs or updates in one plugin do not affect other parts of the system.

Application Server

2025-09-01T21:11:38Z

Guttmann:

The FullJS application server provides a robust, modular, and secure foundation for running server-side services. It combines modern architectural principles with deep Linux integration to deliver enterprise-grade capabilitie

= Microservice Architecture =
The FullJS applications server follows a microservice-based server architecture with deep systemd integration. The application server is represented as a Systemd target ([application].target), with each individual microservice corresponding to a systemd unit instance ([application]@[microservice]).

== Adding and Removing Microservices from the Application Server ==

To add a microservice (a.k.a systemd unit instance) to the application server (a.k.a systemd target):

<code>
sudo systemctl enable [application]@[microservice]
</code>

To remove a microservice from the application server group:

<code>
sudo systemctl disable [application]@[microservice]
</code>

''Note:'' Enabling a microservice only registers it with the application server for automatic start at boot. It does **not** start the microservice immediately in the current session.

== Starting and Stopping a Microservice ==
Each microservice runs as a separate systemd unit instance ([application]@[microservice]).
To start a microservice:

<code>
sudo systemctl start [application]@[microservice]
</code>

To stop a microservice:

<code>
sudo systemctl stop [application]@[microservice]
</code>

''Note:'' starting a microservice only affects the current session and does not configure it to start automatically at boot.

== Checking the Status of a Microservice ==
Each microservice runs as a separate systemd unit instance (<code>[application]@[microservice]</code>).

* To check the current status of a microservice instance:

<code>
sudo systemctl status [application]@[microservice]
</code>

This command shows whether the service is running, stopped, or failed, along with recent log entries.

== Starting and Stopping the application server ==
To start the application server use systemd’s start command.

<code>
sudo systemctl start [application].target
</code>

To stop a running application server, you can use:

<code>
sudo systemctl stop [application].target
</code>

Keep in mind that starting an application server only affects the current session and does not configure it to start automatically at boot.

== Enabling and Disabling the application server ==
To start the application server automatically at boot, you must enable it.

To start the application server at boot:

<code>sudo systemctl enable [application].target</code>

To disable the application service from starting automatically:

<code>sudo systemctl disable [application].target</code>

Keep in mind that enabling an application server does not start it in the current session.

= Filesystem Layout =
The application conforms to the Linux Filesystem Hierarchy Standard (FHS). Executables, data, runtime state, and configuration are separated cleanly:

* <code>/srv/fulljs/[instance]/</code> – contains the deployed application
* <code>/run/fulljs/[instance]/**</code> – runtime files (e.g., sockets, PID files)
* <code>/var/lib/fulljs/[instance]/**</code> – persistent state data (e.g., storage files)
* <code>/etc/fulljs/**</code> – configuration files (if any)

= Plugin-based architecture – Extend and customize backend functionality through a modular plugin system =

'''Description:'''
The plugin-based architecture allows the backend server to be extended and customized by dynamically enabling modular plugins. Each plugin encapsulates a specific functionality, such as HTTP handling, authentication, permission management, system integration, or debugging tools. This design decouples core server logic from optional features, making it easier to maintain, test, and evolve the system.

'''How it works:'''

# '''Core Server Class''': The main server class provides the infrastructure for running the application and managing plugins. For example, <code>Server</code> in the code acts as the base class.
# '''Plugin Registration''': Plugins are registered via a static method, e.g., <code>enablePlugin(pluginClass, options)</code>. This allows the server to load specific functionality only when needed.
# '''Static Initialization''': A '''static block''' in the server class runs once when the class is defined. It is used to register all required plugins at startup. This ensures that the server is fully configured before any instances are created.

<syntaxhighlight lang="javascript">
/* @babel ES2025 */

import Plugin from "plugin";

import {Server} from "appserver";
import {AppServerPlugin} from "appserver";
import {SystemdPlugin} from "appserver";
import {HttpPlugin} from "appserver";
import {AuthPlugin} from "appserver";
import {PermPlugin} from "appserver";
import {DebugConsolePlugin} from "appserver";

new (class MyServer extends Server {

static {
this.enablePlugin(SystemdPlugin);
this.enablePlugin(HttpPlugin, {port: 8080, endpoint: /^(?!.*\.jss$).*/, slot: "http_slot00"});
this.enablePlugin(AppServerPlugin);
this.enablePlugin(AuthPlugin);
this.enablePlugin(PermPlugin);
this.enablePlugin(DebugConsolePlugin);
}

constructor(...args) {
super(...args);
}

})();
</syntaxhighlight>

# '''Plugin Isolation and Modularity''': Each plugin is a self-contained module, responsible for a particular aspect of server functionality. The server core interacts with plugins through a defined interface, enabling safe modularity and easy swapping or upgrading of features.
# '''Extensibility''': Developers can create new plugins without modifying the core server code. By simply calling <code>enablePlugin(NewPlugin)</code> in the static block, the new functionality is integrated seamlessly.

'''Benefits:'''
* '''Modular Design''': Features can be added or removed without touching the core logic.
* '''Reusability''': Plugins can be shared between different projects or server instances.
* '''Scalability''': Additional functionality can be loaded dynamically as the application grows.
* '''Maintainability''': Bugs or updates in one plugin do not affect other parts of the system.

Introduction

2025-09-01T15:42:36Z

Guttmann: /* Backend */

'''FullJS''' is a complete ecosystem for developing and running applications with JavaScript. It brings together an embedded V8 runtime, a robust server-side application server with full Linux and systemd integration, a KDE Plasma-like frontend GUI library, a set of built-in libraries for common development tasks, and a powerful web-based IDE featuring drag-and-drop GUI design.

= JavaScript Runtime =
The runtime is built on the V8 JavaScript engine, designed exclusively for Linux delivering maximum performance, stability, and reliability across a wide range of architectures.

= Application Server =
The application server provides a robust, modular, and secure foundation for running server-side services.
It combines modern architectural principles with deep Linux integration to deliver enterprise-grade capabilities.

Key features include:
* Plugin-based architecture – Extend and customize backend functionality through a modular plugin system.
* Microservice-oriented design – Services are isolated and loosely coupled, making them scalable and maintainable.
* Advanced logging – Structured logging with runtime-configurable log levels.
* JWT-based authentication – Secure, standard-compliant authentication mechanism for microservices.
* Built-in user management – Centralized user handling for authentication.
* ABAC (Attribute-Based Access Control) – Fine-grained permission management based on user attributes and policies.
* Full systemd integration – Each microservice can be managed natively as systemd services (start, stop, reload, status).
* Complete D-Bus integration – Native inter-process communication support for Linux server environments.

= Frontend =
The FullJS frontend is built for **complex, information-driven web applications** rather than content-oriented websites.

Key features include:
* KDE Plasma-inspired look & feel – A modern, desktop-like experience within the browser, including both light and dark color schemes.
* Plugin-based design – Extend the frontend with additional components and modules.
* Core GUI controls – Buttons, icons, dialogs, and essential widgets for building application interfaces.
* Integrated third-party libraries – Support for advanced tools such as Chart.js for charts and Leaflet for maps and geospatial visualization.

= Built-In Libraries =
FullJS includes a set of built-in JavaScript and native libraries to simplify common development tasks.
Examples of core libraries include:
* File system access (`fs`) – Fully asynchronous I/O powered by Linux `io_uring` for high-performance file operations.
* Thread management (`Worker`) – Manage concurrent tasks efficiently.
* Networking (`Socket`, `http`) – Build robust server and client network applications.
* GUI elements for web-based apps – Buttons, icons, dialogs, and other essential widgets.
* Charts and data visualization (`ChartJS`) – Visualize data directly in your application.
* Logging utilities (`console`) – Structured logging with configurable log levels for easy debugging and monitoring.

These libraries allow developers to build complex applications with minimal effort, while taking full advantage of FullJS's high-performance runtime and system integration.

= Web IDE =
A web-based Integrated Development Environment (IDE) for creating and managing applications.
It enables development of both '''client-side''' and '''server-side''' code.
While the backend requires Linux, client-side applications run in any modern browser (e.g., Google Chrome), making your apps accessible to everyone.

= Get Started =
To begin using FullJS, explore the following pages:
* [[Getting Started]]
* [[Architecture]]
* [[Libraries]]
* [[Tutorials]]

Introduction

2025-09-01T15:42:02Z

Guttmann: /* Runtime */

'''FullJS''' is a complete ecosystem for developing and running applications with JavaScript. It brings together an embedded V8 runtime, a robust server-side application server with full Linux and systemd integration, a KDE Plasma-like frontend GUI library, a set of built-in libraries for common development tasks, and a powerful web-based IDE featuring drag-and-drop GUI design.

= JavaScript Runtime =
The runtime is built on the V8 JavaScript engine, designed exclusively for Linux delivering maximum performance, stability, and reliability across a wide range of architectures.

= Backend =
The FullJS backend provides a robust, modular, and secure foundation for running server-side services.
It combines modern architectural principles with deep Linux integration to deliver enterprise-grade capabilities.

Key features include:
* Plugin-based architecture – Extend and customize backend functionality through a modular plugin system.
* Microservice-oriented design – Services are isolated and loosely coupled, making them scalable and maintainable.
* Advanced logging – Structured logging with runtime-configurable log levels.
* JWT-based authentication – Secure, standard-compliant authentication mechanism for microservices.
* Built-in user management – Centralized user handling for authentication.
* ABAC (Attribute-Based Access Control) – Fine-grained permission management based on user attributes and policies.
* Full systemd integration – Each microservice can be managed natively as systemd services (start, stop, reload, status).
* Complete D-Bus integration – Native inter-process communication support for Linux server environments.

= Frontend =
The FullJS frontend is built for **complex, information-driven web applications** rather than content-oriented websites.

Key features include:
* KDE Plasma-inspired look & feel – A modern, desktop-like experience within the browser, including both light and dark color schemes.
* Plugin-based design – Extend the frontend with additional components and modules.
* Core GUI controls – Buttons, icons, dialogs, and essential widgets for building application interfaces.
* Integrated third-party libraries – Support for advanced tools such as Chart.js for charts and Leaflet for maps and geospatial visualization.

= Built-In Libraries =
FullJS includes a set of built-in JavaScript and native libraries to simplify common development tasks.
Examples of core libraries include:
* File system access (`fs`) – Fully asynchronous I/O powered by Linux `io_uring` for high-performance file operations.
* Thread management (`Worker`) – Manage concurrent tasks efficiently.
* Networking (`Socket`, `http`) – Build robust server and client network applications.
* GUI elements for web-based apps – Buttons, icons, dialogs, and other essential widgets.
* Charts and data visualization (`ChartJS`) – Visualize data directly in your application.
* Logging utilities (`console`) – Structured logging with configurable log levels for easy debugging and monitoring.

These libraries allow developers to build complex applications with minimal effort, while taking full advantage of FullJS's high-performance runtime and system integration.

= Web IDE =
A web-based Integrated Development Environment (IDE) for creating and managing applications.
It enables development of both '''client-side''' and '''server-side''' code.
While the backend requires Linux, client-side applications run in any modern browser (e.g., Google Chrome), making your apps accessible to everyone.

= Get Started =
To begin using FullJS, explore the following pages:
* [[Getting Started]]
* [[Architecture]]
* [[Libraries]]
* [[Tutorials]]

Application-server

2025-09-01T15:39:00Z

Guttmann: Guttmann moved page Application-server to Application Server over redirect

#REDIRECT [[Application Server]]

Application Server

2025-09-01T15:39:00Z

Guttmann: Guttmann moved page Application-server to Application Server over redirect

Application Server

2025-09-01T15:37:47Z

Guttmann: Guttmann moved page Application Server to Application-server

MediaWiki:Sidebar

2025-09-01T15:34:41Z

Guttmann:

Backend

2025-09-01T15:33:45Z

Guttmann: Guttmann moved page Backend to Application Server

#REDIRECT [[Application Server]]

Application Server

2025-09-01T15:33:45Z

Guttmann: Guttmann moved page Backend to Application Server

MediaWiki:Sidebar

2025-09-01T15:33:05Z

Guttmann:

MediaWiki:Sidebar

2025-09-01T15:32:41Z

Guttmann:

MediaWiki:Sidebar

2025-09-01T15:31:24Z

Guttmann:

MediaWiki:Sidebar

2025-09-01T15:30:28Z

Guttmann:

Runtime

2025-09-01T15:29:41Z

Guttmann: Guttmann moved page Runtime to JavaScript Runtime

#REDIRECT [[JavaScript Runtime]]

JavaScript Runtime

2025-09-01T15:29:41Z

Guttmann: Guttmann moved page Runtime to JavaScript Runtime

Built on the V8 JavaScript engine, using a single-threaded event loop with non-blocking I/O for main execution, and supporting optional Worker threads for parallel tasks.

= Supported operating systems =
FullJS is designed to run exclusively on Linux-based systems.
* '''Debian''' 12 or newer
* '''Ubuntu''' (and other Debian-based derivatives)

A working '''systemd''' installation is required, as the runtime integrates with systemd for service management.

= Supported architectures =
* amd64
* arm64
* riscv64
* arm

= Event System =
* Uses '''epoll''' as the backend event notification facility for scalable, high-performance I/O.
* Optimized for large numbers of concurrent I/O operation.

= Module System =
* Supports only ES6 import/export syntax.
* Supports .js modules and native .so modules

= Global Scope =
Default global scope mimics a Web API-like environment but only relevant server-side features are exposed:
* Events (Event, EventTarget, CustomEvent)
* Timers (setTimeout, setInterval, etc.)
* Console (Console, console.log, console.error)
* Base64 utilities (atob, btoa)
* Encoding (TextEncoder, TextDecoder)
* Storage API (Storage, localStorage, sessionStorage)
* URL API (URL, URLSearchParams)
* Fetch API (fetch, Response, Request)
* Web Crypto API (crypto.getRandomValues, subtle.digest)
* Streams API (ReadableStream, WritableStream, TransformStream)
* Web Workers (Worker)
* Performance (performance.now)
* AbortController, AbortSignal
* DOMException

= Directory Structure =
FullJS follows the Linux Filesystem Hierarchy Standard (FHS) with specific locations for binaries, libraries, modules, and JavaScript files:

* '''/usr/bin/''' – FullJS JavaScript binary (js), V8 snapshot (snapshot_blob.bin), and ICU data file (icudtl.dat)
* '''/usr/lib/fulljs/''' – V8 shared libraries (e.g., libv8.so)
* '''/usr/lib/fulljs_modules/''' – Dynamically loadable native .so C++ modules (e.g., fs, process, v4l2, etc.)
* '''/usr/lib/fulljs_scope/''' – JavaScript file defining the default scope (e.g. globalscope.js, workerglobalscope.js)
* '''/usr/share/javascript/fulljs/''' – Dynamically loadable .js JavaScript modules (e.g., path, Dialog, etc.)

MediaWiki:Sidebar

2025-09-01T15:26:25Z

Guttmann:

Application Server

2025-09-01T15:22:29Z

Guttmann:

Application Server

2025-09-01T15:21:35Z

Guttmann: /* Filesystem Layout */