Electron 애플리케이션은 일반적으로 렌더러 프로세스에 특권 Electron API에 대한 액세스 권한을 부여하기 위해 사전 로드 스크립트를 사용합니다. 그러나 Notifio의 메인 창은 이러한 접근 방식을 피하고 노드 통합 및 컨텍스트 격리를 비활성화합니다. 대신 렌더러는 메인 프로세스 내에서 실행되는 로컬 HTTP 서버에서 제공하는 표준 웹 페이지로 취급됩니다. 이 서버는 UI와 애플리케이션의 모니터링 로직 간의 완전한 인터페이스를 형성하는 28개의 라우트를 노출합니다.이러한 아키텍처 선택은 여러 요인에 의해 주도되었습니다. 첫째, 렌더러는 실제로 웹 앱처럼 작동하며 표준 웹 기술로 구축되었고 Electron을 인식하지 못합니다. 둘째, HTTP를 사용하면 CRUD 작업과 같은 API 상호 작용에 대한 구조화되고 기존의 어휘를 제공하여 사용자 지정 IPC 채널에 필요한 지속적인 설계 노력을 피할 수 있습니다. 셋째, 렌더러를 자주 다시 로드하는 메인 창의 일회성 특성은 HTTP API를 통해 UI가 각 로드 시 상태를 쉽게 다시 빌드할 수 있습니다.실시간 업데이트는 푸시 메커니즘 대신 이러한 HTTP 라우트를 폴링하여 처리됩니다. 메인 프로세스 내에 서버를 배치하면 직렬화 경계와 별도의 프로세스 관리의 필요성이 제거되어 작동이 단순화됩니다. 이 로컬 HTTP API에 대한 인증은 루프백 인터페이스에만 바인딩하여 외부 네트워크 액세스를 방지함으로써 강제됩니다.HTTP 서버는 깔끔한 분리를 제공하지만, 사용자 로그인을 위한 새 브라우저 창 열기와 같은 특정 Electron 관련 기능은 소규모 인프로세스 브리지를 통해 관리됩니다. 이 브리지를 통해 라우트 핸들러는 서버 모듈 자체가 Electron을 가져오지 않고도 Electron 종속 작업을 위임할 수 있습니다. 이 HTTP 중심 설계의 유일한 예외는 사전 로드 스크립트와 IPC를 사용하는 레코더 창입니다. 이는 타사 사이트를 로드하고 페이지 상호 작용을 관찰해야 하므로 샌드박스 환경 내의 사전 로드 스크립트에 더 적합한 작업이기 때문에 필요합니다. 여기서 차이점은 렌더러가 앱을 쿼리할 때는 HTTP를 사용하고, 외부 페이지를 관찰할 때는 사전 로드/IPC를 사용한다는 것입니다.