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-electronrepository 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.
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
/). 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:
node_modules) and returns the file content with a proper mime type. See
src/io/EsmProtocol.jsfor detailed implementation.
The page loading process is managed by the
src/io/WindowsManager.jswhich takes care of the proper scheme when loading files.
For added security the node integration is disabled in the renderer process. To walk around this, ARC registers a
preloadscript, 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
preloadproxies and interfaces are located in the
For example, the
GoogleDriveProxyclass 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.
Instead of resolving paths in a module ARC uses the
@pika/webproject (now it's snowflake) to resolve and cache modules in a very accessible way. This requires additional step of configuring the
package.jsonfile and the
@pika/web.webDependenciesentry adding each script to the build process. When the
npm iscript runs it also run the
preparescript that eventually runs
pika-webCLI tool. In the renderer process we don't point to
node_modulesbut directly to the files in the
web_modulesdirectory. In fact most UI dependencies are installed in the dev dependencies which means they are not included in the final build of the application.
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.