Application Server

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

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

Starting and Stopping a the application server

To start the application server use systemd’s start command. If you are running as a non-root user, you will have to use sudo since this will affect the state of the operating system:

sudo systemctl start [application].target

To stop a running application server, you can use:

sudo systemctl stop [application].target

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 a the application server

The above commands are useful for starting or stopping an application server during the current session. To tell systemd to start the application server automatically at boot, you must enable it.

• To start the application server at boot:

sudo systemctl enable [application].target

• To disable the application service from starting automatically:

sudo systemctl disable [application].target

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

Adding microservice to the application

Each microservice runs independently, and the target manages the group as a whole. Instances can be attached to the target using **drop-in configuration files**, without modifying the target unit itself.

To attach microservice instances to the application target, you can create drop-in files under:

/etc/systemd/system/[application].target.d/

The drop-in file should define the instance the target should manage using the `[Unit]` section and `Wants=`:

[Unit]
Wants=[application]@[microservice].service

This approach has several benefits:

• The target unit file itself remains minimal and clean.
• Each microservice instance is plugged in modularly via its own drop-in file.
• Adding a new microservice only requires creating a new drop-in file.
• Removing a microservice only requires deleting its drop-in file.
• Starting the target starts all attached instances, stopping the target stops all attached instances.
• If an individual microservice stops or crashes, the target remains running, because Wants= is a soft dependency.

After adding or modifying drop-ins, reload systemd:

sudo systemctl daemon-reload

Starting and Stopping a Microservice Instance

Each microservice runs as a separate systemd unit instance ([application]@[microservice]). To start a microservice:

sudo systemctl start [application]@[microservice]

To stop a microservice:

sudo systemctl stop [application]@[microservice]

As with the application server, starting a microservice instance only affects the current session and does not configure it to start automatically at boot.

Enabling and Disabling a Microservice Instance

To configure a microservice to start automatically at boot, you can enable it.

• To start a microservice instance at boot:

sudo systemctl enable [application]@[microservice]

• To disable a microservice instance from starting automatically:

sudo systemctl disable [application]@[microservice]

Keep in mind that enabling a microservice 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:

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

Managing the FullJS Application Server

Starting and Stopping

To start the FullJS server use systemd’s start command. If you are running as a non-root user, you will have to use sudo since this will affect the state of the operating system:

sudo systemctl start fulljs@[instance]

To stop a running FullJS server, you can use:

sudo systemctl stop fulljs@[instance]

Enabling and Disabling Services

The above commands are useful for starting or stopping FullJS during the current session. To tell systemd to start FullJS server automatically at boot, you must enable it.

• To start the server at boot:

sudo systemctl enable fulljs@[instance]

• To disable the service from starting automatically:

sudo systemctl disable fulljs@[instance]

Keep in mind that enabling a service does not start it in the current session. If you wish to start the service and enable it at boot, you will have to issue both the start and enable commands.

Checking Status

To check the status of the server on your system, you can use the status command:

systemctl status fulljs@[instance]

This will provide you with the server state.

Customizing and Re-branding

You can rebrand FullJS to fit your project name. For example, if your app is called myapp, you can define services like:

systemctl start myapp@microservice1
systemctl start myapp@microservice2

Example Unit File

[Unit]
Description=myapp service
After=network.target auditd.service haproxy.service

[Service]
Type=notify
User=myapp
Group=myapp
RuntimeDirectory=%p/%i
StateDirectory=%p/%i
ExecStart=/usr/bin/fulljs /srv/%p/%i.jss
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=always
WatchdogSec=30
Environment="DBUS_NAME=com.mydomain.%p.%i"

[Install]
WantedBy=multi-user.target

This way, your services become first-class, brand-aligned components of your Linux environment, while keeping all the benefits of FullJS’s microservice infrastructure.