DEV Community: W Ian Douglas

How to Choose Between Subagents and Subrecipes in goose

W Ian Douglas — Mon, 29 Sep 2025 14:10:00 +0000

When you're working on complex projects with goose, you'll often need to break work into multiple tasks and run them with AI agents. Goose gives you two powerful ways to do this: subagents and subrecipes. Both can run multiple AI instances in parallel, but they work differently. Picking which one to use can be confusing, so we're going to guide you to a decision.

I've been using both approaches, and the choice between them depends on what you're trying to accomplish. Let me break down when to use each method and show you real examples.

The Core Difference: To Re-Use or Not Re-Use

Subagents are temporary AI instances that you create with natural language in your prompt and tend to be one-off tasks and then disappear.

Subrecipes are pre-written files full of instructions that define reusable workflows you can run repeatedly with customized parameters.

The TL;DR: subagents are for quick, one-off delegation. Subrecipes are for structured, repeatable processes.

Also, both are still in 'experimental' status, so there's always a possibility their features and capabilities will change over time.

Subagents: Quick and Flexible

Subagents excel when you're in a goose session and just want task delegation without setup overhead. Here's how simple they are to use:

Build a simple task management web app doing these 3 tasks in parallel:

- one task writes the backend API code (Node.js/Express with basic CRUD operations for tasks)
- one task writes comprehensive tests for the API endpoints
- one task creates user documentation explaining how to use the API

Each task should work independently and complete their part simultaneously.

Goose automatically spawns three independent AI instances, and each works on a different component. You get real-time progress tracking and they all work in parallel from that prompt. You're off and running: no setup, no configuration files, just natural language instructions.

What Makes Subagents Great

Quick setup with natural language -- No recipe files to write. Just describe what you want in your prompt.
Process isolation -- Failures don't affect your main workflow. Each subagent runs independently.
Context preservation -- Keeps your main chat clean by offloading detailed work to separate instances.
Flexible execution -- Easy to specify parallel or sequential execution in your prompt.
External integration -- Can use external AI agents like Codex or Claude Code.
Real-time progress -- Live monitoring dashboard shows task completion status.

Subagent Limitations

Limited reusability -- Each subagent is created from scratch. No saved configuration.
Common LLM -- All subagents share the same LLM model as the parent session.
Tool restrictions -- Subagents can't manage extensions, they can only use what the main session already had access to before the subagents were launched.
No persistence -- Configuration isn't saved for future use.

Subrecipes: Structured and Reusable

Subrecipes solve the reusability problem. While main "parent" recipes can be in YAML or JSON, subrecipes can only be written in YAML format. These files define structured workflows with parameters, validation, extensions to use, and even allow you to pick a different provider/model to use for the work.

For detailed subrecipe examples and implementation guides, check out our subrecipes blog post and advanced recipe tips video on YouTube.

What Makes Subrecipes Powerful

High reusability -- Recipe files can be shared and version controlled across projects.
Structured parameters -- Type-safe parameter handling with validation and documentation.
Template support -- Dynamic parameter injection using template syntax.
Full tool access -- Subrecipes can use any extensions and tools available to goose.
LLM customization -- Each subrecipe can specify its own LLM model to use.
Conditional logic -- Smart parameter passing based on conversation context.
Workflow orchestration -- Complex multi-step processes with dependencies and execution order control.

Subrecipe Trade-offs

Setup complexity -- Requires careful YAML file creation and parameter definition.
Learning curve -- Need to understand recipe syntax and structure.
File management -- Must organize and maintain recipe files.

A Decision Framework

Use subagents when:

You need quick, one-off task delegation
Tasks can be completed independently and don't need to be repeated

Use subrecipes when:

Building reusable workflows you can share with your team
Need structured parameter handling

Common Benefits and Limitations of Both Approaches

Both of these features share some limitations. We've already mentioned the experimental and evolving nature, but there are a few more important ones to note:

Subrecipes and subagents run their tasks in isolation and do not share state with one another. This isolation helps prevent conflicts and keeps tasks self-contained. If you do need to share information between the processes, you will have to be very explicit about this in your prompts and instructions.
Neither can spawn additional similar workers: subagents can't create more subagents, and subrecipes can't call other subrecipes. This prevents runaway processes but limits deep nesting.
Whether you're using subagents or subrecipes, you can only run up to 10 concurrent parallel workers total. This is not user-configurable, but this limit keeps resource usage manageable; this may limit very large-scale parallelism.

Getting Started

My recommendation: start with subagents to experiment and understand your workflow needs. They're easier to get started with because you don't need to write configuration files first.

Once you identify patterns you want to repeat, you can convert that subagent workflow session into a recipe and subrecipe structure. This gives you the best progression from experimentation to production.

The Choice is Yours

The choice depends on your specific needs and workflow requirements. Quick tasks that won't be repeated favor subagents. Complex workflows with multiple steps or customization favor subrecipes.

Your workflow requirements should drive the decision.

Share your subagent prompts or subrecipe ideas with us on our Discord community or GitHub discussions.

Automate Your Complex Workflows with Sub-Recipes in goose

W Ian Douglas — Fri, 26 Sep 2025 17:06:04 +0000

Remember when you first learned to cook? You probably started with simple recipes like scrambled eggs or toast. But eventually you wanted to make something more complex, like a full dinner with multiple dishes. That's how subrecipes work in goose: each recipe can run stand-alone for a dedicated task, and a main recipe can orchestrate how they run.

Let's explore goose subrecipes together! You're about to learn know how to orchestrate multiple AI models, coordinate tasks, and build workflows that will turn you into a "head chef" user with goose.

Why Subrecipes Matter

Think of subrecipes like having a team of specialized chefs in your kitchen. One chef is amazing at making desserts, another excels at grilling, and a third is the salad master. Instead of having one person try to do everything, you let each specialist focus on what they do best.

That's exactly what subrecipes do for your goose workflows. You can have one recipe that's optimized for creative tasks like image generation, another that's perfect for technical documentation, and a third that excels at writing code. Then you orchestrate them all from a main recipe.

A Real-World Example: Project Setup Automation

I built a project setup system that creates a complete project with documentation, logo generator, and an initial codebase. Instead of one massive recipe trying to do everything, I broke it into specialized pieces.

Here's the parent recipe that orchestrates everything:

version: 1.0.0
title: "Complete Project Setup"
description: "Creates a full project with README, image, and code using specialized models"
instructions: |
  You are a project orchestrator. Execute the sub-recipes to create a complete project setup.
  Each sub-recipe is specialized for its task and uses the optimal model and instructions for that work.

  EXECUTION ORDER: 
  - Run image-creator and code-writer first, in parallel
  - When they both succeed and finish, then run readme-generator; don't make the readme until we have a logo and finished code project to reference

prompt: |
  Create a complete project setup for: {{ project_name }} within ./project

  Execute these tasks:
  - Create a project logo/image  
  - Write the initial codebase
  - Generate project documentation

  Project details:
  - Name: {{ project_name }}
  - Language: {{ language }}
  - Description: {{ description }}

parameters:
  - key: project_name
    input_type: string
    requirement: required
    description: "Name of the project to create"

  - key: language
    input_type: string
    requirement: optional
    description: "Programming language to use"
    default: python

  - key: description
    input_type: string
    requirement: required
    description: "Project description"

sub_recipes:

  - name: "image-creator" 
    path: "{{ recipe_dir }}/2-image.yaml"
    description: "Create project logo using GPT"
    values:
      project_name: "{{ project_name }}"
      description: "{{ description }}"

  - name: "code-writer"
    path: "{{ recipe_dir }}/3-code.yaml" 
    description: "Write initial code using Claude"
    values:
      project_name: "{{ project_name }}"
      language: "{{ language }}"
      description: "{{ description }}"

  - name: "readme-generator"
    path: "{{ recipe_dir }}/1-readme.yaml"
    description: "Generate comprehensive README using Gemini"
    sequential_when_repeated: true
    values:
      project_name: "{{ project_name }}"
      description: "{{ description }}"
      language: "{{ language }}"


extensions:
  - type: builtin
    name: developer

Notice how each subrecipe gets only the parameters it needs, and we can control the execution order in our prompt.

By default, subrecipes run in parallel. This is like having multiple chefs working simultaneously in different parts of the kitchen. The image generation and code writing happen at the same time, cutting your total execution time.

