Perspectives Technical Documentation

2.5. Actual architecture and underlying technologies

Now let’s concentrate on the concrete architecture and the languages / systems involved in building the PDR.

The core of the PDR is written in the Purescript language and compiled to Javascript. Purescript is a strict (non-lazy) variant of Haskell. The user interface consists of HTML screens, (currently, but not necessarily) written in terms of ReactJS (which is more Javascript, HTML and CSS).

The architecture consists of three components:

the client (an HTML viewer)
the PDR
a private database (either Couchdb or the browser’s IndexedDB)

See the diagram below.

Figure 1. Application layer, React data containers and Javascript API proxy library form the client. The PDR runs in a SharedWorker. The client connects to the Distributed Runtime via window.postMessage. The PDR connects to Couchdb via HTTPS. Yellow components are ‘propriety’ (but open source). The Application Layer consists of models in PL and React-based screens. They are ‘apps’ that are ‘hosted’ in MyContexts, the end user framework program (the name of the entire ensemble).

All run on the end users' node (laptop, desktop; in the future, tablet & mobile phone too).

The PDR connects to the client through the window.postMessage method in the browser.

Both client and PDR access Couchdb over HTTPS; the latter for data and models, the former for screens (associated with a model as attachments).

Notice that, if the private database is IndexedDB, the PDR does not connect through HTTPS to it but through API calls. This holds for screens and models, too.

PDR and client both run in the browser: the PDR in a SharedWorker, the client in a window or tab in a window .

PDRs exchange information and do so exclusively through the Advanced Message Queuing Protocol (AMQP). When two PDRs are connected, they have each other’s message queue address, to which both can post Transactions (a package of Deltas on the primary data). To prevent misunderstanding: only Deltas are communicated, never the primary data itself. Neither is the actual local data storage used by the PDR ever modified by any other process than the PDR itself.

To connect, two installations need each other’s message queue address, requiring IP address, port and a user account on the AMQP server. This server is considered to be outside the Perspectives system (e.g. RabbitMQ).

Finally. A node supports more than a single user. Each user has an account that is (currently) password protected. This account maps one to one to a Couchdb admin account for the relevant databases (a data database, a models database and a post database), or to a set of tables in IndexedDB.

The installing user must have a database admin account with the Couchdb installation. Currently, the local account administration used by the login screen is kept in files in an IndexedDB database ('localusers'). It is accessible to processes in the https://mycontexts.com domain.