DEV Community: Andrii Klymiuk

Corgi: The CLI That Tames Your Local Microservices Chaos

Andrii Klymiuk — Mon, 24 Mar 2025 12:07:21 +0000

Microservices architecture gives us flexibility and scale, but the local development experience? It's a nightmare of tangled dependencies, Docker scripts, and that recurring question: 'How do I seed this database again?'. After one too many onboarding sessions that took hours instead of minutes, I built Corgi, an open-source Go CLI that launches your entire stack with a single command. It's not Docker Compose with a pretty face—it's a fundamentally different approach that containerizes only what needs isolation (databases) while running your services natively for better performance and lower resource usage

In this post, I'll walk you through why I created Corgi, what makes it special, and how it can transform your team's development workflow—all from a simple YAML file.

The Problem: Microservices Development Was Too Chaotic

A while back, I was working on a project with multiple microservices, each with its own database requirements. We faced several challenges:

Onboarding new developers took hours of explanation and troubleshooting
Database seeding was inconsistent and required manual steps
Service dependencies had to be launched in a specific order
Environment variables were difficult to manage across services and filled manually

I tried existing solutions like Docker Compose and Kubernetes, but they either felt too heavy or didn't solve our specific problems:

Docker Compose is solid but lacks native DB seeding or service orchestration smarts. It also runs everything in containers, which consumes more resources than necessary for local development.
Custom Scripts are a maintenance nightmare and don't scale across teams
Cloud Tools want your data and your wallet, neither of which I'm keen to hand over

I wanted something that would make running our entire stack locally as simple as a single command, but with the efficiency of running services natively when appropriate. When I couldn't find it, I built Corgi.

What Makes Corgi Special?

Corgi is like a loyal companion that cuts through the chaos. Here's what sets it apart:

Define Once, Run Anywhere: Write a corgi-compose.yml file with your services and DBs. One command corgi run and everything launches. Share that file with your team, and they're up in minutes.
Database Superpowers: Seed Postgres, MongoDB, Redis (and 30+ others) from SQL dumps or remote DBs. No more manual imports or stale test data.
Parallel Power: Services start concurrently, not in some sluggish sequence. Your API and frontend are live at the same time, every time.
Auto Git Clone: Repositories specified with cloneFrom are automatically cloned during initialization, ensuring everyone on your team has the exact same code structure. If they were cloned already, they are not cloned again.
Smart Environment Management: Automatically connect services with the right environment variables. When you specify dependencies using depends_on_services and depends_on_db, Corgi populates each service's .env file with the correct connection information. For database dependencies, it adds credentials (DB_HOST, DB_USER, etc.), and for service dependencies, it adds URLs like SERVICE_NAME=http://localhost:3000. No more manual environment configuration or copying connection strings.
Resource Efficiency: Only containerizes databases while running your services natively, saving significant CPU and memory compared to full containerization
Simple YAML Configuration: Describe your entire project in one readable file and check its syntax with dedicated vscode corgi extension

It's not flashy—it's functional.

Getting Started

Ready to give Corgi a spin? Here's how to get started:

Install Corgi with Homebrew:

   brew install andriiklymiuk/homebrew-tools/corgi

   # Check if it works
   corgi -h

Create a simple corgi-compose.yml file in your project with db or services part
Run corgi init followed by corgi run

Want to try an example project? Run:

corgi run -t https://github.com/Andriiklymiuk/corgi_examples/blob/main/honoExpoTodo/hono-bun-expo.corgi-compose.yml

This will download and run a sample Todo app with a Hono backend and an Expo frontend.

Under the Hood: How Corgi Works

Unlike Docker Compose, which containerizes everything, Corgi takes a hybrid approach:

Databases run in Docker: Corgi creates Docker container templates for your databases, making them easy to start, stop, and clean up.
Services run natively: Your actual applications (Node.js servers, Go APIs, React frontends, etc.) run directly on your machine, saving CPU and memory.
Environment auto-wiring: Corgi automatically connects everything by generating the right environment variables and .env files.
Parallel execution: Service commands run concurrently, making startup much faster.

This hybrid approach gives you the best of both worlds: the isolation of Docker for databases with the performance of native execution for your applications.

