echolon - Moses Yebei

Abstract

A powerful, local-first API client with Git integration, offline support, and multi-protocol capabilities. Open source alternative to Postman.

The Problem

Developers need a self‑hosted API client that works offline, integrates with Git for version‑controlled collections, and supports multiple protocols (HTTP, WebSocket, etc.). Existing tools (Postman, Insomnia) rely on cloud sync or lack deep Git integration, forcing teams to manage request definitions manually.

What This Does

echolon is an Electron‑based desktop app that stores collections, environments, and request history locally (see core/main/fileStorage.ts). Git operations (clone, commit, push) are wrapped in core/main/git.ts, letting teams treat their workspace like any other code repo. The UI lives in core/renderer/ – for example core/renderer/App.tsx boots the React tree, while core/renderer/components/panels/CenterPanel/ResponseViewer.tsx renders responses with syntax highlighting.

Importers (core/renderer/services/SpecImporter.ts) can ingest OpenAPI or Postman files, turning them into native collections. Request execution is handled by core/renderer/services/RequestService.ts (function execute), which builds a request (buildUrl, buildHeaders, buildBody) and dispatches it via the Electron‑provided browserFetch bridge.

How It Is Wired

Entry point – The Electron main process starts at core/main/index.ts (line 28). It creates the app window, registers IPC handlers (preload.ts), and calls init in core/main/git.ts (line 103) to initialise the Git client and local storage.

Core flow for a request

UI component (RequestCard.tsx) triggers useRequest → execute (core/renderer/services/RequestService.ts:379).
execute calls buildUrl, buildHeaders, buildBody (each referenced >30 times across the codebase).
The assembled request is sent through the Electron bridge to browserFetch, which ultimately invokes the native fetch API (network outbound).

Filesystem interaction – core/main/fileStorage.ts (75 functions) is the only module that reads/writes persisted data (e.g., writeJsonFile during init). Calls to it originate from 14 other files, making it a high‑blast‑radius storage hub.

Git integration – core/main/git.ts (28 functions) performs network calls (git.fetch) and file writes (repo init). It is imported by 9 modules, so any change here impacts version‑control features across the app.

Service hubs – The import graph shows three highly unstable modules:

core/renderer/components/ui/index (imports 25 others, instability 0.96)
core/renderer/services/index (imports 18, instability 0.95)
core/renderer/contexts/index (imports 15, instability 0.94)

These act as “hub” modules; modifications ripple widely and increase merge risk.

Unmapped wiring – No circular dependencies were detected, but many UI panels (e.g., ResponseViewer.tsx, RequestCard.tsx) exhibit deep nesting (up to 10 levels) and oversized files (over 1500 lines), which hampers readability and future refactoring.

How To Use It

# Clone the repo
git clone https://github.com/moses-y/echolon
cd echolon/core

# Install dependencies (Node 18+ required)
npm install

# Run the development server (Electron window)
npm run dev

To build distributables:

# All platforms
npm run package:all

# macOS only
npm run package:mac

No additional configuration files are required for a basic run. Optional code‑signing variables are documented in the README (e.g., CSC_LINK, CSC_KEY_PASSWORD).

Real‑World Use

A team stores its collection JSON in a Git repo (/my-workspace). Each developer runs the Electron app, edits requests, and commits changes via the built‑in Git UI. Because the data lives locally, work continues offline; once back online, git push synchronises the collection with teammates, preserving a full history of request evolution.

Code Health & Issues

High – CI missing – 205 source files, no GitHub Actions workflow.
Medium – Dependabot absent – 5 manifest files, no update bot.
Medium – Large binaries – core/tests/GitHub v3 REST API.postman_collection.json (9 MB) and Asana.postman_collection.json (6.7 MB) should be moved to Git LFS or external storage.
Medium – Test coverage – 1 test file vs 205 source files (0.5 % coverage).
Low – Repository conventions – No .editorconfig, .gitattributes, or formatter config.

The Bottom Line