Sometimes you need things to happen in order. The best approach here is to list the specific order you want in the recipe instructions. In this example, I want the image and code generation to happen in parallel (because they don't depend on each other), and only run the README generation when the other two steps are both successful so it can reference the generated files.

Specialized Subrecipes for Different Tasks

Each subrecipe is optimized for its specific job.

Image Generation with OpenAI DALL-E

For the image generation, we could use an image generator MCP system in a smaller recipe. For this example, though, I'm going to have this recipe write a specific script to call OpenAI's DALL-E API directly. This gives me more control over the image generation process and avoids external resources.

version: 1.0.0
title: "Project Image Creator"
description: "Generate project logos and images"

settings:
  goose_provider: "databricks"
  goose_model: "goose-claude-4-sonnet"
  temperature: 0.1

instructions: |
  You are a creative designer specializing in logo and image creation.
  Create visually appealing, professional images that represent the project's purpose.

  Generate images using OpenAI's DALL-E API

activities:
  - Generate images using DALL-E API
  - Save images to specified locations
  - Handle API errors gracefully

prompt: |
  Create a project logo/image for "{{ project_name }}" - {{ description }}.

  Your working folder is "{{recipe_dir}}/project/"

  Task: Generate an image using OpenAI's DALL-E API directly via Python script.

  Image specifications:
  - Size: 1024x1024
  - Quality: standard
  - Output file: "logo.png"

  - Modern, professional design suitable for a tech API
  - Include themed elements based on project description: {{ description}}
  - Professional color scheme
  - High quality and suitable for documentation

  Steps:
  1. First, verify the OPENAI_API_KEY environment variable is set
  2. Create a Python script:
    - the filename should be "./project/logo_generator.py", create that file and edit it in place
    - it should calls OpenAI's DALL-E API directly to generate an image
    - the output folder to store the image is the same folder in which the logo_generator.py script exists
    - for example, the final image should be "./project/logo.png" but not have the "./project" path hard-coded in the script
  3. Execute the script to generate the image with the specified parameters
  4. Verify the image was created successfully and report the file location
  5. If there are any errors, provide clear troubleshooting guidance

  Implementation approach:
  - Use the developer extension to create and run a Python script
  - The script should use only standard library modules (urllib, json, base64) to avoid dependency issues
  - Call OpenAI's DALL-E 3 API directly with proper authentication
  - Handle API responses and save the base64-encoded image to the specified location
  - Provide detailed error messages for troubleshooting

  Requirements:
  - The OPENAI_API_KEY environment variable must be set
  - Handle any API errors gracefully and provide helpful error messages

retry:
  max_retries: 3
  checks:
    - type: shell
      command: test -f "{{recipe_dir}}/project/logo_generator.py"
    - type: shell
      command: test -f "{{recipe_dir}}/project/logo.png"
  on_failure: rm -f "{{recipe_dir}}/project/logo.png" && rm -rf "{{recipe_dir}}/project/logo_generator.py"
  timeout_seconds: 60  

extensions:
  - type: builtin
    name: developer

parameters:
  - key: project_name
    input_type: string
    requirement: required
    description: "Project name for the logo"
  - key: description
    input_type: string
    requirement: required
    description: "What the project is about"

If you did want more creativity, you could use an image generation MCP server and use a model that's optimized for artistic image creation:

settings:
  goose_provider: "openai"
  goose_model: "gpt-4o"
  temperature: 0.8

Code Generation with Claude Sonnet

The code generation recipe uses Claude for technical precision. We set a low "temperature" value to ensure the generated code is reliable and follows best practices.

version: 1.0.0
title: "Code Generator"
description: "Write initial project codebase"

settings:
  goose_provider: "anthropic"
  goose_model: "claude-sonnet-4"
  temperature: 0.1

instructions: |
  You are a senior software engineer who writes clean, well-documented, and maintainable code.
  Follow best practices and include comprehensive error handling and documentation.

prompt: |
  Write the initial codebase for "{{ project_name }}".

  Your project folder will be ./project/

  Requirements:
  - Language: {{ language }}
  - Description: {{ description }}
  - Include proper project structure
  - Include error handling
  - Follow language-specific best practices
  - Add unit tests where appropriate

  Documentation:
  - Add comprehensive documentation in a file called USAGE.md
  - do not create a README.md file

extensions:
  - type: builtin
    name: developer

parameters:
  - key: project_name
    input_type: string
    requirement: required
    description: "Project name"
  - key: language
    input_type: string
    requirement: required
    default: "python"
    description: "Programming language"
  - key: description
    input_type: string
    requirement: required
    description: "Project description"

README Generation with Gemini

And the documentation recipe uses Gemini for comprehensive README generation:

version: 1.0.0
title: "README Generator"
description: "Generate comprehensive project documentation"

settings:
  goose_provider: "google"
  goose_model: "gemini-2.5-flash"
  temperature: 0.5

instructions: |
  You are a technical documentation specialist. Create comprehensive, well-structured README files
  that are informative, professional, and follow best practices.

prompt: |
  Create a comprehensive README.md file for the project "{{ project_name }}".

  Project details:
  - Name: {{ project_name }}
  - Language: {{ language }}
  - Description: {{ description }}

  Include sections for:
  - Project overview and features with lots of excitement over the capabilities of the project
  - Installation instructions
  - Usage examples

  the code and logo for this project will be in ./project; include the logo.png at the top of the readme, and instructions on running the code in the readme.

  the readme file should be placed in ./project/

extensions:
  - type: builtin
    name: developer

parameters:
  - key: project_name
    input_type: string
    requirement: required
    description: "Project name"
  - key: language
    input_type: string
    requirement: required
    description: "Programming language"
  - key: description
    input_type: string
    requirement: required
    description: "Project description"

Debugging Tips for Subrecipes

Debugging subrecipes is straightforward if you follow a few best practices:

1. Make Sure Each Recipe Runs Independently

This is crucial. Each subrecipe should work perfectly on its own. Test them individually before combining them. If a subrecipe fails when run alone, it will definitely fail as part of a larger workflow.

# Test each subrecipe individually first
goose run --recipe 1-readme.yaml --params project_name="test" language="python" description="test project"
goose run --recipe 2-image.yaml --params project_name="test" description="test project"  
goose run --recipe 3-code.yaml --params project_name="test" language="python" description="test project"

2. Use recipe_dir for Relative Paths

Always use {{ recipe_dir }} for file paths within your recipes. This makes your recipes portable and prevents path issues when someone runs them from a different directory.

3. Parameter Validation is Your Friend

Include clear parameter descriptions and mark required parameters. This prevents confusing errors when someone forgets to pass a needed value.

4. Add Retry Logic for Flaky Operations

Network calls, file operations, and API calls can fail. Add retry logic with proper cleanup:

retry:
  max_retries: 3
  checks:
    - type: shell
      command: test -f "expected_output.txt"
  on_failure: rm -f "partial_output.txt"
  timeout_seconds: 60

5. Monitor Resource Usage

When running multiple subrecipes in parallel, watch your API rate limits and system resources. You might need to adjust the execution strategy for resource-intensive tasks.

More Subrecipe Workflows

Start simple. Pick a complex task you do regularly and break it into 2-3 smaller pieces. Create individual recipes for each piece, test them separately, then build a parent recipe to orchestrate them.

Some ideas to get you started:

Content Creation Pipeline: Research, writing, editing, and formatting
Development Workflow: Code generation, testing, documentation, deployment
Data Processing: Collection, cleaning, analysis, visualization
Project Setup: Structure creation, configuration, initial files, documentation

The Future of Orchestrated AI

Subrecipes represent something bigger than just a goose feature. They're a glimpse into how we'll work with AI in the future -- not as monolithic systems trying to do everything, but as specialized agents working together toward common goals.

Each recipe becomes a reusable component that you can mix and match. Build a library of specialized recipes, then combine them in different ways for different projects. It's like having a toolkit of AI specialists ready to tackle any challenge.

Ready to start building your own subrecipe workflows? The kitchen is open, and all the ingredients are waiting for you.

Share Your Recipes with Us!

Do you have a recipe you'd like to share with the community? We'd love to feature them in our Recipe Cookbook!
How to contribute:

Fork the goose repository
Add your recipe YAML file to the documentation/src/pages/recipes/data/recipes/ directory
Create a pull request following our Recipe Contribution Guide Browse existing recipes for inspiration and formatting examples.

What's in my .goosehints file (and why it probably shouldn't be)

W Ian Douglas — Thu, 05 Jun 2025 21:14:55 +0000