How I Use It (and Why You'll Love It)

Here's a glimpse of how Corgi fits into my workflow:

Team Onboarding: New teammate? Send them the corgi-compose.yml. They run corgi run, and they're coding, not debugging setup.
Prototyping: Testing a new service? Clone it, tweak the YAML, and run it alongside the rest. Ports and dependencies sort themselves out.
Prod Parity: Seed your local DB from a prod dump. Catch issues before they hit staging.
Resource Management: Run a complex stack on a laptop without fans spinning up, since only the databases are containerized.
Cleanup: Ctrl+C kills everything cleanly, with optional afterStart commands to tidy up.

Let's look at a simple example:

# corgi-compose.yml
db_services:
  postgres_main:
    driver: postgres
    databaseName: app_db
    user: admin
    password: secret
    port: 5432
    seedFromFilePath: ./seed.sql

services:
  backend:
    cloneFrom: https://github.com/myorg/backend-api.git
    path: ./backend
    port: 8080
    depends_on_db:
      - name: postgres_main
    beforeStart:
      - go mod tidy
    start:
      - go run main.go

  frontend:
    cloneFrom: https://github.com/myorg/frontend-app.git
    path: ./frontend
    port: 3000
    depends_on_services:
      - name: backend
    start:
      - npm run dev

With this file, anyone on your team can run:

# First time setup
corgi init

# Run everything
corgi run

And Corgi will:

Clone both repositories (if they don't exist)
Create and start the Postgres database in Docker
Seed the database from your SQL file
Configure environment variables to connect everything
Start both services concurrently (directly on your machine, not in Docker)
Handle clean shutdown when you hit Ctrl+C

No more "it works on my machine" problems!

Real-World Examples

Example 1: Todo App with Bun and Expo

Here's a simple Todo application setup with React Native/Expo frontend and a Bun-powered backend:

services:
  dodoApp:
    cloneFrom: https://github.com/Andriiklymiuk/dodo.git
    path: ./dodo
    depends_on_services:
      - name: dodoServer
        envAlias: EXPO_PUBLIC_TODO_URL
        suffix: /
    environment:
      - EXPO_PUBLIC_TODO_WEBSOCKET_URL=ws://localhost:65533
    beforeStart:
      - yarn install
    start:
      # you can run yarn startAll to open web, android and ios all at once
      # - yarn startAll
      # or you can run yarn web, yarn ios, yarn android separately
      - yarn ios
    afterStart:
      # close ios emulator
      - killall Simulator 2>/dev/null || true
      # close android emulator
      - killall qemu-system-aarch64 2>/dev/null || true
  dodoServer:
    cloneFrom: https://github.com/Andriiklymiuk/dodoServer.git
    path: ./dodoServer
    port: 65533
    beforeStart:
      - bun install
    start:
      - bun dev

Notice how this configuration handles mobile development cleanly, automatically connecting the Expo app to its backend and even providing cleanup commands to close simulators when you're done.

Example 2: Go and Deno with AWS SQS

This example showcases a Go service that listens to SQS messages sent by a Deno service, with a Postgres database:

db_services:
  postgres-db-for-go-example:
    driver: postgres
    databaseName: best_name_for_database
    user: woof
    password: woof_database_password
    port: 5234
  aws-sqs-queue-for-go:
    driver: sqs
    databaseName: sqs_queue_name
    port: 4599

services:
  go_aws_sqs_listener:
    cloneFrom: https://github.com/Andriiklymiuk/go_aws_sqs_listener.git
    path: ./go_aws_sqs_listener
    depends_on_db:
      - name: postgres-db-for-go-example
        envAlias: none
      - name: aws-sqs-queue-for-go
        envAlias: none
    port: 7092
    start:
      - go run .
  deno_aws_sqs_emitter:
    cloneFrom: https://github.com/Andriiklymiuk/deno_aws_sqs_emitter.git
    path: ./deno_aws_sqs_emitter
    depends_on_db:
      - name: aws-sqs-queue-for-go
        envAlias: none
    port: 7098
    start:
      - deno run --allow-net --allow-read --allow-env server.ts

required:
  go:
    why:
      - To launch locally service manually
      - You need to install it yourself brew install go
    checkCmd: go version
  deno:
    why:
      - Needed to launch deno_aws_sqs_emitter
      - You need to install it yourself from https://deno.land/manual/getting_started/installation
    checkCmd: deno --version
  docker:
    why:
      - To launch databases
      - You need to install it yourself from https://docs.docker.com/desktop/install/mac-install/
    checkCmd: docker -v

This example shows how Corgi handles more complex infrastructure like message queues just as easily as databases, connecting the services together automatically.

Example 3: React Native App with Go Backend and Seeded Postgres

Here's an example that includes database seeding from a dump file:

db_services:
  postgres_with_data_for_go_reactnative:
    driver: postgres
    databaseName: bestDbName
    user: awesomeUser
    password: themostsecurepasswordyoucanimaging
    port: 5511
    seedFromFilePath: ./users_dump.sql

services:
  reactnative_app_get_user:
    cloneFrom: https://github.com/Andriiklymiuk/reactnative_app_get_user.git
    path: ./reactnative_app_get_user
    depends_on_services:
      - name: go_server_user_data
    beforeStart:
      - yarn install
      - npx pod-install
    start:
      - yarn start
      - yarn ios
    afterStart:
      - yarn ios:simulator:close
  go_server_user_data:
    cloneFrom: https://github.com/Andriiklymiuk/go_server_user_data.git
    path: ./go_server_user_data
    port: 7012
    depends_on_db:
      - name: postgres_with_data_for_go_reactnative
        envAlias: none
    start:
      - go run .

required:
  go:
    why:
      - To launch locally go service manually
      - You need to install it yourself brew install go
    checkCmd: go version
  yarn:
    why:
      - To build and launch some of the repos locally with yarn
    install:
      - brew install yarn
    checkCmd: yarn -v
  node:
    why:
      - To build and launch some of the repos locally with npm
    install:
      - brew install node
    checkCmd: node -v
  docker:
    why:
      - To launch databases
      - You need to install it yourself from https://docs.docker.com/desktop/install/mac-install/
    checkCmd: docker -v

For this example, the users_dump.sql file contains a schema and sample data:

SET statement_timeout = 0;
SET lock_timeout = 0;
SET idle_in_transaction_session_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;
SELECT pg_catalog.set_config('search_path', '', false);
SET check_function_bodies = false;
SET xmloption = content;
SET client_min_messages = warning;
SET row_security = off;

CREATE EXTENSION IF NOT EXISTS pgcrypto WITH SCHEMA public;

COMMENT ON EXTENSION pgcrypto IS 'cryptographic functions';
SET default_tablespace = '';
SET default_table_access_method = heap;

CREATE TABLE public.schema_migrations (
  version bigint NOT NULL,
  dirty boolean NOT NULL
);

CREATE TABLE public.users (
  id uuid DEFAULT gen_random_uuid() NOT NULL,
  name text NOT NULL
);

COPY public.schema_migrations (version, dirty) FROM stdin;
1 f
\.

COPY public.users (id, name) FROM stdin;
0961f8ea-7a94-4f2f-ba09-f41c802465b4 Some random user
0961f8ea-7a94-4f2f-ba09-f41c802465b5 Another random user
\.

ALTER TABLE ONLY public.schema_migrations
  ADD CONSTRAINT schema_migrations_pkey PRIMARY KEY (version);

ALTER TABLE ONLY public.users
  ADD CONSTRAINT users_pkey PRIMARY KEY (id);

To use this configuration:

Download the corgi-compose.yml file and the users_dump.sql file
Run corgi init to initialize repos
Run corgi run --seed to start everything with database seeding

This will start up the iOS app and Go server with a seeded Postgres database containing sample user data.

Example 4: RabbitMQ with NestJS and Go

This example showcases a message queue setup with NestJS sending messages to a Go service:

db_services:
  rabbitmq-for-go-nestjs:
    user: best_user
    password: most_secure_password
    driver: rabbitmq
    databaseName: rabbitmq-for-go-nestjs-db
    port: 4577

services:
  nestjs_rabbitmq_emitter:
    cloneFrom: https://github.com/Andriiklymiuk/nestjs_rabbitmq_emitter.git
    path: ./nestjs_rabbitmq_emitter
    port: 7856
    depends_on_db:
      - name: rabbitmq-for-go-nestjs
    beforeStart:
      - pnpm install
    start:
      - pnpm start:dev
  go_rabbitmq_listener:
    cloneFrom: https://github.com/Andriiklymiuk/go_rabbitmq_listener.git
    path: ./go_rabbitmq_listener
    port: 7854
    depends_on_db:
      - name: rabbitmq-for-go-nestjs
    beforeStart:
      - go run .

required:
  go:
    why:
      - To launch locally sync-go-trigger service manually
      - You need to install it yourself brew install go
    checkCmd: go version
  pnpm:
    why:
      - To launch products service locally
    install:
      - brew install pnpm
    checkCmd: pnpm -v
  docker:
    why:
      - To launch databases
      - You need to install it yourself from https://docs.docker.com/desktop/install/mac-install/
    checkCmd: docker -v

Example 5: Redis with Bun Server and Expo Client

This example shows a Redis-backed application with a Bun server and Expo client:

db_services:
  redis-for-bun:
    driver: redis
    host: localhost
    user: best_user_for_this_serivce
    password: most_secure_password_ever
    port: 2911

services:
  expo_redis_listener:
    cloneFrom: https://github.com/Andriiklymiuk/expo_redis_listener.git
    depends_on_services:
      - name: bun_redis_server
        envAlias: EXPO_PUBLIC_API_URL
    beforeStart:
      - yarn install
    start:
      - yarn ios
    afterStart:
      - yarn ios:simulator:close
  bun_redis_server:
    cloneFrom: https://github.com/Andriiklymiuk/bun_redis_server.git
    port: 1022
    depends_on_db:
      - name: redis-for-bun
    beforeStart:
      - bun install
    start:
      - bun start

required:
  yarn:
    why:
      - To build and launch some of the repos locally with yarn
    install:
      - brew install yarn
    checkCmd: yarn -v
  bun:
    why:
      - To launch products service locally
    install:
      - curl -fsSL https://bun.sh/install | bash
    checkCmd: bun -v
  docker:
    why:
      - To launch database services
      - You need to install it yourself from https://docs.docker.com/desktop/install/mac-install/
    checkCmd: docker -v
  jq:
    why:
      - To format server output in nice format
    install:
      - brew install jq
    checkCmd: jq --version

Database Support: Not Just Postgres

One of my favorite features is Corgi's extensive database support. While the examples above use several different databases, Corgi supports a huge range:

And over 20 more specialized databases like CockroachDB, SurrealDB, and Timescale. You can find the full list and examples in the Corgi documentation.

Each database type comes with sensible defaults, but you can configure them exactly as needed for your project.

Database Helpers: Seeding and Management

Working with databases locally is one of the biggest pain points in microservices development. Corgi makes this easy with built-in database helpers:

Automated Database Seeding

You can seed your databases in two ways:

Automatically (recommended)

# Run with the seed flag
corgi run --seed

This will automatically create dumps and seed your databases based on the configuration in your corgi-compose.yml file.

Manually

If you need more control:

Run corgi db
Choose your service
Select dump to create a dump
Select seed to populate the database

Database Commands

Corgi provides a simple CLI for database management:

# Start all databases
corgi db -u

# Stop all databases
corgi db -s

# Remove all databases
corgi db -r

# Combination: stop, remove, and start all databases
corgi db -rsu

Or work with individual databases using the interactive menu:

corgi db

This gives you an interactive menu to choose your service and the operation you want to perform:

Use the arrow keys to navigate: ↓ ↑ → ← 
? Select service: 
  ▸ 🛑  close program
    postgres_with_data_for_go_reactnative
    rabbitmq-for-go-nestjs
    redis-for-bun

After selecting a service, you'll see connection info and available commands:

Connection info to postgres_with_data_for_go_reactnative:

PORT 5511
USER awesomeUser
PASSWORD themostsecurepasswordyoucanimaging
DB bestDbName

postgres_with_data_for_go_reactnative is running 🟢
Use the arrow keys to navigate: ↓ ↑ → ← 
? Select command: 
  ▸ ⬅️  go back
    down
    help
    id
    listDocker
    seed
    up

Advanced Commands and Options

Corgi offers a range of commands to help manage your development environment:

Selective Running

Want to run just specific services or databases?

# Run only selected services
corgi run --services app,server

# Run only selected databases
corgi run --dbServices postgres,redis

# Skip certain parts of the process
corgi run --omit beforeStart,afterStart

Git Operations

Keep your repositories up to date:

# Pull updates for all service repositories
corgi pull

Service Management

Initialize and clean up as needed:

# Initialize everything from your corgi-compose.yml
corgi init

# Clean all services
corgi clean

Watch Mode

Corgi automatically watches for changes to your corgi-compose.yml file and reloads when changes are detected. If you want to disable this:

# Run without watching for config changes
corgi run --no-watch

Docker Compose vs. Corgi: Why Choose Corgi?

While Docker Compose is a fantastic tool, Corgi addresses several pain points for local development:

Resource Efficiency: Docker Compose runs everything in containers. Corgi only containerizes databases while running your services natively, saving significant CPU and memory.
Simpler Database Management: Corgi has built-in commands for database operations (seeding, dumping, etc.) that would require custom scripts in Docker Compose.
Environment Variable Wiring: Corgi automatically connects services with the right environment variables, handling the tedious .env file management for you.
Service Commands: Corgi can run pre-start, start, and post-start commands for each service, giving you full control over the lifecycle.
Native Performance: Services running directly on your machine often perform better than containerized ones, especially for development tasks like hot reloading.
Smaller Footprint: Corgi itself is a tiny Go binary (~5MB) compared to the Docker ecosystem.

Corgi isn't trying to replace Docker Compose for production deployments—it's focused on making local development smoother and more efficient.

VS Code Integration

If you're a VS Code user like me, you'll love the Corgi Checker extension. It provides:

Syntax highlighting for corgi-compose.yml files
Command palette integration for common Corgi commands
IntelliSense autocompletion for Corgi configuration options
Quick access to example templates

The extension makes working with Corgi even more seamless, especially when you're tweaking your configuration.

Why Go?

You might wonder why I built Corgi in Go rather than JavaScript or Python. There were several reasons:

Speed: Go is fast and creates small, efficient binaries
Cross-platform: Go makes it easy to build for multiple operating systems
Simplicity: Go's standard library covers most of what's needed
Concurrency: Go's goroutines make it easy to run services in parallel

The result is a lightweight CLI (around 5MB) that starts instantly and efficiently manages your services. The source code is fully open-sourced, so you can contribute or customize it to fit your specific needs.

In Conclusion

Corgi was born out of real developer frustration, and its focused approach to local microservices development has already saved countless hours for me and my fellow developers. By containerizing only what needs isolation while running services natively, it delivers the perfect balance of isolation and performance. As microservices continue to dominate architecture patterns, tools that simplify the local development experience become increasingly valuable. Looking ahead, I plan to extend Corgi with more useful stuff. The goal remains the same: make local development so seamless that you forget it's supposed to be hard.

Why "Corgi"?

I love them to be short)) Cli gets job done—like the dog that stares down chaos and wins. Corgis are loyal, hardworking, and surprisingly powerful for their size—just like this tool. They're also excellent herders, which fits perfectly with the tool's ability to corral multiple services and databases.

