Architecture

Before you start developing the application learn more about the architecture of Advanced REST CLient

ARC is built with Electron and web platform technologies. The user interface and most of the application logic is composed of a number of web components. The components are split functionally in the github.com/advanced-rest-client organization. The arc-electron repository is a shell application that bundles the components and provides platform (Electron) specific bindings like persistence layer, file system access, update service, and more. You can learn more about the the architecture for salable application in this Medium article.

Electron architecture

The best place to start is to explore Electron documentation. We won't be repeating their docs. Instead we focus on ARC's specific implementation.

Custom protocol in the renderer process

ARC's UI is built with web component, which are, by the specification, an ECMAScript modules. To run a web module in the renderer process the server (in this case Electron's implementation of it) that serves the modules must return the application/javascript content type. Electron doesn't add mime types for files in the application sources. Because of that, modules cannot run natively in an Electron application. Moreover, to import another module in a module it must use relative or absolute paths (staring with . or /). The industry standard, however, is to point to an NPM module without resolving paths. This results with a different approach in ARC: to use the protocol handlers. The application internally registers a custom scheme (web-module:) for loading files. When the file is being loaded the handler resolves the path to the module (in order: ./src/, ./web_modules/, and node_modules ) and returns the file content with a proper mime type. See src/io/EsmProtocol.js for detailed implementation.

The page loading process is managed by the src/io/WindowsManager.js which takes care of the proper scheme when loading files.

Node integration

For added security the node integration is disabled in the renderer process. To walk around this, ARC registers a preload script, which is executed before the window is loaded. This script has full node and file system access. Inside this script we create interfaces and proxies the application uses to run node modules or to communicate with the main (IO) process. All preload proxies and interfaces are located in the src/preload folder.

For example, the GoogleDriveProxy class allows to perform few operations like listing application folder, getting a file, or storing a file on Google Drive. This proxy just passes data to the main process which performs the authentication and the actual operation. This creates a security layer so external script loaded in the renderer process don't have access to all APIs.

The web_modules directory

Instead of resolving paths in a module ARC uses the @pika/web project (now it's snowflake) to resolve and cache modules in a very accessible way. This requires additional step of configuring the package.json file and the @pika/web.webDependencies entry adding each script to the build process. When the npm i script runs it also run the prepare script that eventually runs pika-web CLI tool. In the renderer process we don't point to node_modules but directly to the files in the web_modules directory. In fact most UI dependencies are installed in the dev dependencies which means they are not included in the final build of the application.

ARC components

The UI and most of the logic is not located in the electron application but in the ARC web components. This is done to enable sharing the UI and the logic with other projects. 99% of the application logic and the UI is located in these components. Depending on which part you want to change you have to find the corresponding component in the ARC's organization.

This document will be updated to add more details about the components architecture.