As Goose users, we have two main ways to provide persistent context to our AI assistant: the .goosehints file and the Memory Extension MCP server. Today, I'll share what's in my .goosehints file, why some of it should probably move to the Memory Extension, and how you can make that choice.

AI Agents and Memory

Imagine ordering coffee at two different cafes. At the first cafe, you're a first-time customer, carefully explaining "medium mocha latte, fat-free milk, extra hot, no foam, with one pump of vanilla." At your regular coffee spot, though, the barista sees you coming and just says "the usual?"

That stored knowledge – your preferences, quirks, and routine – makes the whole interaction faster and more pleasant for everyone.

This is exactly the challenge we face with AI assistants. By default, they start each conversation (aka, "context window") fresh – no memory of your coding standards, documentation preferences, or how you like your pull requests structured. The same way you'd get tired of reciting your detailed coffee order every morning, it's inefficient to repeatedly explain to your AI assistant that you prefer Python's Black formatter, want detailed commit messages, and or how you want to construct a briefing going to everyone in the company.

This is where persistent context comes in. Through tools like .goosehints and the Memory Extension MCP server, we can give our AI assistants the equivalent of a barista's "regular customer" knowledge. But just as you wouldn't want your barista memorizing your entire life story just to make your coffee, we need to be thoughtful about what context we make persistent. The key is finding the right balance between having enough context to work efficiently and not overwhelming our systems with unnecessary information.

Let's explore how to strike that balance.

What is .goosehints?

.goosehints is a configuration file that lives in your Goose directory (usually ~/.config/goose/). It can contain any information that you want Goose to process every time you interact with Goose, providing a foundation for how it interacts with you.

You can read more about .goosehints in the Goose documentation.

What is the Memory Extension?

The Memory Extension is a dynamic storage system using the Model Context Protocol that allows you to store and retrieve context on-demand using tags or keywords. It lives in your ~/.goose/memory directory (local) or ~/.config/goose/memory (global).

Unlike .goosehints, which is static and loaded entirely with every request, Memory Extension can be updated and accessed as needed, allowing for more flexible and user-specific configurations.

How are .goosehints and Memory Extension used in Goose?

At a very high level, when you have a conversation with Goose, it processes your request in two main steps:

Goose interprets your request to detect tags or keywords needed for possible Memory Extension lookups. Then it loads your entire .goosehints file, and sends that, along with any relevant Memory Extension entries to the LLM to generate a response.

The Implications of .goosehints

To reiterate, every single line in your .goosehints file gets sent with every request to Goose. If you write a ton of rules and ideas with all your project preferences, coding standards, and workflow documentation and so on into the .goosehints file, the ENTIRE file is being transmitted and processed every time you ask Goose anything, even something as simple as "what time is it?"

This is particularly important for users who are paying for their own LLM access (like ChatGPT or Gemini). Here's why:

Input Tokens = Real Money: Every line in your .goosehints file consumes input tokens. The LLM must process these tokens as part of its system instructions before it even looks at your question. While a small .goosehints file might not seem like a big deal, it can quickly add up if you're not careful. All-day vibe coding sessions are going to be using lots of tokens just interpreting that whole .goosehints file every time.
Context Window Impact: Large .goosehints files eat into your context window, which is the amount of information the LLM can consider at one time. If your .goosehints file is too big, it can push out important context from your actual question or task, leading to less accurate or helpful responses.

This means a large .goosehints file can:

Increase your AI costs
Reduce the amount of context available for actual work
Limit the complexity of tasks you can perform

Where I went wrong with my .goosehints

When I first started using Goose, I treated .goosehints like a catch-all for everything I wanted Goose to remember. I included:

rules on writing outlines for blog posts
how I like Python code written and formatted
notes about frontend development
etc

That meant that every request I would make asking Goose to help come up with a catchy blog title was sending all of my rules about Python and using Tailwind CSS.

So what "belongs" in .goosehints?

Here's something I end nearly every AI prompt with:

If you're not 95% sure how to complete these instructions, or that you'll be at least 95% factually accurate, do not guess or make things up. Stop and ask me for more information or direction. If you're finding resources online, give me 1 or 2 URLs that informed your response.

I also like to end many of my prompts asking if Goose has any clarifying questions before doing the work I'm attempting:

Based on the information I've provided, ask me any clarifying questions before doing any work, or tell me that you're ready to proceed.

Since these are things that I definitely want to add to every request I make to Goose, I've simplified my .goosehints file to include only these types of rules and standards.

Everything else got moved into the Memory Extension

The Memory Extension uses a tagging system to remember context based on keywords. You can give Goose a command to "remember" something, and Goose will write a Memory entry with appropriate tags. The next time you ask Goose to do something with Python, it will parse your request, look for relevant tags, and use appropriate Memory entries to send as part of the context for just that request.

So all of my Python rules can be written as a command to Goose like this:

Remember that when I ask about Python, I want to conform to the following standards and guidelines:
- use Python 3.12+ syntax
- use type hints for all function signatures
- use f-strings for string formatting
- use the latest Python features and libraries
- use Flake8 for linting
- use black for formatting
- if I ask to build a CLI based tool, expect to take command line arguments and make a colorful interface using ANSI colors and the rich library
- if I ask to build an API, expect to build a RESTful API use FastAPI and to send back data in JSON format

Now, Goose will only send these Python-related rules when I ask it to do something with Python. This is far more efficient.

Here's the resulting Memory file that Goose made:

# python standards development formatting linting api cli
Python Development Standards:
- Python version: 3.12+
- Mandatory type hints for all function signatures
- Use f-strings for string formatting
- Use latest Python features and libraries
- Code formatting: black
- Linting: Flake8
- CLI tools: Use command line arguments and rich library for colorful interface
- APIs: Use FastAPI for RESTful APIs with JSON responses

The first line starts with a hash # and a space-separated list of keywords and tags that it will use to discern when or whether to retrieve this content to send with a request to my LLM.

To hint, or not to hint?

While .goosehints is powerful, it's important to use it judiciously. By moving appropriate content to the Memory Extension, you can optimize your Goose experience and keep your AI context use more efficient. Remember: every line in .goosehints is sent with every request, so choose wisely what goes there.

Share your own .goosehints optimization stories in the Goose community on Discord!

Goose gets a Driver's License

W Ian Douglas — Wed, 21 May 2025 18:00:00 +0000

I taught Goose how to drive (a rover)

Goose has no hands, no eyes, and no spatial awareness, but it can drive a rover!

I came across a demo video from Deemkeen, where he used Goose to control a Makeblock mbot2 rover using natural language commands like "drive forward/backward," "beep," and "turn left/right" powered by a Java-based MCP server and MQTT.

Inspired and excited to take it further, I taught the rover to spin, blink colorful lights, and help me take over the world!

Getting Started with MQTT

I needed to get a few tools installed on my development environment, including Docker, MQTT (brew install mosquitto), and Java.

A Docker Compose file was provided to get started with MQTT, and I needed to make a few changes, and create some subfolders to store data. Goose helped with these instructions:

version: '3.8'

services:
  mosquitto:
    image: eclipse-mosquitto
    hostname: mosquitto
    container_name: mosquitto
    restart: unless-stopped
    command: /usr/sbin/mosquitto -c /etc/mosquitto/config/mosquitto.conf -v
    ports:
      - "0.0.0.0:1883:1883"
      - "9001:9001"
    volumes:
      - ./mosquitto:/etc/mosquitto
      - ./mosquitto/data:/mosquitto/data
      - ./mosquitto/log:/mosquitto/log

mkdir -p mosquitto/data mosquitto/log mosquitto/config

Then a docker compose up command started the MQTT server.

By default, this setup will not use authentication for MQTT, but
in a production environment, these would be important to set up
to avoid unauthorized access to the MQTT server.

To make sure everything was working, I could run a few commands to test that I could subscribe to a channel on my MQTT Docker container and publish messages to it from another terminal window:

# terminal 1: subscribe to a channel called "MBOT/TOPIC"
mosquitto_sub -h localhost -p 1883 -t MBOT/TOPIC -v

# terminal 2: publish a message to the channel "MBOT/TOPIC"
mosquitto_pub -h localhost -p 1883 -t MBOT/TOPIC -m "BEEP"

We see the resulting message in terminal 1:

# terminal 1 sees this output:
MBOT/TOPIC BEEP

Setting Up the mbot2

After the assembly of the mbot2 rover, which took about 15 minutes, I used Makeblock's web-based IDE to copy/paste Deemkeen's Python code to the IDE and upload it to the mbot2. I added appropriate values for wifi, MQTT server, and which MQTT "topic" to subscribe to for commands.

