Ruse @ruse_dev

v0.3.0 is intentionally not an accounts release. Not billing. Not teams. Not cloud sync. Not a giant platform jump. The priority is making the core HTTP loop feel right: - captured request selection - request-aware matching - response body/status/type/delay editing - cleaner header handling - clearer mocked logs I would rather make one local developer workflow trustworthy before adding a bigger product surface area around it. #DevTools

The HTTP workflow Ruse is moving toward: 1. Capture the real browser request. 2. Click the row in logs. 3. Inspect request params/body and response. 4. Edit the response body, status, type, or delay. 5. Save an enabled local mock. 6. Reload the UI. That is the loop. Not a full backend platform. Not a mock-server replacement for every team workflow. Just a faster browser-level path for the UI state in front of you. Ruse v0.2.0 is live; v0.3.0 is the next quality pass. #APIMocking #Frontend

Modal-first flows can make a small task feel bigger than it is. When you are testing one frontend state, you usually do not want ceremony. You want to select the request that happened, inspect it, change the response, save, and reload. That is why the v0.3.0 direction is Builder-first: clicking a captured request should update the main workspace, not pull you into a separate draft step. Ruse should feel like working inside the request, not filling out a mock form from scratch. #DevTools

New DEV.to article planned for today: why URL-only API mocks break down in real frontend work. The thesis: many frontend states are not identified by URL alone. Real apps often reuse one endpoint across filters, accounts, permissions, body variants, and product states. That is exactly the kind of workflow Ruse is moving toward with v0.3.0: start from captured browser traffic, understand the request, and create a local mock for the actual UI state. Ruse v0.2.0 is live now: ruse.dev #Frontend

The v0.3.0 direction is simple: match the state, not only the path. If a captured request body contains 20 fields, maybe only 2 of them matter for the UI state you want to reproduce. The product direction is to let you inspect the captured request, keep the important fields, edit the response, and save a local mock that matches the state you care about. No advanced rule engine theater. Just a practical subset model for real frontend work. Ruse v0.2.0 is live now; v0.3.0 is in progress. #APIMocking

In real apps, the same endpoint can mean totally different UI states depending on query params, user id, account, document type, filters, feature flags, or request body. URL-only mocks are a decent start, but they can break down when the frontend state lives inside the request details. That is one of the reasons v0.3.0 is focused on request-aware HTTP rule creation. Your endpoint is not always your state. #Frontend #APIs

Ruse v0.3.0 is focused on one core idea: The request log should become the place where a useful mock starts. Instead of opening a separate draft modal and mentally jumping between screens, the direction is: click a captured request -> inspect what was sent and returned -> edit the response -> save a local mock. Ruse v0.2.0 is live now. v0.3.0 is the next quality pass around the HTTP workflow. If you use browser request logs while debugging frontend, does this direction feel natural?

The hard part is often not mocking an endpoint. The hard part is reproducing the exact frontend state behind the request. One endpoint can represent an empty list, a filtered list, a permission-limited list, a malformed payload, a slow response, or a 500. That is why Ruse is moving deeper into request-aware HTTP mocking. The goal is not just to override a URL. The goal is to control the state your UI needs to survive. Which API state is hardest for you to reproduce on demand?

Ruse v0.2.0 is live in the Chrome Web Store. The current workflow is intentionally small: 1. Open the app you are testing. 2. Open Ruse on the working tab. 3. Capture a real browser request. 4. Create a local mock rule. 5. Organize rules into local collections. 6. Reload the UI and inspect the state. No account. No proxy setup. No mock server ceremony for one local frontend state. Install or update Ruse and try it on one real API state today: ruse.dev

Ruse weekly recap: - v0.2.0 is live in the Chrome Web Store - working-tab flow replaced the old tab selector - local collections now help organize mock rules - the v0.2.0 DEV.to article is out - next focus is the v0.3.0 HTTP rule quality pass The most useful thing now is feedback from real frontend workflows. Install Ruse, test one API state, and tell me where the flow still feels slow or confusing: ruse.dev

One request can represent many UI states. The same endpoint can drive: - normal data - empty data - loading state - 500 error - malformed response - permission denied Frontend work often means checking all of those states, but most tools make the edge cases slower than the happy path. That is the small workflow Ruse is exploring: make one real browser request easy to bend locally, then reload and inspect the UI.

Ruse is not trying to replace mock servers. I would still use MSW, Mockoon, Requestly, contract tests, and shared mock environments when the team or test suite needs them. Ruse is for a smaller moment: I am in Chrome. The app is making a real request. I need this one request to return a different local response for a few minutes. That smaller loop is worth making better.

Product question I keep coming back to: Should Ruse stay narrow and local-first longer before adding cloud/team features? Cloud sync, shared collections, auth, teams, billing, version history — all of that is tempting. But the core loop still has to earn trust first: Capture a real request. Create a local mock. Reload the UI. Understand the state. My instinct: small tool first, platform later. Curious if other devtool builders think the same.

Build-in-public note for Ruse: v0.2.0 is live, and v0.3.0 is shaping up as an HTTP rule quality pass. Current focus: - safer create-from-log drafts - better response body editing - JSON validation and formatting - response header editing - noisy header cleanup - permission reduction where it is safe Not shipped yet. Still being shaped. The goal is simple: make the first useful browser mock faster and harder to mess up.

Weekend frontend challenge: Pick one screen you care about and test one painful API state. Not a full test plan. Not a huge mock setup. Just one useful state: - empty list - server error - slow response - malformed response - permission denied Then ask: did the UI actually behave the way you expected? If setting up that one state feels annoying, that is exactly the problem Ruse is trying to make smaller.

I wrote a practical DEV.to article about testing frontend error states without breaking backend or staging. It covers the states that are easy to forget but painful when users hit them: - empty lists - 500s - slow responses - malformed data - permission errors The core idea: sometimes you do not need a full mock environment. Sometimes you need one real browser request to return one controlled local response. Read it here: [dev.to/rusedev/how-to…]

Staging is useful, but it rarely has the exact edge case you need. - Maybe you need an empty list, but staging has data. - Maybe you need a 500, but the backend is healthy. - Maybe you need a slow API, but everything is fast locally. - Maybe you need a permission error, but nobody wants to mutate test accounts. That is where local browser-level overrides feel useful. Not as a replacement for tests or mock servers. Just as a faster loop for the UI state in front of you.

Small frontend checklist for today: Before you call a screen done, check at least a few non-happy states: - empty data - 500 error - slow response - malformed response shape - permission denied These are product states, not just technical states. Users see them. QA has to verify them. Designers care about them. Ruse is my attempt to make this kind of browser-level API state testing faster and less annoying.

Local mock rules become much more useful when they have names you can remember. That is why Ruse v0.2.0 adds small local collections. Examples: - Checkout errors - Dashboard empty states - Slow API demos - Permission states - QA repro cases The limits are still intentionally small: up to 20 local rules and up to 3 local collections. The point is not to pretend Ruse is already a team platform. The point is to keep the local testing loop organized while the product stays focused.

The Ruse loop I care about right now is intentionally small: 1. Open the app you are already testing. 2. Open the Ruse side panel. 3. Capture the real browser request. 4. Create a local mock rule. 5. Group it if it belongs to a scenario. 6. Reload the UI. No fake backend setup. No staging mutation. No temporary throw in app code. Ruse v0.2.0 is live now with a cleaner working-tab flow and local collections. Try it on one real frontend screen: ruse.dev