echolon delivers a fully local, Git‑backed API client with a rich Electron UI, but the codebase suffers from high cognitive load (deeply nested, oversized components) and minimal automation (no CI, sparse tests). It is suitable for teams comfortable managing a monolithic Electron project and willing to invest in refactoring and CI setup.

What the analyser found

Deployment readiness

5/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

367 files

TypeScript123
TSX87
CSS65
JSON20
HTML6
Shell5

React

Architecture

Top-level areas of the codebase, sized by module count. Arrows show how many imports cross from one area into another.

graph TD g0["core<br/>194 modules"] g1["docs<br/>10 modules"] g2["sample-api<br/>9 modules"] g3["web<br/>2 modules"] g3 -->|9| g0

Module dependencies

The 10 most depended-upon modules of 215, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_core_shared_constants["constants"] n1_erer_contexts_WebModeContext["WebModeContext"] n2_core_shared_echoFormat["echoFormat"] n3_er_contexts_WorkspaceContext["WorkspaceContext"] n4__contexts_FileStorageContext["FileStorageContext"] n5_core_shared_ipc_channels["ipc-channels"] n6_s_CenterPanel_ResponseViewer["ResponseViewer"] n7_r_contexts_DataLoaderContext["DataLoaderContext"] n8__contexts_CollectionsContext["CollectionsContext"] n9_contexts_EnvironmentsContext["EnvironmentsContext"] n8__contexts_CollectionsContext --> n3_er_contexts_WorkspaceContext n8__contexts_CollectionsContext --> n7_r_contexts_DataLoaderContext n8__contexts_CollectionsContext --> n1_erer_contexts_WebModeContext n8__contexts_CollectionsContext --> n4__contexts_FileStorageContext n7_r_contexts_DataLoaderContext --> n0_core_shared_constants n7_r_contexts_DataLoaderContext --> n1_erer_contexts_WebModeContext n7_r_contexts_DataLoaderContext --> n4__contexts_FileStorageContext n9_contexts_EnvironmentsContext --> n7_r_contexts_DataLoaderContext n9_contexts_EnvironmentsContext --> n1_erer_contexts_WebModeContext n9_contexts_EnvironmentsContext --> n4__contexts_FileStorageContext n4__contexts_FileStorageContext --> n1_erer_contexts_WebModeContext n3_er_contexts_WorkspaceContext --> n0_core_shared_constants n3_er_contexts_WorkspaceContext --> n7_r_contexts_DataLoaderContext n3_er_contexts_WorkspaceContext --> n1_erer_contexts_WebModeContext n3_er_contexts_WorkspaceContext --> n4__contexts_FileStorageContext n0_core_shared_constants --> n5_core_shared_ipc_channels

Findings

MediumNo CI/CD pipeline detected - no automated build/test gate .github/ or CI config

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high1

medium3

low1

Add a workflow that builds and tests this repositoryhigh

205 source files, no CI configuration

Every change merges with nobody having run the build once, which across this estate is 499 repositories.

Fix: Add a workflow running the project build and test command on push and pull_request.

Enable Dependabot or Renovatemedium

5 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Move large binaries to Git LFS or out of the repositorymedium2 occurrences

core/tests/GitHub v3 REST API.postman_collection.json

2 blobs over 5MB: GitHub v3 REST API.postman_collection.json 9.0MB, Asana.postman_collection.json 6.7MB

One repository here carries twenty blobs over 5MB including a 10.9MB spreadsheet, so every clone and every CI checkout pays for data nobody diffs.

Fix: Track those extensions with LFS, or move datasets to object storage and fetch them in a setup step.

Expand the test suite; it cannot cover this codebasemedium

1 test files against 205 source files (ratio 0.005)

A reviewer reads "has tests" and assumes a safety net that covers two files out of eighty-five, which is how untested paths ship behind a green badge.

Fix: Add tests for the highest fan-in modules first.

Add the repository convention files this project lackslow3 occurrences

missing .editorconfig, .gitattributes, a formatter config

Without them one contributor's editor writes tabs into a Python file, a shell script commits with CRLF and fails in the container, and a notebook diff is unreviewable.

Fix: Add .editorconfig, .gitattributes with text=auto eol=lf, and a formatter config.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.