DEV Community

Agrzam
Agrzam

Posted on

I'm building an open source API workspace that syncs with your backend automatically — and I need contributors

#opensource #webdev #beginners #node

Every team I've worked with has the same problem. The backend developer finishes a new endpoint. What happens next is painful.

Backend dev → Slack message
→ Frontend copies it into Postman manually
→ Auth fails → Asks backend again
→ Endpoint changes next day → Nobody notified
→ Frontend breaks → Blame starts
Enter fullscreen mode Exit fullscreen mode

This happens on every team that builds software. It wastes hours every week. And every existing tool — Postman, Bruno, Insomnia, Hoppscotch — requires you to maintain collections manually. The backend changes. The tool doesn't know.

So I started building Agrzam 🦁 — an open source collaborative API workspace that stays in sync with your backend automatically.

The idea

Instead of manually creating and updating API collections, Agrzam reads the OpenAPI spec your framework already generates. No code changes. No custom parsers. No framework lock-in.

Your backend (any port)
    ↓  already generating OpenAPI JSON
@agrzam/apiwatch
    ↓  watches openapi.json on server start
    ↓  detects any change instantly
Agrzam platform
    ↓  WebSocket push
Your workspace ← live endpoint cards
Enter fullscreen mode Exit fullscreen mode

When your backend adds a new endpoint — the workspace updates. When an endpoint changes — the card updates. Your teammate opens the workspace and sees the same live state you do.

Three commands. Setup done forever. 

# Install once
npm install @agrzam/apiwatch

# Connect your account — once per machine
agrzam connect
# → opens browser login
# → token saved to ~/.agrzam/credentials

# Link this project — once per codebase
agrzam link
# → shows list of your platform projects
# → you select one
# → asks what port your server runs on
# → saves to agrzam.config.json
# → watching starts automatically
Enter fullscreen mode Exit fullscreen mode

After agrzam link the package watches your OpenAPI JSON on every server start. No extra command. It just works.

When you've tested your endpoints locally and you're ready for teammates to see them:

agrzam push
# → shows what will change
# + POST /api/orders   (new)
# ~ GET  /api/users/:id (changed)
# → you confirm → team sees it
Enter fullscreen mode Exit fullscreen mode

Local-first — your team sees nothing until you decide

This is the design decision I'm most interested in getting feedback on.

Local endpoints stay local until you run agrzam push.

You test privately while you're building. You fix issues before anyone else sees the endpoint. When you're confident — you push. The team sees verified, working endpoints. Not half-finished work in progress.

It mirrors how Git works mentally:

git commit   →   agrzam watches locally
git push     →   agrzam push
Enter fullscreen mode Exit fullscreen mode

Developers already understand this model. Zero learning curve.

Three ways to test inside Agrzam

Quick — one click. GET endpoints run immediately. Auth injected. Done.

Manual — full control. Paste your token, edit the payload, send the request. Exactly like Postman but inside a workspace your whole team shares.

Vibe Test — this is the interesting one. You provide your auth token once. The AI reads your OpenAPI schema, generates a valid payload, sends the request, and tells you what passed and why. You touch nothing. Like vibe coding but for API testing.

Works with every framework

If your framework generates an OpenAPI URL — Agrzam works with it.

Framework Default OpenAPI URL
FastAPI /openapi.json
Django REST Framework /api/schema/
NestJS /api-json
Express + swagger-jsdoc /api-docs.json
Laravel + L5-Swagger /api/documentation.json
Rails + rswag /api-docs/v1/swagger.yaml
Spring Boot /v3/api-docs
Go + swaggo /swagger/doc.json

agrzam link detects the OpenAPI URL automatically from the port you provide.

Web + Desktop

The platform works in the browser. But for local development you want a desktop app — no browser tabs, no CORS issues, works offline. So we're also building an Electron desktop app that wraps the same Next.js UI.

apps/web/       → Next.js workspace (browser)
apps/desktop/   → Electron wrapper (native desktop)
Enter fullscreen mode Exit fullscreen mode

One codebase. Two surfaces.

The monorepo structure

Built with Turborepo and pnpm workspaces. Every package is independently contributable.

agrzam/
├── apps/
│   ├── web/               → Next.js workspace UI
│   ├── desktop/           → Electron desktop app
│   ├── api/               → NestJS REST API
│   └── gateway/           → WebSocket realtime server
│
└── packages/
    ├── apiwatch/          → CLI tool (@agrzam/apiwatch)
    ├── openapi-parser/    → Reads OpenAPI schemas
    ├── schema-diff/       → Detects endpoint changes
    ├── payload-generator/ → Builds test payloads
    ├── test-runner/       → Executes requests
    ├── websocket/         → Shared WS logic
    └── shared-types/      → TypeScript types
Enter fullscreen mode Exit fullscreen mode

Why open source

Bruno proved developers want open source API tooling. It has 30k+ GitHub stars. But Bruno is still manual — you maintain collections yourself. There's no real-time sync, no team workspace, no OpenAPI-native model.

Agrzam fills the gap between "fully manual" and "fully cloud-locked." Open source and self-hostable, with a cloud-hosted version planned later.

Contributor benefits

Nothing is promised today — but the principle is clear:

If Agrzam makes money, the people who built it should benefit from it.

Once the MVP is validated and the project reaches sustainable usage, monetization decisions (cloud plans, revenue sharing, compensation) will be discussed openly with active contributors before anything is implemented.

Where we are now

Early architecture phase. The monorepo is structured. The packages are scoped. The README is written. Now we need people to actually build it.

4 good first issues are open right now:

  1. agrzam connect — one-time machine auth CLI command
  2. agrzam link — link codebase to platform project
  3. OpenAPI schema parser — normalize OpenAPI 3.x into endpoint list
  4. Endpoint card component — Next.js App Router, Tailwind, shadcn/ui

Each issue is self-contained. No need to understand the whole codebase to contribute to one package.

Stack: TypeScript, Node.js, NestJS, Next.js, PostgreSQL, Redis, Turborepo, Electron

Honest questions for this community

  1. Is the local-first model (test privately, push when ready) useful — or just extra friction?
  2. Would the OpenAPI-native approach work for your backend setup?
  3. What would actually make you switch from Postman or Bruno?

GitHub: github.com/MrAboubakr/agrzam

If any of the open issues match your skills — comment on the issue to claim it. If you just want to follow along — star the repo and watch GitHub Discussions where all architecture decisions happen publicly.

Built in public. All feedback welcome.

Top comments (0)