DEV Community: Mesut Yakut

Tigrister CLI

Mesut Yakut — Tue, 31 Mar 2026 12:57:22 +0000

Introducing tgrs - A Modern HTTP Client CLI with Built-in API Testing

If you work with APIs, you probably use curl, wget and etc. every day. It gets the job done, but when you need assertions, timing breakdowns, flow testing, or load testing - you reach for separate tools.

tgrs combines all of these into a single CLI tool. One binary, zero dependencies, native HTTP/3 support.

Tigrister CLI - tgrs v1.0.0 is available

curl-Compatible, But More Powerful

If you know curl, you already know tgrs. The familiar flags work the same way:

tgrs GET https://api.example.com/users -H "Accept: application/json"
tgrs POST https://api.example.com/users -H "Content-Type: application/json" -d '{"name": "John"}'
tgrs GET https://api.example.com/admin -u admin:secret
tgrs GET https://example.com -L -k

-H, -d, -u, -L, -k, -o - they all work as expected. No new syntax to learn.

But tgrs adds capabilities that curl doesn't have.

Request Tracing

Every API call goes through multiple phases: DNS lookup, TCP handshake, TLS negotiation, server processing, content download. When something is slow, you need to know which phase is the bottleneck.

Use -t (or --trace) to see a visual waterfall breakdown:

tgrs GET https://api.example.com/users -t

Every phase is measured with microsecond precision. DNS taking too long? TLS handshake slow? Server response time high? You'll see it instantly.

This is not just a total response time. It's a full breakdown of where every millisecond goes.

Built-in Assertions

Testing APIs usually means writing scripts, setting up test frameworks, or using GUI tools. With tgrs, you validate responses directly from the command line:

tgrs GET https://api.example.com/users \
  -a "status eq 200, $.data.id exists, body contains users, header content-type contains json, response_time lt 500"

Five assertion targets: status codes, JSON paths, body content, headers, and response times. Short operators like eq, lt, gt, contains keep commands concise.

The key detail: tgrs exits with code 1 when assertions fail. This makes it a drop-in tool for CI/CD pipelines. No test framework needed.

# GitHub Actions
- name: API Health Check
  run: |
    curl -sSL https://cli.tigrister.com | sh
    tgrs GET https://api.example.com -a "status eq 200, response_time lt 2000"

Flow Runner - Chaining API Requests

Real-world API testing is rarely a single request. You need to authenticate, create resources, verify them, update them, check side effects. tgrs has a built-in flow runner for exactly this.

Define your flows in .flow.json files (created with Tigrister Pro or written manually), then run them:

tgrs run order-flows -f place-order

Run all flows in a directory at once:

tgrs run order-flows

The live terminal dashboard shows every step's status, response time, HTTP method, URL, and assertion results. All four flows ran with 100% success rate, 16 out of 16 steps passed.

Iterations and Anomaly Detection

Run the same flow multiple times to detect performance regressions:

tgrs run order-flows -f bulk-create-orders -i 4

Or run iterations in parallel with -p:

tgrs run order-flows -f bulk-create-orders -p 4

Each iteration appears as a separate line on the response time chart. The anomaly detection engine automatically flags unstable response times - like "Create Shipment Label: Iteration 1: 423ms - 73% above average" or "Response times are unstable (CV: 45%)".

You don't need to eyeball charts. tgrs tells you what's wrong.

Load Testing

When you need to push your API to its limits, tgrs supports four test types:

load - Gradual ramp up, sustained load, gradual ramp down
stress - Aggressive increase to find breaking points
spike - Sudden spike to high load
soak - Long duration with low, steady load

tgrs run api-specs -s user-api -t stress

The real-time dashboard shows response time charts, throughput (req/s), error rates, active virtual users, and a step breakdown with P50/P90/P95/P99 percentiles. The error analysis section pinpoints exactly which steps are failing and why.

25+ Random Data Generators

Generate dynamic test data on the fly in any request, flow step, or load test:

tgrs POST https://api.example.com/users \
  '{"email": "{{random.email}}", "id": "{{random.uuid}}", "name": "{{random.name}}"}'

Available generators: uuid, email, name, firstName, lastName, phone, number, string, boolean, date, datetime, ip, ipv6, url, city, country, slug, hex, alphanumeric, custom (regex patterns), and more.

HTTP/3 Native

tgrs has first-class HTTP/3 (QUIC) support. Force a specific protocol or let tgrs negotiate automatically:

tgrs GET https://api.example.com --http3
tgrs GET https://api.example.com --http2
tgrs GET https://api.example.com --http1.1

Connection pooling handles HTTP/1.1 keep-alive, HTTP/2 multiplexing, and QUIC connections transparently.

Install in Seconds

Pick your preferred method:

curl -sSL https://cli.tigrister.com | sh
wget -qO- https://cli.tigrister.com | sh
npm install -g @tigrister/tgrs
brew install tigrister/tap/tgrs

Available on macOS and Linux. Windows support is coming soon.

tgrs also auto-updates in the background - when a new version is available, it downloads and replaces itself automatically.

What's Next

tgrs v1.0.0 is the foundation. We're working on Windows support, more export formats, and deeper CI/CD integrations.

Try it out, break things, and let us know what you think.

Tigrister: Api Client
Documentation: https://tigrister.com/cli
npm: https://www.npmjs.com/package/@tigrister/tgrs

What are Webhooks and How to Test Them

Mesut Yakut — Fri, 23 Jan 2026 15:47:24 +0000

You're building an e-commerce app. A customer completes a payment, and you need to update their order status, send a confirmation email, and notify the warehouse. How does your payment provider tell your app that the payment succeeded?

This is exactly where webhooks come in.

What is a Webhook?

A webhook is an automated HTTP request that one system sends to another when a specific event occurs. Think of it as a "reverse API" - instead of your app asking "Did anything happen?", the other system proactively tells you "Hey, something just happened!"

Traditional API polling works like this:

Your App: "Any new payments?" → Payment API: "No"
Your App: "Any new payments?" → Payment API: "No"
Your App: "Any new payments?" → Payment API: "Yes! Here's the data"

Webhooks flip this around:

Payment API: "A payment just completed!" → Your App: "Got it, thanks!"

This is more efficient, real-time, and reduces unnecessary API calls.

Real-World Webhook Examples

Webhooks are everywhere in modern software:

Stripe/PayPal sends a webhook when a payment succeeds or fails
GitHub notifies your CI/CD pipeline when code is pushed
Slack triggers workflows when messages are posted
Shopify alerts your inventory system when an order is placed
Twilio informs your app when an SMS is delivered

Every major platform uses webhooks to enable real-time integrations.

The Webhook Testing Challenge

Here's the problem: webhooks are notoriously difficult to test during development.

Challenge 1: You don't control when they fire

When testing a Stripe integration, you can't just "trigger" a real payment webhook whenever you want. You'd need to make actual payments, wait for processing, and hope the webhook arrives.

Challenge 2: Your local server isn't accessible

Webhooks need a public URL to send requests to. Your localhost:3000 isn't reachable from Stripe's servers. Developers often resort to tunneling tools, which add complexity.

Challenge 3: Inconsistent payloads

Real webhook payloads can vary. A payment webhook might include different fields depending on the payment method, currency, or account settings. Testing all variations is tedious.

Challenge 4: Timing and sequence issues

What happens if a webhook arrives before your database transaction commits? Or if webhooks arrive out of order? These race conditions are hard to reproduce with real services.

Challenge 5: Error handling is blind

When your webhook handler fails in production, you often don't know why. The external service just sees a 500 error. Debugging requires extensive logging and often can't be reproduced locally.

How Mock Servers Solve Webhook Testing

A mock server lets you simulate webhook behavior without depending on external services. Instead of waiting for Stripe to send a webhook, you configure your mock server to send it exactly when and how you need.

This approach gives you:

