DEV Community

Cover image for Why I built RedfireForge: one workbench for six API protocols
RedfireForge
RedfireForge

Posted on

Why I built RedfireForge: one workbench for six API protocols

I was tired of keeping four tools open to test one service.

HTTP in a REST client. GraphQL in another tab. A gRPC call in the
terminal. A WebSocket in wscat. Kafka somewhere else. Load testing
in a fifth window. None of them shared variables or a single report.

RedfireForge is my attempt to put that in one workbench.

What it is

An open-source visual API testing and load-testing app for HTTP,
GraphQL, gRPC, WebSocket, SSE, and Kafka
. Same engine in the
desktop app (Tauri + React), the browser, and the CLI.

You can:

  • Send ad-hoc requests (Postman-style client + OpenAPI catalog)
  • Chain calls in a workflow designer (variables, conditions, fork/join)
  • Run load tests with assertions
  • Stand up a local mock server
  • Run the same tests in CI: npm install -g redfireforge-cli

There is an optional Learning Hub desktop build with guided
lessons. The hosted site is the browser app, not that lesson player.



Why open source

I need this on my machine, against local ports and private networks.
A hosted-only tool cannot do that. AGPL v3 keeps the code open.

Cloud-hosted load testing is on a waitlist — it is not required to
use the app today.

What I would like feedback on

  1. Which protocols you actually need in one UI
  2. Whether the workflow designer is understandable
  3. What is missing for CI

Links

Top comments (0)