I've been using Corgi daily for more than a year, so that's battle tested and today I decided to share it with the world broadly. Whether you're a solo developer juggling multiple projects or part of a team managing a complex microservice architecture, I think you'll find it as helpful as I do.

And if you enjoyed this, you might also like my VS Code extension Golden Retriever for API testing within VS Code. There's even a sneak peek of Corgi at the end of my Golden Retriever demo.

So, what do you think? Grab Corgi from Homebrew, try it out, and let me know your thoughts in the comments. How's your dev setup looking these days?

Let's build smarter. 🚀

Photo by Jarrel Ng on Unsplash

Golden Retriever: Testing REST APIs in VS Code made easy

Andrii Klymiuk — Mon, 24 Mar 2025 08:39:43 +0000

As developers, we're always on the hunt for tools that streamline our workflows without forcing us out of our favorite environments. If you're like me—someone who lives in Visual Studio Code and dreads switching apps just to test an API—then I've got something exciting to share. Meet Golden Retriever, a VS Code extension I built to make API testing fast, collaborative, and, dare I say, fun. Think of it as Postman's loyal cousin who stays local, syncs with Git, and doesn't demand a cloud subscription.

In this post, I'll walk you through why I created Golden Retriever, what makes it stand out, and how it can level up your API testing game—all from the comfort of VS Code.

