Arcentry - Backend Architecture Overview
This guide is targeted towards developers working with Arcentry's code-base. If you are an end-user, please consult the REST-API and Api-Docs documentation instead. If you are an enterprise customer, please find information in the Enterprise section of the documentation.
Arcentry provides REST endpoints through a low-level HTTP server, written in Express. Arcentry's backend consciously avoids higher level MVC paradigms or ORM layers for performance reasons. It instead relies on PL/pgSQL scripts, running directly on the underlying PostgreSQL database to ensure speedy processing.
Arcentry was originally written as a serverless app, running on AWS Lambda. The on-premise/enterprise version serves the same endpoints locally and provides certain wrappers to ensure compatibility with HTTP traffic coming from AWS API Gateway.
Process Request Function and Request Context
Every incoming request is initially processed by a function called processRequest(). This function executes all generic checks, e.g. is the user authenticated, does the incoming data adhere to a given schema, is a publish-subscribe endpoint or database connection required etc...
Once these checks have passed, the actual request handler is invoked with a RequestContext object. This object contains access to the request and user data and offers database and HTTP handling functionality specific to this request.
Authentication
Arcentry supports multiple authentication strategies, such as internal auth, webhook auth via a remote server, or integration with Azure Active Directory.
Each auth-strategy has to implement an authenticateUser() function and register with the AuthStrategy handler (arc-enterprise\src\auth-strategies), which will forward incoming requests and handle the returns.
Access Control
Arcentry's backend applies multiple layers of access checks:
- Session Checks: The majority of Arcentry's services are restricted to authenticated users with an active session. To restrict a request endpoint to authenticated users, set requiresSession: true in the processRequest definition.
- API Key checks: API endpoints are protected by an API Key. To validate this key, use shared.checkApiKey() within the request handler.
- Permission Checks: Arcentry comes with a powerful groups and permission framework. To ensure that the current user has a given permission, use r.accessControl.checkPermission from the request context or public.get_permissions() within an SQL statement.
Publish-Subscribe Messaging
Arcentry's backend also serves persistent WebSocket/HTTP Long-Polling connections via socket.io. The socket.io server sits on top of the regular HTTP server and reuses the same host and port for HTTP traffic and Websocket connections alike.
Building Arcentry Enterprise
Arcentry Enterprise uses pkg to bundle both frontend and backend into a single executable. The frontend is compiled and important by running import-frontend.sh in the main folder. Executables are compiled via build-all-executables.sh for Mac, Linux, and Windows or build-windows-executable.sh to build just the Windows executable.
External Dependencies
Arcentry's backend relies on a PostgreSQL database to store its data. Optionally, it can also connect to a Chrome or Chromium instance using Google's Puppeteer Library. To run as a Service, Arcentry relies on NSSM that's shipped together with the project.
Testing
To run tests against Arcentry's backend, run npm test in the arc-enterprise directory. Please note - some tests require a Google Chrome installation at C:\Program Files (x86)\Google\Chrome\Application\chrome.exe - you can change this path in test\test-tools\browser.js.