Full control over when webhooks fire
Predictable payloads that match your test scenarios
Local development without public URLs or tunnels
Edge case testing for timeouts, failures, and retries
Reproducible tests that run the same way every time

Webhooks in Mocklantis

Mocklantis provides a complete webhook simulation system. Here's how it works:

Creating a Webhook

In Mocklantis, webhooks are standalone entities that you configure once and bind to multiple endpoints. When any bound endpoint is called, the webhook fires automatically.

You configure:

Target URL: Where to send the webhook (your app's webhook handler)
HTTP Method: Usually POST, but supports all methods
Headers: Custom headers like Content-Type or authentication
Body: The payload to send, with dynamic template support

Template Variables

The real power comes from template variables. Your webhook payload can include data from the original request:

{ "event": "payment.completed", "orderId": "{{request.body.orderId}}", "amount": {{request.body.amount}}, "customerId": "{{request.body.customerId}}", "processedAt": "{{request.timestamp}}", "transactionId": "{{random.uuid}}" }

When a request hits your mock endpoint, Mocklantis extracts values from the request and injects them into the webhook payload. This creates realistic, dynamic webhooks that mirror real-world behavior.

Available template variables include:

{{request.path.id}} - URL path parameters
{{request.query.page}} - Query string parameters
{{request.body.field}} - JSON body fields (supports nested paths)
{{request.header.X-Custom}} - Request headers
{{request.timestamp}} - ISO timestamp
{{random.uuid}} - Generate unique IDs

Webhook Flow

Here's the sequence when a request arrives:

Client sends request to mock endpoint
Mocklantis returns the mock response immediately
Webhook fires asynchronously (doesn't block the response)
Your webhook handler receives the notification

This "fire-and-forget" approach mirrors how real webhook systems work. The webhook execution never affects your endpoint's response time or success.

Advanced Configuration

For realistic testing, Mocklantis supports:

Delay: Add latency before the webhook fires. Real payment processors don't send webhooks instantly - there's usually a 1-5 second delay. Simulate this to test your app's behavior during that window.

Retry Logic: Configure automatic retries if your handler returns an error. Set retry count (up to 10) and delay between attempts. Test how your app handles webhook redelivery.

Authentication: Support for Basic Auth, Bearer tokens, and API keys. Test that your webhook handler properly validates incoming requests.

Timeout Control: Set how long to wait for your handler's response. Test timeout scenarios without waiting forever.

Binding Webhooks to Endpoints

A single webhook can be bound to multiple endpoints. For example, an "Order Notification" webhook might fire when:

POST /api/orders (new order created)
PUT /api/orders/:id/status (status change)
DELETE /api/orders/:id (order cancellation)

This models real-world scenarios where the same external system needs to know about multiple types of events.

Practical Testing Scenarios

Testing Payment Flows

Create a mock POST /api/checkout endpoint that returns a success response, bound to a webhook that hits your POST /webhooks/payment handler. Now you can test your entire payment flow locally, including the webhook processing.

Testing Failure Handling

Configure a webhook with a short timeout and point it at a slow endpoint. Verify your app handles webhook timeouts gracefully. Then test retry behavior by returning 500 errors and checking that retries occur.

Testing Race Conditions

Add a 2-second delay to your webhook. Make a request and immediately query your database. Is the order in a "pending" state? Does your UI handle this correctly? These timing issues are nearly impossible to test with real services.

Testing Idempotency

Webhooks can be delivered multiple times. Configure retries and verify your handler doesn't create duplicate records or send duplicate emails when the same webhook arrives twice.

Best Practices

Always verify webhook signatures in production. While testing, you can skip this, but your production handler should validate that webhooks come from the expected source.

Make handlers idempotent. Use unique identifiers to detect and ignore duplicate deliveries.

Respond quickly. Return a 200 response immediately and process asynchronously. Webhook senders often have short timeouts.

Log everything. Webhook debugging is hard without detailed logs of what was received and how it was processed.

Test error scenarios. Don't just test the happy path. Simulate network failures, invalid payloads, and authentication errors.

Conclusion

Webhooks are fundamental to modern application architecture, enabling real-time communication between services. But their asynchronous, external nature makes them challenging to test during development.

By using a mock server with webhook support, you gain full control over the testing process. You can simulate any webhook scenario, test edge cases, and build confidence in your webhook handlers before deploying to production.

The next time you're integrating with a webhook-based service, consider setting up mock webhooks first. Your future self will thank you when debugging that mysterious production issue.

For this and more features: mocklantis.com
Download mocklantis: mock server

Mocklantis: Modern API Mocking Made Simple

Mesut Yakut — Fri, 12 Dec 2025 14:48:31 +0000

The Hidden Cost of Dependencies: Why Mocking Matters

Working with microservices architecture means living with dependencies. Your service talks to another service, that service talks to three more, and somewhere in this chain, there's a payment gateway, a notification service, and probably a third-party API with aggressive rate limits.

When everything is up and running, life is good. But here's the question nobody likes to ask: what happens when they're not?

How do you test a timeout scenario? How do you simulate a 503 from the payment service? How do you know your retry logic actually works before it matters?

These questions are uncomfortable because the honest answer is often "we don't" or "we hope for the best."

The Problems We Don't Talk About Enough

In microservices development, there are friction points that slow everyone down but rarely get addressed properly.

Dependencies block progress. Your service is ready, but the one you depend on isn't. Maybe another team is still building it. Maybe it's a third-party API with sandbox limitations. Maybe it's a payment gateway that only behaves correctly in production. Whatever the reason, you're waiting for something outside your control.

Unit tests create false confidence. Tests pass. Green checkmarks everywhere. But passing unit tests means your code works in isolation—with mocked interfaces that behave exactly as you programmed them. Real services don't behave that way. They timeout. They return unexpected responses. They fail at 3 AM on a Sunday.

Simulating failure is harder than building features. You need to verify what happens when a downstream service returns a 503. You need to test your circuit breaker. You need to confirm your fallback logic works. But actually creating these conditions? That's where teams give up and hope monitoring will catch problems in production.

Everyone mocks differently. One developer hardcodes JSON responses. Another writes a small Express server. Someone else uses a CLI tool with YAML configs. The staging environment is shared by four teams and constantly broken. "Works on my machine" becomes the team motto.

These aren't rare situations. This is Tuesday for most backend teams.

It's Not Just Microservices

Dependency problems aren't exclusive to microservices architecture. They exist wherever two systems need to talk to each other.

Frontend teams waiting for backend APIs to be ready. Mobile apps blocked because the server endpoint isn't deployed yet. Integration projects stalled because the third-party system has rate limits or sandbox restrictions.

The pattern is the same: your work is done, but you can't verify it because something else isn't available. You're blocked not by your own code, but by external factors.

This is where mocking becomes essential. Not as a nice-to-have, but as a fundamental part of how software gets built and tested.

Why Mocking Has a Bad Reputation

The concept of mocking is simple: create fake services that return predictable responses. Test your code against them. Simulate any scenario you need.

On paper, it's the perfect solution. In practice, most teams avoid it.

Traditional mocking means configuration files. YAML or JSON schemas. CLI commands. Learning another tool's syntax. Restarting servers every time you change a response.

You've already written the feature. You've already written unit tests. Now you need more setup just to simulate a service that someone else should have finished?

The friction isn't worth it. So teams test against unstable staging environments or skip integration testing entirely. Neither is good, but both feel more practical than fighting mock server configuration.

This is the real problem: mocking works, but the experience around it doesn't.

Mocklantis changes this.

Mocklantis is a free desktop application for creating mock servers. It runs locally on macOS, Windows, and Linux. It supports HTTP/REST endpoints, WebSocket connections, Server-Sent Events, and webhooks—all in one application.

But what makes it different is the experience. No configuration files. No CLI commands. No YAML schemas to learn. You open the app, create a server, add endpoints, and start testing. Changes apply instantly—no restarts, no rebuilds. Everything visual, everything immediate.

The distance between "I want to test this scenario" and "I'm testing this scenario" becomes seconds instead of hours.

Mocklantis in Action

The workflow is straightforward. You open the application, create a server on port 8080, add an endpoint—POST /payments/process, type a JSON response, set the status code. Done. The endpoint is live. Your service can call it immediately.

Need to test timeout handling? Add a delay. The change applies instantly—no restart, no config file, no terminal command. Need to test error scenarios? Change the status code to 503. Watch how your service responds.

Need dynamic data? Mocklantis supports template variables—UUIDs that regenerate per request, timestamps, emails, names, values that follow custom patterns. Fourteen different random variable types built in.

But HTTP/REST is just the beginning. Modern systems aren't just REST anymore.

WebSockets are everywhere—real-time dashboards, notifications, chat systems, live feeds. Mocklantis supports WebSocket mocking with three modes: conversational for request-response patterns, streaming for continuous data flow, and triggered streaming where a client message triggers a sequence of responses—perfect for AI-style interactions.

Server-Sent Events power streaming interfaces, especially in AI applications where responses arrive token by token. With Mocklantis, you configure events, set intervals, and define on-connect messages. Exactly what you need for testing streaming consumers.

Need to trigger external callbacks? Webhooks are built in. When an endpoint is called, Mocklantis can fire HTTP requests to other URLs with configurable auth, retry logic, and delays.

Everything visual. Everything immediate. No custom server code. No documentation required to get started.

Small Features, Big Impact

Some capabilities sound minor until you actually need them. Mocklantis gets these details right.

Live updates without restart. Change any endpoint while your service is running. Modify responses, add delays, switch status codes—all without restarting anything. Stay in flow. Experiment freely.

Automatic persistence. Every change saves immediately—500ms debounce, no save buttons. Close Mocklantis, come back tomorrow, everything is exactly as you left it.

Real-time request logs. See every request hitting your mock server as it happens. Headers, bodies, timing. Debug integration issues in seconds instead of adding logging statements everywhere.

Proxy mode. Mock some endpoints, forward others to real services. Isolate specific dependencies while keeping the rest of your stack intact.

Import from anywhere. Paste a cURL command, import an OpenAPI spec, or load a .mock file. Don't start from scratch when you don't have to.

Local-only operation. Everything runs on localhost. No cloud accounts. No data leaving your machine. No concerns about sensitive test data being logged somewhere.

None of these are revolutionary on their own. Together, they remove the friction that stops teams from testing properly.

The Friction Problem

Developer tools follow a pattern: more power means more complexity. Steeper learning curves. Thicker documentation. More Stack Overflow questions about basic setup.

But complexity isn't a requirement for capability. Usually it means nobody prioritized the user experience.

The best tools disappear into your workflow. You don't think about them. You don't fight them. They just work.

Mocklantis is built on this principle. Creating an endpoint shouldn't require reading documentation. Simulating a scenario shouldn't mean editing config files. Testing edge cases shouldn't feel like a separate project.

When mocking is easy, teams mock more. They test more scenarios. They catch more bugs before production. The tool's simplicity directly impacts code quality.

Confidence Compounds

Testing isn't about any single test. It's about the confidence that builds over time.

When simulating scenarios is easy, you simulate more of them. You verify error handling works. You confirm retry logic behaves correctly. You ship knowing your code handles edge cases—not hoping it does.

Reliable software comes from teams that can test thoroughly without fighting their tools. When the tooling gets out of the way, testing becomes a habit instead of a chore.

Wrapping Up

Dependency mocking is the most effective way to test services in isolation. It's how you verify that code handles real-world scenarios—not just happy paths, but failures, timeouts, and edge cases.

Most teams don't mock enough because the friction is too high. Configuration files, CLI commands, server restarts, learning curves. Rational trade-offs lead to less testing and more production surprises.

Mocklantis removes that friction. Visual interface. Instant updates. No configuration files. HTTP, WebSocket, and SSE support. Runs locally on macOS, Windows, and Linux.

It's free. You can start using it in seconds.

mocklantis.com

Get Started

Have fun.