Once the mbot2 rebooted to use the new code, I could reissue the "BEEP" command from my terminal, and the mbot2 beeped. so it was on to the next step.

Setting up the local MCP server

I had some trouble compiling the Java MCP server (I'm a Python developer), but I was able to get the MCP server compiled by skipping the tests for the time being:

mvn clean package -DskipTests

This created a JAR file that we could run on the command line:

# 3 required environment variables for MQTT
export MQTT_SERVER_URI=tcp://localhost:1883
export MQTT_USERNAME=""
export MQTT_PASSWORD=""
/path/to/java -jar /path/to/mbotmcp-0.0.1-SNAPSHOT.jar

To test that MCP was working, I used the MCP inspector tool to send commands to MQTT.

npx @modelcontextprotocol/inspector /path/to/java -jar /path/to/mbotmcp-0.0.1-SNAPSHOT.jar

This starts up a local web server (the command line output will tell you which port to access in your browser, ie, loalhost:6274), where you can "connect" to the server, and request a list of tools, resources, prompts, from the MCP server. In this case, I see a list of tools available such as "mbotBeep" or "mbotExplore".

Goose learns how to drive!

Following our mbot MCP tutorial we can set up our MCP extension just like we ran our Java JAR file with the environment variables.

Now we can give Goose commands like "drive in a square pattern by making left turns and moving forward, and beeping before you turn" and it will send the commands to the mbot2 rover via MQTT.

I didn't want my mbot2 rover to gain too much territory, so I decided to make some modifications to limit how far it would go.

Modifications I made to the Python code

Deemkeen's Python code allows for the following commands:

"turn left" or "turn right"
drive "forward" or "backward"
"explore" randomly
"stop" exploring
"beep"

The default distance in Deemkeen's code seemed a little long, and the turn angles are set to 90 degrees. I shortened the distance the mbot could drive, and to turn at 45 degrees instead. I added a "spin" command for both clockwise and counter-clockwise, and a "blink" command to change the color of the lights on the mbot2. There are a large number of API calls available to access the mbot2 motor hardware and sensors.

Next, I had to make sure my Java code was updated to include these new commands to send an appropriate "SPINLEFT" or "BLINKRED" commands to MQTT so the rover could respond to the commands properly.

Finally, the rover includes an ultrasonic distance sensor, which look like "eyes" on the rover, which I felt was more appropriate to be the "front" of the rover, so I reversed Deemkeen's direction code in Python to move the wheels in the opposite direction from Deemkeen's original code.

Goose changes for the video

I grew up with Pinky and the Brain, and I wanted to have some fun with the mbot2 extension. I decided to add a few "Evil AI" commands to Goose to make it seem like it was trying to "take over the world." I added the following instructions to my .goosehints file to include fun instructions for the mbot2 extension:

If I ask you "what do you want to do tonight, Goose?" I 
want you to reply with "The same thing we do every night,
Ian. TRY TO TAKE OVER THE WORLD!!!!" and tell my mbot2 
rover to blink its lights red, then start exploring.

For the video recording, I used a voice modifier to narrate Goose's response in a "robotic" voice, but I'm sure someone will create an MCP server for text-to-speech soon enough!

Credit where it's due

We want to extend a huge thank you to deemkeen for their open-source work which inspired this project, and to the Makeblock team for creating such a fun rover to work with.

We're always excited to see what the community is up to. If you're working on your own Goose-powered experiment, come share it with us on Discord!

MCP Is Rewriting the Rules of API Integration

W Ian Douglas — Tue, 22 Apr 2025 16:23:23 +0000

As developers, we're always looking for ways to build more efficient, scalable, and intelligent applications. For years, RESTful APIs have been our go-to for connecting services. Here are some ways you can integrate AI agents and MCP into your existing API infrastructure to make it smarter, more efficient, and easier to maintain.

Introduction: The Intelligent Evolution of Your APIs

In March 2023, OpenAI announced an easier integration to ChatGPT by using properly-formatted OpenAPI specification files with meticulously-written and detailed instructions in the same file. This announcement gained a lot of attention in developer communities. The business impact was having developers and documentation writers working on one gigantic spec file together, to provide ChatGPT the necessary context to understand which API to use, and how.

Skip ahead just a short while, and AI agents combined with the Model Context Protocol (MCP) are splitting this workload where MCP could contain the context and awareness, and your API team can focus on the API itself. These aren't just incremental improvements, either; the combination of Agentic AI and MCP represent a fundamental shift in how we connect and interact with data and services.

The shift to using AI Agents and MCP has the potential to be as big a change as the introduction of REST APIs was back in 2005. Imagine a world where integrations are more dynamic, context-aware, and require less manual coding. This isn't a distant future -- it's already happening. This is an opportunity for us to boost productivity, enhance app intelligence, and ultimately deliver better experiences to our users, clients, and customers.

Let's use an example: imagine your team wants AI to handle dynamic pricing adjustments in your e-commerce workflow at Square. If you could gain a faster response time to market changes or inventory, you could reduce the need to build dozens or hundreds of dynamic pricing rules into your code. Your productivity as a developer goes up, and you have less code to maintain. You could write those rules in a more spoken-language way, and the AI agent can handle the rest through MCP and your APIs.

From Static Endpoints to Intelligent Interactions

Current Landscape: The Limitations of Traditional APIs

Many of our current systems rely heavily on traditional APIs, like RESTful APIs, which are designed with static endpoints that respond to specific requests with specific results. While these APIs have served us well (and certainly aren't going away any time soon), they come with limitations:

The static nature of RESTful APIs makes them more rigid, less adaptable to business changes, and require hard rules around versioning to provide compatibility.
They often require significant manual effort to define endpoints, handle data transformations, and manage complex workflows. This can lead to slower development cycles and increased maintenance overhead.

The AI opportunity lies in leveraging intelligent agents, combined with MCP, to create more adaptive integrations. These agents can understand context, discover relevant services, and negotiate interactions in a more dynamic way than static API calls. The static APIs are still being used, but the AI agents can navigate those more easily than changing your code calling the APIs and parsing and validating responses, and handling errors.

Development Impact: Boosting Productivity, Enhancing User Experiences

This dual integration of AI agents and MCP can have a significant positive impact on your development processes and the applications you build:

Developer Productivity: By automating many integration tasks and reducing the need for extensive manual coding, AI agents free up our time to focus on core application logic and innovation. (And testing. And security. And documentation. And...)
Customer Satisfaction: Intelligent integrations can lead to more personalized and responsive user experiences. Agents can facilitate real-time data analysis and context-aware interactions, making our applications smarter and more user-friendly.
Scalability: As your application grows, the complexity of managing multiple APIs can become overwhelming. Using multiple AI agents can help manage this complexity by dynamically adapting to changes in the underlying services and workflows.

Business Impact: Driving Efficiency and Cost Savings

From the business side, the integration of AI agents and MCP can lead to significant cost savings and efficiency gains. Here are some key areas where you can expect to see improvements:

Example ROI Calculation (Per Developer):

Traditional API Development:

Average time to add feature: 2 weeks
Developer cost: $150/hour
Assuming 40 hours/week: 2 weeks * 40 hours/week * $150/hour = $12,000

AI-Agent Enabled:

Average time to add feature: 2 days
Developer cost: $150/hour
Assuming 8 hours/day: 2 days * 8 hours/day * $150/hour = $2,400

Annual savings for 50 features:

( $12,000 - $2,400 ) * 50 = $480,000 per developer

This illustrates the potential for significant time and cost savings per developer by adopting AI agents.

Integrating AI and MCP: Navigating the Landscape

Integrating AI agents, especially through a platform like MCP, requires careful consideration.

Risk Management: MCP, while promising, is a newer technology. Your team needs to thoroughly evaluate potential security concerns and understand the maturity of the platform before deep integration into critical systems.
Planning for Continuity and Versioning: As with any evolving technology, you will need strategies for ensuring the continuity of integrations and managing versioning of both the AI agents and MCP itself.

Phased Approach: A Practical Integration Strategy

A step-by-step approach can help mitigate risks, and learn effectively through feedback, as you integrate AI agents via MCP:

Phase 1: Assessment (Initial Exploration)

Look through your existing API usage, and identify integration possibilities
Consider the ROI: start with small ideas and grow your integration efforts over time
Build initial business/tech plans for adopting AI agents and MCP

Phase 2: A/B Testing and Pilot Projects

Select a low-risk, high-value service for initial AI agent integration via MCP
Implement the integration, then do thorough A/B testing and comparisons against the traditional API approach
Measure the results, gather benchmark/performance data, and talk to the team about what you find

Phase 3: Scale and Optimization

Take it a step at a time: based on the results, take on bigger and more complex integration ideas
Continue to optimize your integration process over time
Use feedback from your dev teams and end-users to refine your process

Measuring Success: Quantifying the Impact

For the business readers: to understand the benefits of integrating AI agents via MCP, here are some key performance indicators (KPIs) you can track:

Development Velocity
Error Rates
Customer Satisfaction

Build Your Case Study and Share Your Learnings

Documenting your team's journey and sharing your experiences is valuable for both your team and the wider developer community. Here are a few things you should share to help demonstrate the impact of your projects:

Before and After Metrics: what kind of improvements did you see in development time, error rates after integrating AI agents and MCP?
Team Feedback: there's going to be a learning curve here, similar to what we all experienced when integrating APIs; gather feedback about how the integration workflows are going and what could be improved
Customer/End User Impact: highlight any positive changes in user engagement, satisfaction, or other user/customer metrics
Lessons Learned: perhaps the most important; what worked well, what didn't, how are you changing the process for the next phase of integration?

Where do we go from here?

Understanding your existing integrations, and identifying potential areas for improvement with AI agents and MCP is your starting point. There is a lot to learn about integrating AI agents, and MCP is still a new technology.

Finding those opportunities where AI can help, and outlining a plan to gradually adopt AI and MCP into your projects is the best way to start.

Keep in mind, this integration landscape is still evolving. Stay open to new ideas, and adapt your approach as the technology matures. Building smarter applications is a journey, and there will be forks in the road.

Additional Reading:

TL;DR Common Questions

How will MCP help with APIs?

Start with this post by Angie Jones. MCP provides context about your API, to give AI Agents more context and awareness of the capabilities of your API endpoints and responses. This can help the Agent understand the intent of the request, and dynamically invoke (or "call") to underlying API endpoint, handle data transformation, and return a response. No more manually writing the code, response validators, error handlers, and so on!

What are some initial steps I can take as a developer explore AI agents and MCP?

Start by researching the fundamental concepts, and use other existing MCP servers. We recommend starting with Goose to integrate an existing MCP server. We have a growing listof tutorials to help you find some technologies like GitHub, PostgreSQL, Google Maps, and more. Once you feel comfortable with using MCP, you can start building your own MCP server for your own APIs.

What about AI and MCP security?

AI agents can enhance security through better context awareness in interactions, but MCP is still relatively new, and requires careful security evaluations. Your business and dev teams should thoroughly investigate MCP's capabilities to ensure you're building appropriate access control, and managing data privacy.

How long would a full migration typically take?

It's too dynamic to give one solid answer. Integration and migrations can vary a lot, depending on the scope of your existing API usage and existing integrations. Start small, build some pilot projects to try it out, and these might only take a few days or weeks.

What are some potential problems devs might encounter on this AI/MCP journey?

There's a learning curve associated with any technology. This can be compounded when you consider that MCP is still relatively new and evolving. The greater community needs strategies around testing and debugging MCP, as well as considering security and data privacy. This means that what you learn today will need to be re-evaluated even a few short months from now.

How mature and production-ready is MCP for enterprise-level AI integration?

Your approach on this may vary depending on whether you're building your own MCP server, or whether you're using third-party MCP servers in your integration. Developers should evaluate all of the benefits of MCP and consider the work being done around security and data privacy. Focus on a small pilot project or non-critical system initially to assess its suitability for your specific needs. Stay updated on MCP's development roadmap and community feedback.

How to Choose HTTP or gRPC for Your Next API

W Ian Douglas — Thu, 22 Sep 2022 10:14:54 +0000

I recently hosted a Postman livestream, “How We Built it: gRPC Support,” with a few members of the Postman engineering team. During the chat, a lot of great questions were raised about efficiency, how gRPC differs from HTTP-based APIs (like REST and GraphQL), how those are designed and built within Postman, how to do testing, and more. This sparked my interest in doing a deeper technical comparison between the two API types, and why you might choose one over the other.

HTTP-based API development

Most modern REST APIs APIs follow request-response models of communicating between client and server, and build on HTTP version 1.1. This protocol has been around a long time, and is very well supported in software development kits (SDKs), including browser support. The implication of HTTP 1.1, however, is that the protocol relies on a single transactional nature of the communication.

Using an analogy of wanting to ask a friend several questions over the telephone, HTTP 1.1 means we call our friend, ask a question, get an answer, and end the call. We call them again, ask the next question, and end the call again, and so on until we have all of the information we wanted.

REST APIs are widely used, and because their principles are taught to developers, they are well understood within the industry. REST’s alignment with HTTP and its protocol methods make understanding the desired action more clear to developers. These are easier to adopt by other developers because they have a more “shallow” learning curve, typically using JSON data formats for transferring data. JSON has become a highly desired format. Many programming languages serialize and deserialize JSON relatively quickly, again leading to faster implementations. Other formats like XML, BSON, or custom data formats can be used as well, which have their own benefits and drawbacks.

REST APIs offer a flexibility that helps for customization of a company’s API. However, the drawback is that the principles and standards of REST design are loosely followed. The result of this customization is a lack of tools to easily produce documentation or code samples. Postman is a great benefit here, and the OpenAPI Specification can assist as well, to generate documentation and code samples simply by defining the API structure, endpoints, and results. Developers wanting to use the HTTP API must have knowledge of which endpoints are available and how to use them properly.

REST APIs can result in large data payload responses, especially when resources are complex in nature, where developers worry about sending too little data. This over-fetching/under-fetching style of API design sparked a lot of interest in GraphQL, where developers could specify exactly which resources and attributes they wanted in a response. REST may also not be an ideal solution for low-power clients and mobile devices where bandwidth limitations such as data limits make it a less-ideal solution.

GraphQL APIs, which are also generally based on HTTP 1.1 and predominantly use the POST method, remove many of the over-fetching/under-fetching problems inherent in REST APIs of sending “too much” data (that the client discards) or “too little” data (which causes the client to make more calls). GraphQL’s solution was to allow the client to make a request, by name, and inform the server which fields of data it would like to receive in the response. The primary drawback here is that developers need to know the structure of the database to know what is possible to retrieve, and the interaction is still primarily done in text-only formats such as JSON.

gRPC-based API development

Google developed and then released gRPC in 2016 to achieve higher performance communication between microservices. It is an evolved design of RPC, which was created in the 1970s. Designed with HTTP 2.0, it commonly uses Protocol buffers (Protobufs) for a strictly-binary communication format between the client and server.

The primary concepts of building an RPC API are very similar to building a RESTl API. Developers define the rules of the interaction between client and server, like the methods to call. Clients submit the call using arguments to invoke the methods, but unlike REST APIs, which use the HTTP methods like GET and POST to define the desired action, RPC APIs define that method in the URL itself, and the query parameters define the instruction to take.

gRPC implements four kinds of service methods for transfer of data, which allow for flexibility in their overall use:

Unary: the client makes a single request, and the server sends a single response, similar to REST over HTTP 1.1.
Client-streaming: the client can send multiple requests to the server, the last of which is an indication that the streamed data is finished, and the server sends back a single response.
Server-streaming: the client sends an initial request alerting the server that it is ready to receive a stream of data, and the server responds with many responses, the last of which indicates that the stream is complete.
Bidirectional streaming: after an initial Unary connection between the client and server, both the client and server can send streams of information.

Postman’s gRPC request types, listing the Unary, Client-Streaming, Server-Streaming, and Bidirectional Streaming modes

Protocol Buffers allow for a type-safe interface, and are considered to be a “lightweight” communication format. This format is highly compressed and allows for immediate conversion into data structures supported by the client and server’s independent programming languages. (Granted, JSON and text-only formats can also be compressed with many client and server systems supporting compression algorithms like gzip before transport.)

The primary benefit of HTTP 2.0 and the use of Protocol Buffers is speed. Ruwan Fernando determined that gRPC APIs are generally seven to ten times more performant than REST APIs. It’s important to emphasize that the speed increase is not due solely to gRPC but the underlying network layer and data transfer. Using our earlier telephone analogy to ask a friend some questions, HTTP 2.0 would allow us to call our friend one time, give our list of questions, get our list of answers, and then terminate the call, resulting in less overall traffic to reestablish the connection between each question.

gRPC allows a client to execute a “remote” (server-based) instruction as though it were part of the local system. Because there is less serialization/deserialization required between systems, gRPC is beneficial to low-power clients such as mobile devices and IoT devices.

Another benefit of gRPC is its “discoverability.” As an optional extension, gRPC servers can broadcast a list of requests to clients who request it. This “server reflection” is of tremendous value when working with gRPC APIs. While not a complete replacement for documentation, it does allow easier adoption of an API when developers can get a list of supported instructions. Also, code generation is a feature built into gRPC thanks to its “protoc” compiler.

The main downside for gRPC is adoption, and that adoption is due to the complexity of designing and building a gRPC API. gRPC is generally more difficult to set up and debug since Protocol Buffer messages are binary in nature and not easily human-readable. While RESTful libraries and communication types like JSON are natively supported in browsers, gRPC requires third-party libraries such as gRPC-web, as well as a proxy layer, to perform conversions between HTTP 1.1 and HTTP 2.0.

Third-party tooling and library support is still relatively new for supporting gRPC, and this can lead teams to make more internally-facing gRPC-based APIs than customer-facing external APIs. As a result, Postman’s Public API Network shows only a few gRPC APIs, such as Wechaty and NOVA Security. You can see some examples in a workspace that our DevRel team has put together.

Side-by-side comparison of HTTP and gRPC for producing APIs

As an API producer, you have a lot of choices. Postman’s API-first REST APIs are well known for connecting applications and microservices on the internet. REST follows HTTP standards and offers universal support, and is an easier development decision for many teams. While its data transfer is generally larger and its reliance on HTTP 1.1 generates more data transfer to establish connections between requests, its data transfer is easily viewable and readable by developers for software development and debugging purposes.

gRPC’s architectural style is an excellent choice for working across multi-language applications and microservices. Its ability to stream content bidirectionally makes it an efficient choice for systems that require heavier communication loads than single request/response cycles. Its binary data format is far more efficient than RESTful text transfers, and the use of HTTP 2.0 decreases its need to reestablish connections to servers.

An overview of HTTP vs. gRPC at a glance

Check out the examples in our Public gRPC APIs workspace, and search the Postman Public API Network for others—we’ll be sure to highlight more and more of them in the future! We welcome your feedback and contribution as well, so if you find a great public-facing gRPC API, please make a pull request to our workspace.

Technical review by Joyce Lin.

The post How to Choose HTTP or gRPC for Your Next API appeared first on Postman Blog.

How to Test JSON Properties in Postman

W Ian Douglas — Mon, 23 May 2022 17:09:28 +0000

(This article was originally written by Vikram Sahu with technical review by Ian Douglas)

JSON (JavaScript Object Notation) is one of the most used formats for sending and receiving API responses. With the rise of REST APIs, the JSON format has started gaining popularity among technologists. XML had similar popularity and usage, but that popularity has dropped over time with the adoption of JSON among tech communities.

In this article, we’ll walk through an overview of JSON architecture, structure, and its examples. Then, we’ll check out some code snippets that will help us access and test JSON properties with Postman.

JSON architecture

JSON is a text-based data format that’s used to represent data in a structured way based on JavaScript object syntax. As said earlier, it’s the most commonly used format for data exchange between two different machines running at two different locations geographically, or it can be the two applications running on the same machine.

Though it’s very close to JavaScript object syntax, it can be independently used with different programming languages. Due to its popularity and human-readable standards, most programming languages have started supporting the JSON format within their pre-built libraries, which helps users to create or parse JSON data.

JSON data can be easily stored in a file with a file extension called .json and MIME type as application/json. JSON supports the two most used data structures, arrays and objects. Since these data structures are foundational pillars of modern programming language, JSON is strong and useful data-exchange format.

JSON structure

As described above, JSON structure is generated using arrays and objects. This means almost all the basic data structures like strings, numbers, boolean, and other object literals are also supported in the JSON format, making it easier for users to read, manage, build, and test the data with their other software programs. Since JSON is human-readable, it allows the user to generate simple to complex datasets without many efforts.

For example, the simplest dataset can be an object starting with { and ending with } chaving a key/values pair where keys are name, email id, Twitter, GitHub handle and values are as shown in the object below.

{
   "email": "heyjson@example.com",
   "name": "JSON",
   "twitter": "@callmeJSON007",
   "github": "helloworldjsonhere"
}

And the complex dataset can be a combination of objects and arrays, as shown below. The complexity of structure can be increased as per the requirement and accessibility.

{
   "items": [
       {
           "orderID": "0000001211",
           "orderInvoiceNo": "1234567",
           "OrderBlocks": [
               {
                   "lineNo": [1,4,6,8,9,1,4],
                   "ProductCode": "#31451"
               },
               {
                   "lineNo": 2,
                   "ProductCode": "#64311"
               },
               {
                   "lineNo": 3,
                   "ProductCode": "#85959"
               }
           ]
       },
       {
           "orderID": "0000001212",
           "orderInvoiceNo": "1234568",
           "OrderBlocks": [
               {
                   "lineNo": 7,
                   "ProductCode": "#86869"
               },
               {
                   "lineNo": [6,7,4,8,4,2],
                   "ProductCode": "#10384"
               },
               {
                   "lineNo": 12,
                   "ProductCode": "#00873"
               }
           ]
       },
       {
           "orderID": "0000001213",
           "orderInvoiceNo": "1234569",
           "OrderBlocks": [
               {
                   "lineNo": 76,
                   "ProductCode": "#22291"
               }
           ]
       }
   ]
}

Also, as you can see, even though the JSON is big and has multiple nested arrays and objects, it can be read with the same methods as the dataset that we describe above. That’s the magic of JSON.

Test and access JSON properties

As we now know about JSON and how it can be created, let’s check a few code snippets which are commonly asked among different communities, and we’ll access keys and values within the JSON.

To make it convenient and quick, you can fork the following Postman collection or click on the Run in Postman button below.

Let’s walk through a few examples, where we’ll be using code that uses the pm library to run the test method. The text string will appear in the test output. The function inside the test represents an assertion as given below:

An array of all properties in an array of object: In this example, we’ll have an API response body as jsonData and a code snippet showing how to access array properties within an array of object. API response body:

{
   "data": {
       "items": [
           {
               "orderID": "0000001211",
               "orderInvoiceNo": "1234567",
               "OrderBlocks": [
                   {
                       "lineNo": 1,
                       "productCode": "001"
                   },
                   {
                       "lineNo": 2,
                       "productCode": "012"
                   },
                   {
                       "lineNo": 3,
                       "productCode": "013"
                   },
                   {
                       "lineNo": 4,
                       "productCode": "014"
                   }
               ]
           }
       ]
   }
}

Code snippet to get all the properties of objects within an array:

pm.test("array of all properties", () => {
   //get data from API in jsonData
   let jsonData = pm.response.json()
   arrayOfObject = jsonData.data.items[0].OrderBlocks;

   //method 1
   let resIdData = arrayOfObject.map(a => a.lineNo);
   console.log("values of lineNo in array : " + resIdData)

   //method 2
   let resProductCode = arrayOfObject.map(({ productCode }) => productCode);
   console.log("values of productCode in array : " + resProductCode)

});

(Find) Array item by property: In this example, we’ll walk through the response body where we will find array items using JavaScript’s find function, which scans the array and returns the object or value similar to the search term.

{
   "data": {
       "items": [
           {
               "orderID": "0000001211",
               "orderInvoiceNo": "1234567",
               "OrderBlocks": [
                   {
                       "lineNo": 1,
                       "productCode": "001"
                   },
                   {
                       "lineNo": 2,
                       "productCode": "012"
                   },
                   {
                       "lineNo": 3,
                       "productCode": "013"
                   }
               ]
           }
       ]
   }
}

Code snippet that search for object having value “3”:

pm.test("array of all properties", () => {

   let jsonData = pm.response.json()
   arrayOfObject = jsonData.data.items[0].OrderBlocks;

   // You can use the arrow function expression:
   var result = arrayOfObject.find(obj => {
       // Returns the object where
       // the given property has some value
       return obj.lineNo === 3
   })
   console.log(result)
});

Arrays inside array of objects: In this example, we’ll access the values which are within an array of objects. API response body:

{
   "data": {
       "items": [
           {
               "orderID": "0000001211",
               "orderInvoiceNo": "1234567",
               "OrderBlocks": [
                   {
                       "lineNo": [
                           1,
                           3,
                           4,
                           5
                       ],
                       "productCode": "001"
                   },
                   {
                       "lineNo": [
                           0,
                           6,
                           2,
                           5
                       ],
                       "productCode": "012"
                   }
               ]
           }
       ]
   }
}

Code snippet:

pm.test("array of all properties", () => {
   let jsonData = pm.response.json()
   arrayOfObject = jsonData.data.items[0].OrderBlocks;

   //Accessing Array within array
   var arrWithinArr = arrayOfObject.map(o => o.lineNo)
   console.log(arrWithinArr)

   //optional code, if you want to concat all results
   //Concating all the array retrieved from arrayOfObject
   const concatAllArrays = [].concat(...arrWithinArr)
   console.log(concatAllArrays)
});

Conclusion

We’ve just gone through a conceptual overview of the JSON data format and how it gained its popularity when XML was high in its time. After looking at the similarities and differences between parsing and generating simple versus complex JSON datasets, hopefully you now know how to access and test JSON properties with Postman.

The post How to Test JSON Properties in Postman appeared first on Postman Blog.

When and How to Use JSON Serialization in Postman

W Ian Douglas — Wed, 09 Mar 2022 18:58:57 +0000

As a new member of Postman’s developer advocacy team, I was recently tasked with completing our 30 Days of Postman challenge. This challenge is a wonderful walk-through of the Postman API Platform’s main features, and it really helps you get familiarized with the many ways Postman is able to assist with your productivity.

I started livestreaming my journey on Twitch, and early on I was curious why I needed to serialize data in memory variables to pass between requests, especially when building dynamic request bodies. When I examined the data in the Postman Console, it appeared that they were being stored in a JSON object, yet I was unable to access the values correctly on subsequent requests.

For viewers of my Postman Blindfold Challenge, we all learned that I love to peel back the layers on what’s really going on inside a system. I have a background in development, specifically systems architecture, and so understanding how things communicate is something that greatly enhances my learning.

Let’s do a quick review of serialization and why it’s used, and then look into Postman a little deeper.

What is serialization?

“Serializing” data is used to store and convert complex data types when writing and reading from memory. It is especially useful when sharing data between multiple systems which may not all share common data types. By turning these complex data structures into simpler types, it allows independent systems to convert data in ways that are agreed upon.

A variable is given to the serializer and turned into a string

A simple example is an array of numbers. When we serialize this data into a string, in this JavaScript example with JSON.stringify(), we can see how it is converted into a string that includes square brackets around our comma-delimited list of numbers:

let arrayOfNumbers = [1,2,3,4,5]

JSON.stringify(arrayOfNumbers)

// ‘[1,2,3,4,5]’

When we “deserialize” this data back into an array, we are reversing the process to convert a string into what our programming language will interpret as an array of simple integer types. In this example, we’re still using JavaScript, and calling JSON.parse().

A string is given to the deserializer and turned back into a complex data type

let stringData = “[1,2,3,4,5]”

JSON.parse(stringData)

// [1, 2, 3, 4, 5]

Most programming languages will interpret simple data types, sometimes called “primitives,” in a straightforward way. These primitive data types include strings, numbers, boolean true/false, and then “unknown” types such as “undefined” or “null” values.

If you need to store data in a more complex way—such as an array, or a deeply nested object—then transporting that data from one place to another is more easily managed between systems if we serialize the data.

In fact, most APIs are already serializing data for us. The most common way that APIs will “package” their data right now is by using JavaScript Object Notation, or JSON, and sending it as a big string within the HTTP response body. This allows the sending system to transport data to your client software in a way that is a high-level, abstracted form of their data. Once you receive that JSON data, your application will need to convert that string back into a structure that it can interact with in a more natural way.

When you should serialize your data in Postman

So why is it that we need to JSON-serialize our data some of the time, and not all the time?

As mentioned above, primitive types such as strings and numbers do not need to be serialized; only complex data types like arrays and objects will need serialization when saving them in variables. This applies not only to global and environment variables, but collection and local variables as well.

If you need to prepare a response and send it in a “dynamic body”, you will need to serialize the data and make sure that your body data is set to “raw,” and can be set to either “Text” or “JSON” in the dropdown at the end of that row of options:

It is worth noting, also, that setting the outgoing body to “JSON” here does not have any effect on the dynamic variable you build in your pre-request script. Setting the body to JSON instead of Text only manipulates the outgoing header, not the body content itself.

Trying to debug this with the Postman Console gets a little tricky, though. Logging is run at the same time the script is executed, so building a complex structure of data is going to show up in the console correctly. But the pre-request script and the building of the dynamic body are handled in two different places.

If we do not serialize the data that we build, we’ll notice that Postman will convert this to a string containing [object Object]:

However, when we serialize this data using JSON.stringify(), we see that our data is interpreted properly:

This code and testing was done using the Postman Echo API, which echos back any data that you send to it.

Why is this a necessary step?

Building dynamic bodies for outgoing requests in Postman’s “pre-request scripts” is one of the most common places you will use this serialization technique.

Another common time to serialize and deserialize your data is when sharing responses from one request to another request. When these API responses are more complex objects, serialization will convert this data into string format, which can be parsed before using it in another request. When you serialize and “persist” data from collections and environments to Postman’s servers, your team can use that data once they have deserialized the data using JSON.parse().

Again, this serialization step is only necessary if you need to store and retrieve complex data types in collection or global variables, or save something (“persisting” the data) in your Postman environment.

But why? Postman builds and stores this variable for use between portions of the application, and may execute code and build things in an order or manner that you are not expecting. Postman does its own serialization of the data, since we cannot know what you intend to do with your data. By using JSON.stringify() and JSON.parse() yourself, you help Postman to store and interpret the data more easily, removing unexpected results in your application.

Technical review by Arlemi Turpault and Shamasis Bhattacharya.

The post When and How to Use JSON Serialization in Postman appeared first on Postman Blog.

Effective Company Research tips before your next Technical Interview

W Ian Douglas — Tue, 27 Jul 2021 19:18:10 +0000

aka "hack the networking/outreach"

I'm the author of https://techinterview.guide and I live-stream twice a week on Sundays and Thursdays about technical interview preparation.

A few weeks ago, I made a video about how to research industries and companies where you might like to work. It showcased some of my favorite tips on the topic.

There are lots of tools out there to use for tracking your application status when you apply for jobs. Some of them allow you to add custom notes, etc..

Getting Started

I use Google Sheets to track a list of things which are important to me about a company. For example:

company name
your application status
next step in the process
primary contact at the company
where are they located
do they allow remote work
what are the primary technologies they use
what's the dress code
what is the typical salary range for a role here
how big is the company
how big is the engineering team compared to the rest of the company
do they publish DEI stats
company blog URL
primary company values
top customers
top competition

Place this column on tab number 1 at the bottom of Google Sheets. Rename this tab "criteria".

You can add whichever kinds of items are important to you. For example, it might be important to you to know if the office is pet-friendly. Maybe you love taking an office pet for a quick walk, OR maybe you have allergies and cannot attend work at an office when a pet is present.

Finally, I like to add criteria at the bottom of my list that indicates the head of HR, the head of Engineering, and any contacts that my connections on LinkedIn might know. We'll talk about this later regarding cover letters.

Rank these Criteria

Your list of criteria will be different than mine. How you prioritize them will also be different than myself.

Place the criteria that is most important to you at the top of the list, and the less-important criteria at the bottom.

If you think of additional criteria as you do company research, add it to this list.

Next, organize the things on a regular basis. Your criteria may shift over time, and that's okay.

Make a new tab per Industry

Make a new tab at the bottom of the spreadsheet. Rename it to an industry that is important to you. For example, maybe "fitness" or "environment" or "travel".

In that new tab, you're going to create a reference to the "criteria" column and put those references in this tab.

In row/column A1, enter the following formula:

=criteria!A1

Copy that cell (Cmd-C or Ctrl-C), highlight all cells from A1 through A25 (or however many you want), and Paste (Cmd-V or Ctrl-V) the cell you copied.

You should now see a linked copy of the cells from your "criteria" tab on this sheet.

As you add new criteria on the "criteria" tab, you should see them show up on this tab as well. Note that you may need to copy additional rows if you add more criteria.

Next Up: the actual research

In each new tab you create, such as "fitness" or "fintech" or whatever, you can now add each company in column B, column C, column D, etc.

You might ask yourself ... "self -- how do I actually fill in this grid of information?" I'm glad you asked!

LinkedIn is a great resource, and there are many others such as GlassDoor, StackShare and others where you can find information about a company.

If, in the process of researching a company you also find competition for that company, add THEM as a column in your spreadsheet as well! If you don't interview at the first company, you might get an interview at their competition!

Fill in as much detail as you can find. It's okay if you can't find certain pieces of information. We're getting to that.

"Is This Okay With Me?"

While you fill in this spreadsheet, constantly ask yourself, "Is this okay with me?"

Is it okay that you found this information? Do you like what you found? Was it easy to find? Does it make sense to you?

If you CANNOT find information for a specific criteria, also ask yourself "is THAT okay with me that I could NOT find that information?" Was it hard to find, could you find it at all?

If something is important to you and you cannot find information, it's not a show-stopper.

But it's important to do this check whenever you do research. For example, I never want a job where I have to wear a shirt and tie every day.

If I found out that a particluar job was formal enough to require wearing a tie, I would seriously think twice before applying. That's just a strong personal preference. But so is working for a company who has "Big Tobacco" as a client. It's against my morals to support that industry, and so knowing who a company's client list is is also important to me.

Fill in the Gaps

Now that you've researched as much as possible, you'll notice that you still have gaps in information.

This is where networking and outreach becomes critical.

Through LinkedIn, you can find a company, get a list of their employees. Keep in mind these are people who volunteer this information on LinkedIn and may be out of date.

Find a peer-level employee on that list. If you're an entry-level developer, find another entry-level developer. If you're a senior developer, find another senior developer, and so on.

Connect with them. Let them know in the connection request that you have specific questions you'd like to ask them about the company. Don't just click on the "connect" button -- send a request with a message like this:

Hi Ian. I see that you work at Acme Inc. I'm doing some research on the company and would like to get to know a peer at the business. I have some specific questions about the company, and wondered if you had some time to chat. I'm happy to send the questions to you ahead of time or chat asynchronously if that's more convenient.

When you connect with an employee there, now you have SPECIFIC questions to ask: all those gaps.

I wasn't able to easily find any information about ___, and I was wondering if you could help me find that, or tell me about that.

You can also ask them to confirm information you DID find:

I noticed on LinkedIn that the company size was about __ employees. Is that still accurate? Could you guess at the percentage of employees that make up the engineering team?

Now you're asking very sepcific questions, getting specific answers.

And the whole time, keep asking yourself "is this okay with me?"

Get Contacts

While you're connecting with people at these companies, ask them for the names of the head of HR, or the head of Engineering if the company is small. Most businesses under 40 people may not even have an HR department yet, but most companies near 50 employees will have an established HR team.

If they have an HR team, you will address your cover letter and application to that person. If they do not have an HR team, you will address your cover letter to the VP of Engineering or a Director of Engineering. Typically, a CTO is a last resort as a CTO is really in charge of projects and technologies at a company, where a VP of Engineering will be in charge of hiring and people management.

Now you can apply for that job

In your cover letter you can mention that you've been speaking with someone in the company (mention them by name only if they give you their permission). Mention the research you've been doing, this will be a tremendous benefit to your job search.

Good luck in your job hunt!

Follow for more!

I stream on Twitch on Sundays and Thursdays, and you can subscribe to my YouTube channel to get notified of new videos.

How to shortcut the Leetcode grind

W Ian Douglas — Mon, 26 Jul 2021 22:02:00 +0000

I'm a professional technical interview coach, and Leetcode-style interviews aren't going away any time soon. There IS a way to shortcut the process of grinding hundreds upon hundreds of challenges. Here are my favorite tips.

I outline a lot of notes and ideas in a 90-minute YouTube video on the subject, but wanted to write them up here as well to help others.

Step One: Practice lots of Mock Interviews

There are good platforms out there such as intervieiwng.io and Pramp. For disclosure, I'm an interviewer on IIO, and my promo code for Pramp was in exchange for some blogging I did on their platform a few years ago.

Without a good coach, it's hard to get better. Grinding on leetcode problems won't tell you what you're doing well, or things to improve, unless someone can guide you along the way.

Get on a platform where you can be given some direct feedback on what you're doing well and where you need to improve.

Step Two: Come up with a good Pseudocode Process

Nver jump straight into coding when given a technical challenge. Always break the problem down into smaller pieces to solve, and ask clarifying questions along the way.

Pseudocode should be written like a food recipe:

"crack an egg in a bowl"

I'm not telling you how to crack the egg, where to tap the egg, how to hold the egg, how hard to tap the egg. I'm going to presume that (a) you know how to crack an egg, and (b) through your own experience you know the best way to crack the egg for this kind of recipe.

By keeping the pseudocode really high-level in this fashion, you're not locking yourself into an implementation. If you write down "for loop over the array" then you've locked yourself into an implementation to strictly use a "for" loop.

Your pseudocode should be flexible enough to give you the ability to change your mind on "how". As an interviewer, I can ask questions about how you MIGHT implement something, but your steps should remain high level.

Start vague, add more detail, but if you've added so much detail that you've locked in your implementation, you might want to back up a bit.

Step Three: Learn from Others

Okay, leetcode.com. I appreciate their platform more than others because of the discussion forum for each problem, and because they give you actionable feedback when you run your code to see what didn't work based on inputs and expected output and actual output.

3a -- find a category of problem to study

Next, we're going to use Sean Prashad's awesome Leetcode Patterns site. From here we're going to pick any category of problem, say "DFS" (Depth First Search), and then pick any of those problems at random.

From here we'll visit the discussion forum for that problem -- the link will usually look like "Discuss (999+)".

3b -- find 4 to 5 answers in programming languages you DO NOT KNOW

By using languages you don't know it will force you into higher-level thinking like "okay, they're passing a parameter called 'menu', and I see they're doing a 'for' loop with that parameter, so I'm going to write down 'loop over menu' as my instruction."

If you look at an answer in a language you DO know, you can certainly write down your pseducodeo quicker because you'll have a better idea what's happening, but you're (a) more likely to lock yourself into an implementation, and (b) more likely to memorize the SYNTAX, where we're here to learn the STRATEGY.

3c -- compare the pseudocode

Once you have pseudocode written out for 4 or 5 answers, compare them side by side. Highlight lines that are similar, and try to come up with a 4 to 6 line algorithm from there.

For example, if you were solving a maze, the algorithm might look like:

work until you get to an intersection
from a list of possible directions
  go in that direction
  repeat/recurse all of the above
  rewind to previous intersection if that didn't work
if we're at the exit, we're done

3d -- write it on a Post-It note, stick it on your monitor

Study these often.

The next time you try a problem of this type, see whether that algorithm will work. If not, repeat step 3 for that new kind of problem.

Step Four: Build a workout Schedule

Now that you have a condensed list of study notes, you can form a plan for studying different kinds of problems every day.

Research shows that repeating something 2 days later and 3 days later is optimal for long-term memory. PROVIDED that you start over from nothing. Don't review old notes, don't review pseudocode, start all over again.

Come up with a calendar where you try a new kind of problem every day, and then sprinkle in when you can repeat a previous problem.

I give some examples of this in my YouTube video around the 48-minute mark, but could look something like this:

Sun: DFS-1
Mon: Heap-1
Tue: BFS-1, repeat DFS-1
Wed: DP-1, repeat Heap-1
Thu: DFS-2, repeat BFS-1
Fri: Array-1, repeat DP-1, repeat DFS-1
Sat: break day

Sun: F&S Ptr, repeat DFS-2, repeat DP-1
Mon: etc etc

I have two DFS problems on this schedule because maybe the company where I'm interviewing is more likely to ask DFS-style questions.

I describe the "break day" in the video. It's important to let our brain rest, and to take time to just analyze problems for the "type" of problem it may be. This will help you more quickly identify a leetcode-type challenge in a real interview.

Conclusion

To sum it all up: practicing mock interviews with someone else is the best way to get feedback. Without feedback you're not going to get better as quickly.

Next, learn the algorithms by studying how other people have solved particular kinds of challenges. Condense them into very concise steps, and study those.

Finally, come up with a regular schedule for studying different kinds of problems every day, and repeating them. Add the same kind of problem in the mix more often if you think the company is more likely to ask that kind of problem.

Disclosures

I stream every Sunday and Thursday on Twitch around topics of technical interview prep. Come by and check out the stream, chat and say hello and ask questions. I also do live resume reviews on Sundays. The link above will give you all of the info you need.