# Architecture 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](https://pawelpsztyc.medium.com/composable-applications-with-web-components-ebe5158387be). ## Electron architecture The best place to start is to explore [Electron documentation](https://www.electronjs.org/docs). 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](https://www.electronjs.org/docs/api/protocol). 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](https://www.snowpack.dev/)) 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.advancedrestclient.com/arc-development/architecture.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.