# Architecture

The Nano client is made up of several processes working together.
Each component is dedicated to fulfilling a specific set of tasks.

## Components

This is a short overview of the components, presented in a logical order of dependencies and responsibilities.

### Core process

This process is the one to start first and will setup all the other processes and services. During its lifetime
it will also check on the spawned subprocesses if they are still alive and working as needed.

It is also the communication hub that facilitates dynamic service/process discovery. Tightly coupled subprocesses
communicate directly with the hub using authenticated sockets. This makes it possible for all the components to be
dynamically configured even though they are dependant on one-another. In particular this is extraordinarily useful to
avoid having static resource allocations as dependencies. (like specific port assignments)

Subprocesses that can no longer reach the core process shall terminate asap. The core will also track the
subprocesses in a platform independent way and also issue termination commands.

The managed subprocesses shall be extensible so optionally (maybe platform dependant) extra processes can be
easily added. For example a user-interface process to manage the config without editing the config files.

### Solr process
*Dependency of the indexer and server.*

For the search functionality a simple solr instance is used. Initial configurations are managed by the core. For
example the used port will be selected by the core, so it can be included in the configuration for other processes.

The index core and the schema are managed by the indexer.

### Tika process
*Dependency of the indexer.*

This is the content extractor that processes the different kinds of documents to be indexed for search. It is
managed similarly to the Solr process.

### Indexer process

The indexer will scrape the designated locations from config and synchronize their content into the solr database.
This system has to be resilient. The indexed contents must eventually converge to the actual contents of the source
locations. It cannot be expected from the user to only change contents when the indexer is alive (so filesystem
events may be acted upon). The indexer will always look through all contents recursively in the source locations to
check for changes at startup. It may also repeat the full-scrape periodically. It will also utilize FS event
listeners where possible for low-latency updates. The resource usage of the polling update scrapes will be highly
configurable and they shall have sane defaults that yield optimal tradeoffs generally. An interrupted scrape shall
be resumed when the process is re-started.

When configurations affecting the solr schema/core change, this process will make sure they are applied to the solr
instance.

### Gateway process
*Dependency of the server.*

This is the process that will connect to the Clarabot servers, authenticate and listen for remote requests.
The goal of this component is primarily to manage the connection to the servers and validate incoming requests to
the group policies of the assigned resource from the server adhering to optional overrides from local config.

Administrative requests (if allowed) are passed to the core process to change the config for example.

Content access requests are passed to the server processes.

### Server process

This process is a scalable worker process that connects to the gateway and awaits requests.

The only job of these is to execute requests, which may be queries to the solr instance or file listing, reading, etc.
At this point each request will be validated by the gateway so only the local policies need to be enforced. Such as
valid locations for access (not outside of configured sources), etc.