The Problem: API Testing Felt Clunky

A while back, I was working with my team on a project with a bunch of REST APIs. We needed a way to test them locally, share collections, and run Postman-style tests—all without jumping between tools. I'd tried the usual suspects: Postman, Thunder Client, Bruno, you name it. But each had its quirks:

Postman has a VS Code extension, but it doesn't provide a straightforward way to save collections directly in your own Git repo alongside your code. Plus, many features require a subscription.
Thunder Client stayed in VS Code, but it didn't support Postman's test format and had premium features locked behind a paywall.
Bruno was free and Git-friendly, but it lived outside VS Code and used its own collection format.

I wanted something that checked all my boxes: Git-syncable, Postman-compatible, local-first, and—most importantly—inside VS Code. When I couldn't find it, I decided to build it. Enter Golden Retriever.

What Makes Golden Retriever Special?

Golden Retriever is like a trusty dog that fetches exactly what you need. Here's what it brings to the table:

Git-Synced Collections: Store your API collections as JSON files in a /collections folder, version them with Git, and share them with your team. No cloud required.
Postman Compatibility: Import your Postman collections and run Newman-powered tests right in VS Code. If your team already uses Postman, this is a seamless transition.
Performance Testing: Repeat requests with customizable iterations to stress-test your APIs and catch performance hiccups.
Environment Variables: Manage variables via .env files (e.g., BASE_URL=http://localhost:3000) and use them with {{VARIABLE_NAME}} syntax. Toggle between local, staging, and production effortlessly.
Local & Secure: Everything stays on your machine. No data leaves unless you push it to Git. Even your request history clears when you close request tab or VS Code.
REST and GraphQL: Whether you're hitting REST endpoints or querying GraphQL, Golden Retriever has you covered with dedicated editors.

And the best part? It's free and lives right in your VS Code sidebar.

How I Use It (and Why You'll Love It)

Here's a glimpse of how Golden Retriever fits into my workflow:

Team Collaboration: I store collections in my repo, tweak them (e.g., adding a new POST /users request), and push them to Git. My team pulls the updates—no extra steps.
Performance Checks: I'll run a request 50 times to see if my API holds up under load. The stats panel shows me response times and failures instantly.
Pre-Deployment Testing: Before pushing to staging, I test endpoints locally with real data, using variables to swap environments.
Quick Experiments: For one-off tests, I use a .tmp folder (ignored by Git) to mess around without cluttering the shared collections.

Check out this simple example:

# .env
BASE_URL=http://localhost:3009/api
API_KEY=super-secret-key

In Golden Retriever, my request looks like:

Hit "Send," and I see the response right there—no context-switching. The extension uses Postman's schema, so if you're familiar with Postman, you'll feel right at home.

Run Collections: Test Everything at Once

One of my favorite features is the Collection Runner. When you're developing an API, you often need to test multiple endpoints to make sure everything works together properly. With Golden Retriever, you can:

Run an entire collection of requests with a single click
Test with multiple iterations to check for consistency and performance
View detailed statistics for each request
Easily identify slow endpoints or failures

This is incredibly useful when:

You've made changes to your API and want to ensure nothing broke
You're preparing for a release and need to validate all endpoints
You want to stress-test your API under load
You're onboarding a new team member and want to show them how the API works

The Collection Runner supports all the same features as individual requests, including environment variables and tests.

GraphQL Support

Golden Retriever isn't just for REST APIs. It provides first-class support for GraphQL with a dedicated editor experience. Here's how it works:

query GetUser($id: ID!) {
  user(id: $id) {
    name
    email
  }
}

{
  "id": "123e4567-e89b-12d3-a456-426614174000"
}

The GraphQL editor gives you:

A separate variables section for your JSON inputs
The ability to use collection environment variables within both queries and variables

Whether you're working with SpaceX's public GraphQL API or your own custom schema, just set the URL to your graphql, hit send, and you're good to go.

Try It Out Yourself

Ready to give it a spin? Here's how to get started:

Install Golden Retriever from the VS Code Marketplace.
Open VS Code, create a collections folder in your workspace, and start adding requests.
Need a sample project? Clone this Hono-based example to see it in action with a real server.

The extension welcomes you with a clean interface, and if you've used Postman, it'll feel familiar.

Why "Golden Retriever"?

Because it's loyal, dependable, and fetches your API responses with a wagging tail (metaphorically speaking). I've been using it daily, and it's saved me countless hours. Whether you're a solo dev tinkering with APIs or part of a team juggling microservices, I think you'll find it as handy as I do.

Oh, and if you're curious about more tool automation, check out my other extension Corgi that helps manage local development setup of multiple microservices and databases. Its primary use case is to syntax highlight Corgi go cli and to add useful commands to it. There is a sneak peak of it in my YouTube video in the end of golden retriever demo.

So, what do you think? Grab it from the Marketplace, play around, and let me know your thoughts in the comments. Got questions? I'd love to hear them!

Happy testing! 🐾

Photo by Filios Sazeides on Unsplash