Forem: Prakash

The itgps-agent: Bringing Studio-Managed Configs to Your Local Workflow

Prakash — Mon, 11 May 2026 04:14:20 +0000

The itgps-agent: Bringing Studio-Managed Configs to Your Local Workflow

In Part 1 and Part 2, we explored ITG Playwright Studio's web interface for managing tests. But what if you're a developer who prefers the command line? What if you want to run tests locally during development but still leverage Studio's centralized configuration management?

That's exactly what the itgps-agent solves.

The Problem: Configuration Drift

Here's a common scenario: Your team uses ITG Playwright Studio to manage test configurations, environments, and datasets. Everything works great in CI and for scheduled runs. But when you're developing locally, you're back to managing your own .env files, trying to keep them in sync with what's in the Studio.

This leads to:

Configuration drift - your local setup doesn't match staging or production
Debugging confusion - "It works on my machine" because your env vars are different
Onboarding friction - new team members need to manually set up all the environment variables
Data duplication - the same credentials and URLs exist in multiple places

The Solution: itgps-agent

The itgps-agent is a command-line tool that bridges the gap between local development and Studio-managed configurations. It lets you:

Run tests locally with Studio-managed environment variables and datasets
Trigger remote test runs on the Studio server from your terminal
Sync Git repositories via CLI
Work offline with cached Studio data

Think of it as "Studio configuration, command-line execution."

Installation

The agent is distributed as an npm package. Install it globally for the best experience:

npm install -g @itechgenie/itgps-agent

Or install it locally in your project:

npm install --save-dev @itechgenie/itgps-agent

Requirements:

Node.js 18 or later
@playwright/test installed in your project
Access to an ITG Playwright Studio instance

Initial Setup: The Config Command

The first thing you'll do is run the interactive configuration wizard:

itgps-agent config

This wizard walks you through:

Step 1: Studio URL

? Studio URL: https://studio.example.com

Step 2: Personal Access Token

The wizard provides instructions on how to generate a PAT:

Open Studio in your browser
Navigate to Settings
Scroll to "Personal Access Tokens"
Generate a new token
Copy and paste it

? Personal Access Token (PAT): **********************
✓ Verified! Signed in as John Doe (john@example.com)

Step 3: Credential Storage

Choose where to store your credentials:

? Where to save credentials?
  > Global config (~/.itgps/config.json)
    Local .env file

Global config: Good if you only work with one Studio instance
Local .env: Better for multiple projects or multiple Studio instances

Step 4: Project Selection

The agent fetches your projects from Studio:

? Select project:
  > E-Commerce Tests
    Mobile App Tests
    API Integration Tests

Step 5: Environment & Dataset

Choose which environment and dataset to use by default:

? Select environment:
  > Staging
    Production
    Local Development

? Select dataset:
  > Test Users
    Edge Cases
    Performance Data

Step 6: Bootstrap & Cache

The agent downloads project configuration, environment variables, and dataset variables from Studio and caches them locally:

✓ Bootstrap complete
✓ Playwright config copied to .itgps/playwright.config.cjs
✓ Added .itgps/ to .gitignore

Configuration complete!

  Studio URL:  https://studio.example.com
  User:        John Doe (john@example.com)
  Project:     E-Commerce Tests
  Environment: Staging
  Dataset:     Test Users

What Just Happened?

The config command did several things:

Authenticated with Studio using your PAT
Stored credentials in either ~/.itgps/config.json or .env
Downloaded configuration from Studio (project settings, env vars, dataset vars)
Cached data locally in ~/.itgps/cache/ for offline use
Copied Playwright config to .itgps/playwright.config.cjs in your project
Updated .gitignore to exclude .itgps/ folder

Your project structure now looks like:

my-test-project/
├── .itgps/
│   ├── cache/              # Cached Studio data
│   └── playwright.config.cjs  # Playwright configuration
├── .env                    # Studio credentials (if you chose local storage)
├── .gitignore              # Updated to ignore .itgps/
├── tests/
│   ├── login.spec.ts
│   └── checkout.spec.ts
└── package.json

Running Tests Locally

Now you can run tests with Studio-managed configuration:

itgps-agent test

This command:

Reads your Studio credentials
Fetches the latest configuration (or uses cache if offline)
Merges environment variables and dataset variables
Runs playwright test with the merged configuration

Example output:

[Config] Running on browser: chromium
Running 5 tests using 1 worker

✓ [chromium] › login.spec.ts:3:5 › User can log in (2.1s)
✓ [chromium] › login.spec.ts:15:5 › Invalid credentials show error (1.8s)
✓ [chromium] › checkout.spec.ts:3:5 › Complete checkout flow (4.3s)
✓ [chromium] › checkout.spec.ts:22:5 › Apply discount code (2.9s)
✓ [chromium] › checkout.spec.ts:35:5 › Guest checkout (3.2s)

5 passed (14.3s)

Using Studio Variables in Tests

In your test files, you access Studio-managed variables via process.env:

// tests/login.spec.js
const { test, expect } = require('@playwright/test');

test('user can log in', async ({ page }) => {
  // These values come from Studio
  const siteUrl = process.env.siteurl;
  const username = process.env.app_username;
  const password = process.env.app_password;

  await page.goto(siteUrl);
  await page.fill('#username', username);
  await page.fill('#password', password);
  await page.click('#login');

  await expect(page).toHaveURL(/dashboard/);
});

The agent automatically injects these variables based on the environment and dataset you selected during itgps-agent config.

Variable Precedence

Variables are merged with the following precedence (highest to lowest):

Local .env overrides - Variables you define locally
Dataset variables - From the selected Studio dataset
Environment variables - From the selected Studio environment
Project defaults - Default values from Studio project settings

This means you can override Studio values locally for debugging:

# .env
# Override the site URL for local testing
siteurl=http://localhost:3000

# Use Studio values for everything else

All Playwright Commands Work

The agent acts as a proxy for Playwright, so all native commands work:

# Run tests in headed mode
itgps-agent test --headed

# Run specific tests
itgps-agent test --grep "login"

# Run on specific browser
itgps-agent test --project=firefox

# Generate test code
itgps-agent codegen

# View reports
itgps-agent show-report

The agent bootstraps Studio data before passing control to Playwright.

Remote Execution: Trigger Studio Runs

Want to trigger a test run on the Studio server from your terminal?

itgps-agent remote-run

This command:

Connects to Studio
Lets you select environment and dataset
Triggers a test run on the Studio server
Streams the output to your terminal in real-time

Example:

$ itgps-agent remote-run

? Select environment: Staging
? Select dataset: Test Users
? Trigger remote run? Yes

✓ Run triggered. Run ID: e1f86b12-f6b6-42f0-8a17-af6feb89001c

[MR] clean output dir ...
Running 5 tests using 5 workers

✓ [chromium] › login.spec.ts:3:5 › User can log in (2.3s)
✓ [chromium] › checkout.spec.ts:3:5 › Complete checkout flow (4.1s)
...

✓ Run completed successfully in 12.4s

This is useful when:

You want to run tests on Studio's infrastructure (more powerful, different OS)
You need to test against an environment only accessible from Studio
You want the results recorded in Studio's execution history

Git Sync from CLI

Instruct Studio to pull the latest changes from Git:

itgps-agent studio-git-sync

This triggers a Git sync on the Studio server, useful in CI/CD pipelines or when you've pushed changes and want Studio to pick them up immediately.

Offline Support

The agent caches Studio data locally, so you can work offline:

$ itgps-agent test
[offline] Using cached Studio data from 2024-05-10T14:23:45Z

Running 5 tests using 1 worker
...

When you're back online, run itgps-agent config to refresh the cache.

Customizing the Playwright Config

The agent copies a Playwright config to .itgps/playwright.config.cjs. This file is fully editable - customize it as needed:

// .itgps/playwright.config.cjs
const { defineConfig, devices } = require('@playwright/test');

module.exports = defineConfig({
  testDir: './',
  timeout: 30000,

  // Add custom reporters
  reporter: [
    ['list'],
    ['html'],
    ['junit', { outputFile: 'results.xml' }],  // Your addition
  ],

  // Customize projects
  projects: [
    {
      name: 'chromium',
      use: { ...devices['Desktop Chrome'] },
    },
    // Add more browsers as needed
  ],
});

The agent uses this config when running tests. If you run itgps-agent config again, it will ask if you want to overwrite with the latest version from the agent package.

Language Support: JavaScript and TypeScript

The agent works with both JavaScript and TypeScript projects. Your test files can be .spec.js or .spec.ts:

TypeScript example:

// tests/api.spec.ts
import { test, expect } from '@playwright/test';

test('API health check', async ({ request }) => {
  const apiUrl = process.env.api_base_url!;
  const apiKey = process.env.api_key!;

  const response = await request.get(`${apiUrl}/health`, {
    headers: { 'Authorization': `Bearer ${apiKey}` }
  });

  expect(response.ok()).toBeTruthy();
});

JavaScript example:

// tests/api.spec.js
const { test, expect } = require('@playwright/test');

test('API health check', async ({ request }) => {
  const apiUrl = process.env.api_base_url;
  const apiKey = process.env.api_key;

  const response = await request.get(`${apiUrl}/health`, {
    headers: { 'Authorization': `Bearer ${apiKey}` }
  });

  expect(response.ok()).toBeTruthy();
});

Both work identically with the agent.

Real-World Workflow

Here's how a typical development workflow looks with the agent:

Morning: Start Development

# Pull latest code
git pull

# Refresh Studio config (in case env vars changed)
itgps-agent config

# Run tests to ensure everything works
itgps-agent test

During Development

# Run specific test you're working on
itgps-agent test tests/new-feature.spec.ts --headed

# Override a variable locally for debugging
echo "debug_mode=true" >> .env
itgps-agent test tests/new-feature.spec.ts

Before Committing

# Run full test suite
itgps-agent test

# If all pass, commit and push
git add .
git commit -m "Add new feature tests"
git push

After Pushing

# Trigger Studio to sync with Git
itgps-agent studio-git-sync

# Trigger a remote run to verify in Studio environment
itgps-agent remote-run

Troubleshooting

Authentication Errors:

# Token expired or invalid
# Regenerate token in Studio and reconfigure
itgps-agent config

Network Errors:

# Studio unreachable
# Agent automatically uses cached data
[offline] Using cached Studio data from 2024-05-10T14:23:45Z

Missing Browsers:

# Playwright browsers not installed
npx playwright install

Config Issues:

# Regenerate config file
itgps-agent config
# Choose "Yes" when asked to overwrite

Configuration Files Reference

Global Config (~/.itgps/config.json):

{
  "studioUrl": "https://studio.example.com",
  "token": "your-personal-access-token"
}

Local Environment (.env):

ITGPS_STUDIO_URL=https://studio.example.com
ITGPS_TOKEN=your-personal-access-token
ITGPS_PROJECT_ID=project-uuid
ITGPS_ENV_ID=environment-uuid
ITGPS_DATASET_ID=dataset-uuid

# Local overrides
siteurl=http://localhost:3000
debug_mode=true

Cache Location (~/.itgps/cache/):

~/.itgps/
├── config.json          # Global credentials
└── cache/
    ├── project.json     # Project list
    ├── environments.json # Environment configs
    └── datasets.json    # Dataset variables

Why Use the Agent?

The agent is particularly valuable when:

You prefer command-line tools but want centralized config management
You're developing locally and need the same env vars as CI/Studio
You work on multiple projects with different Studio instances
You need offline capability but want to sync when online
You want to trigger remote runs without opening the browser
Your team uses Studio but you want a local development workflow

The Best of Both Worlds

The beauty of the itgps-agent is that it gives you flexibility:

Use the Studio web interface for scheduling, viewing reports, and managing configurations
Use the agent CLI for local development and command-line workflows
Use both - they work together seamlessly

Your tests remain standard Playwright tests. The agent just makes it easier to run them with the right configuration, whether you're working locally or triggering remote runs.

Try It Yourself

Install the agent and give it a try:

# Install globally
npm install -g @itechgenie/itgps-agent

# Configure connection to Studio
itgps-agent config

# Run tests
itgps-agent test

For more details, check out:

GitHub: https://github.com/ITechGenie/itg-playwright-studio
Agent README: https://github.com/ITechGenie/itg-playwright-studio/tree/main/itgps-agent
Studio Documentation: https://github.com/ITechGenie/itg-playwright-studio#readme

Series Recap

In this three-part series, we've covered:

Part 1: Why managing Playwright tests at scale is challenging and how ITG Playwright Studio addresses these challenges

Part 2: A detailed visual tour of the Studio interface, showing how to manage tests, view reports, schedule runs, and manage data

Part 3 (this article): How to use the itgps-agent CLI tool to run tests locally while leveraging Studio-managed configurations

Together, ITG Playwright Studio and the itgps-agent provide a complete solution for managing Playwright tests at scale - whether you prefer a web interface or command-line tools.

Have you tried the itgps-agent? What features would you like to see added? Let me know in the comments!

A Visual Tour of ITG Playwright Studio: Managing Tests Through a Web Interface

Prakash — Mon, 11 May 2026 04:13:42 +0000

A Visual Tour of ITG Playwright Studio

In Part 1, we discussed why managing Playwright tests at scale is challenging and introduced ITG Playwright Studio as a solution. Now let's take a detailed tour of the interface and see how it actually works.

Getting Started: Authentication

The first thing you'll see is the login page. ITG Playwright Studio supports multiple authentication methods:

You can authenticate via:

OAuth providers (GitLab, GitHub) - useful for Git integration
Local admin account - for self-hosted deployments
Personal Access Tokens - for CLI and API access

The OAuth integration isn't just for login - it also enables direct Git repository access, letting you import projects and sync files without cloning repos locally.

Project Workspace: Your Test Suite Dashboard

Once logged in, you land on the Projects page - your central hub for all Playwright test projects:

Each project card shows:

Project name and description
Number of test files
Recent execution status
Quick actions (run tests, view files, settings)

You can create projects in two ways:

Import from Git - Connect to a GitLab/GitHub repository
Local sync - Point to an existing Playwright project on your filesystem

Test Explorer: Browse and Manage Test Files

Click into a project and you'll see the Test Explorer - a file browser specifically designed for test suites:

Key features:

Tree view of your test directory structure
File preview with syntax highlighting
Quick actions - run individual files or entire folders
Search and filter to find specific tests
Monaco editor for editing tests directly in the browser

The Monaco editor (the same one VS Code uses) gives you:

Full TypeScript/JavaScript IntelliSense
Syntax highlighting
Error detection
Auto-completion

No need to clone the repo, open an IDE, make a change, commit, and push just to fix a typo in a test.

Running Tests: The Prepare Drawer

When you're ready to run tests, click "Prepare Tests" to open the runner drawer:

This is where the Studio really shines. You can:

Select Test Files:

Pick individual files or entire folders
Multi-select with checkboxes
See how many tests will run

Configure Execution:

Choose browsers (Chromium, Firefox, WebKit, Chrome, Edge)
Set worker count for parallelization
Configure timeouts
Enable/disable headless mode
Set viewport dimensions

Choose Environment & Data:

Select which environment to run against (staging, production, etc.)
Pick a dataset for test data
Override specific variables if needed

Advanced Options:

Enable video recording
Configure screenshot capture
Set up HAR file recording
Add custom Playwright flags

All of this without touching a config file or writing npm scripts.

Live Execution: Real-Time Feedback

Hit "Run Tests" and you get live execution logs streamed directly to your browser:

You see:

Real-time stdout/stderr from Playwright
Progress indicators for each test file
Pass/fail status as tests complete
Duration tracking
Ability to stop the run if needed

No more waiting for CI to finish and then downloading logs. You see everything as it happens.

Execution History: Track Every Run

After tests complete, they're automatically added to the execution history:

For each run, you can see:

Status (passed, failed, stopped)
Duration and timestamp
Who triggered it (user or schedule)
Environment and dataset used
Command executed
Direct links to HTML and Monocart reports

The reports are served directly from the Studio - no downloading, no extracting archives. Just click and view.

Filter the history by:

Date range (with a 2-week maximum for performance)
Status (passed, failed, running)
Environment
Triggered by

This makes it easy to spot patterns: "Why do tests keep failing on Fridays?" or "Did the staging environment have issues last week?"

Scheduling: Automate Test Runs

Need tests to run automatically? Open the scheduler:

Set up recurring runs with:

Cron-like scheduling - run tests hourly, daily, weekly, or custom patterns
Test selection - which files to run
Environment configuration - which environment and dataset to use
Browser selection - which browsers to test

Examples:

Run smoke tests every hour during business hours
Full regression suite nightly at 2 AM
Checkout flow tests every 30 minutes
Cross-browser tests weekly

No need to set up Jenkins jobs, GitHub Actions workflows, or cron jobs. It's all managed through the UI.

Data Management: Environments and Datasets

One of the most powerful features is the data management system. Instead of hardcoding values or managing multiple .env files, you define them in the Studio.

Data Templates:

Define the schema for your test data:

Field names (username, password, api_key, etc.)
Field types (text, password, URL, etc.)
Descriptions and defaults

Environments:

Create environment-specific configurations:

Staging: staging URLs, test credentials
Production: production URLs, real credentials
Local: localhost URLs, mock data

Datasets:

Create reusable test data sets:

Happy Path Users: valid credentials, complete profiles
Edge Cases: special characters, boundary values
Error Scenarios: invalid data, expired tokens

In your tests, you just reference the variables:

const username = process.env.app_username;
const password = process.env.app_password;
const siteUrl = process.env.siteurl;

The Studio injects the right values based on which environment and dataset you selected for the run.

Variable Precedence:

Local .env overrides (highest priority)
Dataset variables
Environment variables
Project defaults (lowest priority)

This means developers can override values locally for debugging while CI uses Studio-managed values.

Project Settings: Fine-Tune Configuration

Each project has a settings page where you can configure Playwright defaults:

Set project-wide defaults for:

Default browser
Worker count
Timeout values
Base URL
Video and screenshot settings
Viewport dimensions

These become the defaults for all test runs, but can be overridden per-run in the Prepare drawer.

Git Integration: Sync Without Cloning

If you authenticated via OAuth, you get seamless Git integration:

Import Projects:

Browse your GitLab/GitHub repositories
Import with one click
Studio clones and syncs automatically

Sync Files:

Pull latest changes from Git
See what changed
No local git commands needed

Push Changes:

Edit files in Monaco editor
Write a commit message
Push directly to the repository

This is particularly useful for:

Quick fixes that don't warrant a full dev environment setup
Non-technical team members who need to update test data
Reviewing test code without cloning repos

Real-World Workflow Example

Let's walk through a complete workflow:

1. Morning: Schedule Smoke Tests

Open scheduler
Create "Hourly Smoke Tests" schedule
Select critical path tests (login, checkout, search)
Choose staging environment
Set to run every hour from 9 AM to 6 PM
Save

2. Mid-Day: Debug a Failing Test

Check execution history
See that checkout test failed at 11 AM
Click to view Monocart report
See screenshot of the failure
Open test file in Monaco editor
Fix the selector
Push change to Git
Manually trigger a test run to verify fix

3. Afternoon: Run Full Regression

Open Test Explorer
Select all test files
Choose "Production" environment
Select "Full Dataset"
Enable all browsers (Chromium, Firefox, WebKit)
Set workers to 5 for parallelization
Run tests
Watch live logs
Tests complete in 8 minutes instead of 40 (thanks to parallelization)

4. End of Day: Review Results

Check execution history
Filter by today's date
See 8 scheduled runs (hourly smoke tests)
See 1 manual run (your regression)
All passed
Share report link with product manager

All of this without writing a single line of CI/CD configuration or managing any infrastructure.

Technical Stack

For those curious about what's under the hood:

Frontend:

React 18 with Vite
Tailwind CSS for styling
Radix UI (Shadcn) for components
Monaco Editor for code editing
Lucide Icons

Backend:

Node.js + Express
TypeScript throughout
SQLite with Drizzle ORM
WebSockets for real-time logs

Execution:

Spawns Playwright processes directly
Streams stdout/stderr via WebSockets
Generates HTML and Monocart reports
Stores artifacts on filesystem

Deployment:

Docker image available
Can run on any Node.js host
Minimal resource requirements
SQLite means no separate database server

What's Next?

In Part 3, we'll dive into the itgps-agent - a CLI tool that brings Studio-managed configurations to your local development workflow. It's perfect for developers who prefer the command line but want centralized config management.

You'll learn how to:

Install and configure the agent
Run tests locally with Studio data
Trigger remote runs from your terminal
Sync Git repositories via CLI

Try It Yourself

Ready to try ITG Playwright Studio? It's open source and easy to get started:

Docker (fastest):

docker pull ghcr.io/itechgenie/itg-playwright-studio:latest
docker run -d -p 3000:3000 \
  -v $(pwd)/data:/app/data \
  --name itg-playwright-studio \
  ghcr.io/itechgenie/itg-playwright-studio:latest

From Source:

git clone https://github.com/ITechGenie/itg-playwright-studio.git
cd itg-playwright-studio
npm install
npm run dev

Then open http://localhost:3000 and start exploring.

GitHub: https://github.com/ITechGenie/itg-playwright-studio

Coming up next: Part 3: The itgps-agent CLI Tool - Run tests locally with Studio-managed configurations.

What features would you like to see in a Playwright management tool? Let me know in the comments!

Playwright is Powerful, But Managing It at Scale? That's Another Story

Prakash — Mon, 11 May 2026 04:12:45 +0000

Playwright is Powerful, But Managing It at Scale? That's Another Story

If you've worked with Playwright, you know it's an incredible tool for end-to-end testing. The API is clean, the cross-browser support is solid, and the developer experience is generally great. But here's the thing: as your test suite grows and your team expands, managing Playwright tests becomes... complicated.

The Playwright Paradox

Playwright gives you everything you need to write robust tests. But when it comes to managing those tests across teams, environments, and schedules, you're mostly on your own. Let me paint a familiar picture:

Scenario 1: The Test Execution Shuffle

Your QA team wants to run a specific subset of tests against staging. Your CI/CD pipeline needs to run the full suite on every PR. Your product manager wants to trigger smoke tests on demand. Each of these requires:

Different environment variables
Different test data
Different browser configurations
Different reporting requirements

You end up with a maze of npm scripts, environment files, and CI/CD configurations that only three people on your team truly understand.

Scenario 2: The Report Hunt

A test failed in CI last night. You need to see what happened. Where's the report? Is it in the CI artifacts? Did someone download it locally? Is it still available, or did it get cleaned up? You spend 10 minutes just finding the report before you can even start debugging.

Scenario 3: The Schedule Dance

"Can we run the checkout flow tests every hour during business hours?" Sure, let me just... set up a cron job? Write a GitHub Actions workflow? Deploy a Lambda function? For something that should be simple, it requires surprisingly complex infrastructure.

What's Missing?

Playwright itself is fantastic. What's missing is the control plane - a centralized way to:

Manage test execution across different environments without juggling config files
Schedule recurring runs without writing cron jobs or CI/CD workflows
View and share reports without hunting through artifacts or local directories
Track execution history to spot patterns and regressions
Manage test data (environments, datasets) separately from test code
Collaborate with team members who may not be comfortable with command-line tools

These aren't Playwright problems - they're operational problems that emerge when you're running tests at scale.

Enter ITG Playwright Studio

This is why we built ITG Playwright Studio - a web-based control plane specifically designed to solve these operational challenges while keeping Playwright at the core.

Think of it as the missing management layer for your Playwright tests. You still write tests the same way, you still use Playwright's excellent API, but now you have a centralized dashboard to:

Execution Management

Select multiple test files and run them in parallel with a few clicks
Configure browser settings, timeouts, and workers through a UI
Trigger runs on-demand or schedule them for later
Stream live execution logs in real-time

Reporting & History

View HTML and Monocart reports directly in the browser
Track every test run with full execution history
Filter runs by status, date range, or environment
Share report links with team members

Data Management

Define environment-specific variables (staging, production, etc.)
Create reusable datasets for different test scenarios
Override values without touching test code
Manage secrets securely

Scheduling

Set up recurring test runs with cron-like precision
Run smoke tests every hour, full regression nightly
No infrastructure setup required

File Management

Browse and edit test files directly in the browser
Monaco editor with full TypeScript/JavaScript support
Sync with Git repositories (GitLab, GitHub)
No need to clone repos locally just to make quick edits

The Architecture

ITG Playwright Studio is built as a distributed system:

Frontend: React + Vite dashboard with Monaco editor
Backend: Node.js + Express API with SQLite database
Execution Engine: Spawns Playwright processes with configured environments
CLI Agent: Optional tool for running tests locally with Studio-managed configs

The key insight: we don't replace Playwright, we orchestrate it. Your tests remain standard Playwright tests. The Studio just makes them easier to manage, execute, and monitor.

Who Is This For?

ITG Playwright Studio is particularly useful if you:

Have a growing test suite that multiple team members need to run
Need to run tests across different environments with different configurations
Want non-technical stakeholders to trigger test runs without command-line access
Are tired of hunting for test reports in CI artifacts
Need scheduled test runs but don't want to manage cron jobs or CI/CD complexity
Want a single source of truth for test execution history

What's Next?

In the next article, I'll give you a detailed tour of ITG Playwright Studio's interface, showing you exactly how it solves each of these problems. We'll walk through:

Setting up your first project
Running tests with different configurations
Viewing reports and execution history
Managing environments and datasets
Setting up scheduled runs

And in the third article, we'll dive into the itgps-agent - a CLI tool that lets you run tests locally while still leveraging Studio-managed configurations. It's perfect for developers who prefer the command line but want centralized config management.

Try It Yourself

ITG Playwright Studio is open source and available on GitHub. You can spin it up with Docker in under a minute:

docker pull ghcr.io/itechgenie/itg-playwright-studio:latest
docker run -d -p 3000:3000 --name itg-playwright-studio \
  ghcr.io/itechgenie/itg-playwright-studio:latest

Then open http://localhost:3000 and start exploring.

GitHub: https://github.com/ITechGenie/itg-playwright-studio

Coming up next: Part 2: A Visual Tour of ITG Playwright Studio - Screenshots, features, and a complete walkthrough of the interface.

Have you faced similar challenges managing Playwright tests at scale? What solutions have you tried? Let me know in the comments!

Open Source: A Friendly Guide for New Developers

Prakash — Sat, 27 Dec 2025 13:50:53 +0000

Open Source: A Friendly Guide for New Developers

This article is written for first-time developers — a friendly, practical introduction to help you understand open source and take your first steps.

Open source powers much of the software you use every day — from operating systems and developer tools to the websites and services you depend on. If you’re a new or first-time developer, open source is an incredible way to learn, contribute, and make real-world impact. This short guide explains what open source is, how it differs from other models, why it matters, and how you can get started.

What is Open Source?

Open source means the source code of a project is publicly available for anyone to view, modify, and distribute. This encourages transparency, peer review, and collaboration. While the code is open, projects still use licenses that define what others can do with the code.

Open Source vs Free Software vs Commercial

Before we compare them, here’s why the distinction matters: different projects have different goals and rules. Some focus on making code easy to reuse and build on, others focus on protecting users' freedoms, and some are designed mainly to make money. That changes what you are allowed to do with the code and how the project is run.

In simple words:

Open source: you can see and usually modify the code — specific rights depend on the license.
Free software: strong emphasis on the user's freedom to run, study, change, and share the software.
Commercial software: typically built to generate revenue; it may be closed-source or restricted.

Quick comparison	Open Source	Free Software	Commercial
Main idea	Code is public and reusable	User freedoms are protected	Built to make money (may be closed)
What you can do	Read and modify (depending on license)	Run, study, modify, and redistribute	Often limited unless vendor permits it
Who builds it	Community contributors + companies	Communities and activists for software freedom	Companies and paid teams
Friendly for beginners?	Yes — great for learning by reading real projects	Yes — teaches important values, but legal terms matter	Sometimes (paid support helps), but source may be hidden

These categories overlap — for example, an open source project can also be free software, and companies often offer commercial services around open source projects.

A Brief History

The culture of sharing software predates modern open source. Key milestones include:

1983: The GNU Project launched to create a free Unix-like OS.
1991: Linus Torvalds released the Linux kernel, sparking widespread collaboration.
2000s: Distributed version control and platforms like GitHub made contributing easier and more social.

Together these developments shaped the modern open source ecosystem: collaborative, distributed, and accessible.

Life-Changing Open Source Projects

Open source has produced tools and platforms that changed how we build software — and many are things you already use every day. You don't have to be a developer to benefit: many smartphones include Android components that are open source, millions of websites run on WordPress, and popular apps like VLC and Firefox are open-source projects. If you're a developer, these projects' code is public and you can read or contribute; if not, you can still help by reporting bugs, translating, or donating.

Linux — the backbone of servers, mobile devices (Android), and cloud infrastructure.
Git — the version control system used by millions of developers.
Python and Node.js — languages and runtimes powering huge swathes of applications.
Java & Android (AOSP) — Java is a ubiquitous language used for backend systems, Android apps, and games (Minecraft was originally written in Java); Android's open-source components power many phones and devices.
WordPress & Forem (dev.to) — WordPress powers a large portion of the web for blogs and sites; Forem is an open platform for developer communities and publishing — both demonstrate community-driven publishing.
VS Code (OSS core) — the editor's open-source core is used widely by developers; community extensions thrive on it.
Firefox — a modern web browser focused on privacy and extensibility; its codebase is open and accepts contributions.
VLC — a versatile media player that supports countless formats and is community-driven.
7-Zip — an open-source file archiver used for compressing and extracting files.
qBittorrent — a community-maintained BitTorrent client commonly used for peer-to-peer file sharing.
LibreOffice and GIMP — open alternatives for productivity and image editing.
OpenGL and Vulkan — graphics APIs used in games and graphics applications; they power much of the visual software you interact with.
Kubernetes and Docker — changed how we build, ship, and run applications.
Blender — open-source 3D modeling and animation software used in films and design.
OpenStreetMap — volunteer-built mapping data that powers many navigation and location services.

These projects are not just technologies; they’re products you've likely used — so the question is: if you can run them, why not read or change their code? That direct connection makes open source especially inviting for first-time contributors.

Licenses and Their Nuances

Licenses determine what others can do with your code. Choosing a license depends on your goals (encourage wide adoption, preserve freedoms, or limit certain commercial usages). Common license families:

License family	Examples	Key points	When to choose
Permissive	MIT, BSD-2/3, Apache 2.0	Minimal restrictions; Apache 2.0 adds a patent grant	When you want broad adoption and easy reuse, including commercial use
Copyleft	GPLv3, AGPLv3	Requires derivative works to use the same license (AGPL extends to network use)	When you want derivatives to remain open-source
Source-available / Custom	Business Source (e.g., MariaDB BSL), commercial dual-licensing	Limits certain uses (e.g., cloud providers); may not be OSI-approved	When you need specific commercial protections or staged openness

For a broader list of licenses see Open Source Initiative or the SPDX license list.

Each choice has trade-offs between adoption, control, and community expectations.

How Commercial Support Adds Value

Commercial offerings around open source help organizations use projects reliably at scale. Typical commercial services include:

Long-term support (LTS) and enterprise builds: stable releases with extended maintenance and security patches.
Service-level agreements (SLAs): guaranteed response times and dedicated support for critical incidents.
Managed/hosted offerings: cloud-hosted versions (e.g., MongoDB Atlas, Elastic Cloud, Redis Enterprise) that remove operational overhead.
Integration, consulting, and training: help with architectural design, migration, and bespoke integrations.
Security and compliance: coordinated security advisories, backported fixes, and assistance meeting regulatory needs.

Well-known examples include Red Hat (enterprise Linux support), MongoDB (enterprise features and Atlas), Elastic (Elastic Cloud and enterprise plugins), and Redis (Redis Enterprise and hosted services). Paid support funds maintainers and organizations, improves documentation and testing, and underwrites the work that keeps widely used projects healthy.

That said, commercial models sometimes introduce trade-offs: features may be gated behind paid tiers, or licensing changes can create tension with community expectations — so transparent governance and clear communication are important.

When Commercialization Causes Friction

Sometimes monetization strategies trigger community pushback. Here are a few concrete cases you may have heard about:

Vendor licensing shifts (Java/Oracle): Oracle changed the terms and long-term support model for its Oracle JDK binaries, which led many organizations to switch to community OpenJDK builds or paid commercial distributions. The change shows how vendor licensing can push users toward community-maintained alternatives (see OpenJDK: https://openjdk.java.net/).
Cloud-provider tensions and re-licensing (Redis, Elastic, MongoDB): Some projects moved parts of their code to more restrictive or "source-available" licenses (or SSPL-style terms) to stop cloud providers from offering managed services without sharing revenue. Those moves caused forks, ecosystem disruption, and heated debate — for example, Redis' 2024 relicensing of certain modules and the later discussions about returning to a more permissive stance (see Redis announcement and coverage: https://redis.com/blog/introducing-redis-enterprise-modules/ and https://en.wikipedia.org/wiki/Server_Side_Public_License).
Platform policy changes (Chrome Manifest V2 → V3): Platform or policy changes can also affect ecosystems. Chrome's move from Manifest V2 to Manifest V3 changed extension APIs that many ad blockers relied on, prompting privacy and developer concerns and wider discussion about platform power (see the Chromium docs and coverage: https://developer.chrome.com/docs/extensions/mv3/ and https://www.license-token.com/wiki/ublock-origin-dead-in-chrome).

These examples show why transparent governance, clear communication, and diverse funding models matter — they reduce surprises and keep communities resilient when business needs change.

How Developers Can Help Sustain Open Source

You don’t need to be a core maintainer to have high impact. Ways to help:

Contribute small fixes: docs, tests, or tiny bug fixes labeled “good first issue”.
Report clear bugs and include steps to reproduce.
Sponsor or donate to maintainers and organizations that support projects you rely on.
Help with triage and reviews to reduce maintainer burden.
Share knowledge: write blog posts, give talks, or mentor newcomers.

Together these actions make projects healthier and more sustainable.

Getting Started — A Simple Roadmap

A. Create your own project (learn by doing):

Start small: a focused utility, library, or tool solves a real problem.
Choose a license (see table above) and add a clear README.md and LICENSE file.
Add CONTRIBUTING.md, issue and PR templates, and a short roadmap to guide contributors.
Publish the repo (GitHub/GitLab) and announce it in relevant communities; welcome feedback.

B. Contribute to an existing project (learn from others):

Pick a project you use and read its contribution guide and code of conduct.
Look for labels like good first issue, help wanted, or docs.
Start with documentation, tests, or small bug fixes to build context and confidence.
Communicate clearly: describe your changes, link tests, and be open to reviewer feedback.

C. Be helpful, not a nuisance: small, respectful, well-explained contributions win friends. Avoid low-effort or noisy PRs and follow the project's contribution norms — a good reminder is this tongue-in-cheek example: https://www.reddit.com/r/ProgrammerHumor/comments/1o0iqf6/lookingclosely/.

Open source is welcoming — start small and grow your impact over time.

Conclusion

Open source offers an incredible way for new developers to learn, contribute, and shape software used around the world. Start small, be consistent, and you’ll find that helping others also accelerates your own growth.

ITG DocVerse - A Developer Knowledge Platform Powered Entirely by Redis

Prakash — Sun, 10 Aug 2025 19:40:26 +0000

This is a submission for the Redis AI Challenge: Beyond the Cache.

What I Built

Meet ITG DocVerse - an internal knowledge-sharing platform for organizations, inspired by the excellent community-driven approach of DEV.to. I wanted to create something that teams could use to document projects, share insights, and collaborate - but with the power of Redis driving everything under the hood.

The platform allows team members to:

📝 Share posts, thoughts, and auto generated documents from git repos (Work in progress)
🔍 Search content using AI-powered semantic search
💬 Engage with discussions and comments
🏷️ Organize content with tags and categories
👤 Build profiles and connect with colleagues

What makes this special is the architecture - I used this hackathon as an opportunity to explore Redis as the complete backbone of the application. From storing user profiles to powering semantic search with vector embeddings, this project demonstrates how Redis can serve as a comprehensive data platform that scales from small teams to enterprise-wide knowledge bases.

Demo

🚀 Live Demo: https://itg-docverse.onrender.com/static/index.html

📚 API Documentation: hhttps://itg-docverse.onrender.com/docs

Screenshots

Main Dashboard & Content Feed

The main feed showing posts with real-time interactions and engagement

Detailed post view with markdown rendering and discussion section

Content Creation & Management

Rich markdown editor for creating technical documentation

Quick thought sharing interface for team communication

AI-Powered Search & Discovery

Semantic search finding relevant content even without exact keyword matches

AI-generated code summaries and documentation from repositories

Automated code analysis and summary generation

Tag-Based Organization

Visual tag cloud for content discovery and organization

Grid-based tag organization for better navigation

User Engagement & Analytics

Real-time reactions and engagement tracking

Community leaderboard and contributor recognition

Comprehensive user profiles with activity tracking

Redis Data Architecture in Action

Redis Insight showing our multi-model data structure

User profiles stored as Redis Hash sets

Post content stored as Redis JSON documents

Tag organization using Redis sorted sets

Vector embeddings stored for semantic search

Content chunking strategy for large documents

How I Used Redis 8

This project leverages Redis as the primary backbone - serving as our database, search engine, and real-time data platform. The hackathon gave me the perfect excuse to see how far I could push Redis beyond traditional caching. Here's how:

🗄️ Redis as Primary Database

Rather than reaching for PostgreSQL or MySQL, I decided to architect the application around Redis data structures to see what was possible:

User Management with Hash Sets

# User profiles stored as Redis hashes
HSET user:prakash88 
  id "ac2402cf-9a84-46a5-8484-d32400e7a18d"
  username "prakash88" 
  display_name "Prakash M"
  email "prakash@example.com"
  bio "Full-stack developer passionate about Redis"
  avatar_url "https://..."
  joined_date "2025-01-15T10:30:00Z"

Content Storage with JSON Documents

# Posts stored as Redis JSON with rich metadata
JSON.SET post:technical-architecture $ '{
  "id": "post-technical-architecture",
  "title": "Building with Redis: Beyond the Cache",
  "content": "# How Redis Powers Modern Applications...",
  "author_id": "ac2402cf-9a84-46a5-8484-d32400e7a18d",
  "post_type": "posts",
  "tags": ["redis", "architecture", "database"],
  "created_at": "2025-01-15T14:22:00Z",
  "read_time": 8
}'

Indexing with Sorted Sets for Performance

# Time-based post feeds using sorted sets
ZADD posts:by_date 1737890520 "post-technical-architecture"
ZADD posts:by_tag:redis 1737890520 "post-technical-architecture" 
ZADD user:prakash88:posts 1737890520 "post-technical-architecture"

🧠 AI-Powered Vector Search

The real magic happens with Redis's vector search capabilities. I built a semantic search engine that understands context, not just keywords:

Vector Embeddings Storage

# 768-dimensional embeddings stored efficiently
HSET search:vector:post-architecture-chunk-0
  vector "\x3e\x9a\x12\x40..."  # Binary encoded float32 array
  metadata '{"post_id": "post-architecture", "content": "Redis serves as...", "title": "Technical Architecture"}'

# Index management
SADD search:chunks "post-architecture-chunk-0"

The Search Pipeline

Content Chunking: Break posts into semantic chunks (~500 words)
Embedding Generation: Use Ollama's nomic-embed-text model to create 768-dim vectors
Redis Storage: Store vectors as binary data with metadata
Similarity Search: Cosine similarity against all stored vectors
Results Ranking: Return top matches with relevance scores

📊 Data Architecture in Redis

Here's how I structured the data across Redis:

Redis Database Structure
├── Users (Hashes)
│   ├── user:{username} → Profile data
│   └── user:{id}:posts → User's post references
│
├── Posts (JSON Documents)  
│   ├── post:{id} → Full post content
│   ├── posts:by_date → Time-ordered feed
│   └── posts:by_tag:{tag} → Tag-based organization
│
├── Comments (Hashes)
│   ├── comment:{id} → Comment data
│   └── post:{id}:comments → Post comment references
│
├── Vector Search (Mixed Types)
│   ├── search:chunks → Set of all chunk IDs
│   ├── search:vector:{chunk_id} → Hash with vector + metadata
│   └── search:metadata:{post_id} → Post search metadata
│
└── Authentication (Strings)
    └── session:{token} → JWT session data

Redis Data Model Visualization

graph TB
    subgraph "User Management"
        A[user:prakash88<br/>Hash: Profile Data] --> B[user:ac24...18d:posts<br/>Sorted Set: Post IDs]
        C[user:sarah_dev<br/>Hash: Profile Data] --> D[user:7576...9c08:posts<br/>Sorted Set: Post IDs]
    end

    subgraph "Content Storage"
        E[post:welcome-guide<br/>JSON: Full Content] --> F[posts:by_date<br/>Sorted Set: All Posts]
        G[post:architecture<br/>JSON: Full Content] --> F
        E --> H[posts:by_tag:tutorial<br/>Sorted Set: Tagged Posts]
        G --> I[posts:by_tag:redis<br/>Sorted Set: Tagged Posts]
    end

    subgraph "Vector Search Engine"
        J[search:chunks<br/>Set: All Chunk IDs] --> K[search:vector:post-guide-chunk-0<br/>Hash: Vector + Metadata]
        J --> L[search:vector:post-arch-chunk-0<br/>Hash: Vector + Metadata]
        K --> M[768-dim Binary Vector<br/>+ JSON Metadata]
        L --> N[768-dim Binary Vector<br/>+ JSON Metadata]
    end

    subgraph "Engagement Layer"
        O[comment:cm1<br/>Hash: Comment Data] --> P[post:welcome-guide:comments<br/>List: Comment IDs]
        Q[comment:cm2<br/>Hash: Comment Data] --> P
    end

    B -.-> E
    D -.-> G
    E -.-> K
    G -.-> L

Data Flow for Search Operations

sequenceDiagram
    participant User
    participant API
    participant Redis
    participant Ollama

    User->>API: Search "react architecture"
    API->>Ollama: Generate embedding
    Ollama-->>API: 768-dim vector

    API->>Redis: SMEMBERS search:chunks
    Redis-->>API: [chunk-0, chunk-1, ...]

    loop For each chunk
        API->>Redis: HGET search:vector:chunk-N vector
        Redis-->>API: Binary vector data
        Note over API: Calculate cosine similarity
    end

    Note over API: Sort by similarity score
    API->>Redis: HGET search:vector:best-chunks metadata
    Redis-->>API: Post metadata + content
    API-->>User: Ranked search results

Redis Key Patterns Used

Pattern	Type	Purpose	Example
`user:{username}`	Hash	User profile storage	`user:prakash88`
`user:{id}:posts`	Sorted Set	User's posts by time	`user:ac24...18d:posts`
`post:{id}`	JSON	Complete post content	`post:welcome-guide`
`posts:by_date`	Sorted Set	Global feed timeline	`posts:by_date`
`posts:by_tag:{tag}`	Sorted Set	Tag-based organization	`posts:by_tag:redis`
`search:vector:{chunk_id}`	Hash	Vector + metadata	`search:vector:post-arch-chunk-0`
`search:chunks`	Set	All searchable chunks	`search:chunks`
`comment:{id}`	Hash	Comment data	`comment:cm1`
`post:{id}:comments`	List	Post's comments	`post:welcome-guide:comments`

⚡ Performance Optimizations

Redis's speed shines through several optimizations:

1. Compound Queries with Pipeline

# Fetch user, their posts, and engagement data in one roundtrip
pipe = redis_client.pipeline()
pipe.hgetall(f"user:{username}")
pipe.zrevrange(f"user:{user_id}:posts", 0, 19)  # Latest 20 posts
pipe.scard(f"user:{user_id}:followers")
results = pipe.execute()

2. Smart Caching with Expiration

# Cache frequently accessed data with TTL
redis_client.setex(f"popular:posts:today", 3600, json.dumps(trending_posts))

3. Memory-Efficient Vector Storage

Instead of storing vectors as JSON arrays, I serialize them as binary:

# Convert float array to compact binary format
vector_bytes = np.array(embedding, dtype=np.float32).tobytes()
redis_client.hset(f"search:vector:{chunk_id}", "vector", vector_bytes)

🔄 Future Real-Time Features

The current architecture is designed to support additional Redis capabilities in the roadmap:

Chatbot Integration: A knowledge-base powered chatbot using the existing vector search
Redis Streams: For storing and processing chat queries and user interactions
Pub/Sub: For real-time chat notifications and live updates
Advanced Analytics: Using the engagement data already being collected

The "Aha!" Moments

Building this taught me that Redis isn't just fast storage - it's a complete data platform:

Easy Migration: Originally started with SQLite, but adding Redis support was surprisingly smooth thanks to our service layer architecture
JSON Support: Redis JSON made complex document storage trivial - no more complex table joins!
Vector Search: No need for separate vector databases like Pinecone - Redis handled it natively
Multi-Model Flexibility: Hash sets for profiles, sorted sets for feeds, JSON for posts - all in one system
Atomic Operations: Complex updates in single commands instead of transaction blocks
Memory Efficiency: Surprisingly good performance even with a 12-chunk vector index
Scalability: What started as a simple SQLite app easily scaled to support Redis's advanced features

Technical Stack

Backend: FastAPI (Python) with Redis as the primary database
Frontend: React + TypeScript with Vite
UI Framework: Tailwind CSS + shadcn/ui components
AI: Ollama for local embeddings (nomic-embed-text model)
Search: Redis vector operations with cosine similarity
Authentication: JWT tokens stored in Redis
Deployment: Docker-compose for easy setup

What's Next?

This hackathon project was a great exploration of Redis's potential as an application backbone. I would like to explore other Redis capabilities for the :

Complete Redis migration: Since the project was started in Sqlite and migrated to Redis not all capabilities works in Redis
AI Chatbot: Knowledge-base powered assistant using existing vector search
Real-time Chat: Redis Streams for storing chat history and Pub/Sub for live messaging
Advanced Analytics: Redis TimeSeries for tracking user engagement patterns
Geographic Features: Redis GEO commands for location-based content
Enhanced Search: Combining full-text search with vector similarity

Try It Yourself

# Clone and run with Docker
git clone https://github.com/ITechGenie/itg-docverse
cd itg-docverse
docker-compose up -d

# Or run locally
cd apis && pip install -r requirements.txt && python main.py
cd app && npm install && npm run dev

Redis isn't just about caching anymore - it's a powerful platform for building modern applications. ITG DocVerse shows what's possible when you use Redis as your application's backbone.

The hackathon challenge gave me the perfect excuse to explore these capabilities! 🚀

OpenFGA Studio - An Open Source Authorization Modeling Interface

Prakash — Tue, 10 Jun 2025 18:22:48 +0000

Understanding OpenFGA

OpenFGA (Fine-Grained Authorization) is a high-performance authorization engine built for developers and inspired by Google's Zanzibar paper. It excels in handling complex authorization scenarios with features that make it stand out:

Relationship-Based Authorization: Model complex access patterns through relationships
High Performance: Process millions of authorization checks per second
Flexibility: Support for RBAC, ABAC, and ReBAC models
Time-Based Access: Define temporal access rules with built-in support
Proven Architecture: Based on Google's battle-tested Zanzibar system

While OpenFGA Playground provides a hosted application for experimentation, it comes with limitations:

Not open source
Cannot be deployed in air-gapped environments
Limited customization options
Dependency on external services

Why This Project?

I built OpenFGA Studio to address these limitations and provide:

A fully open-source solution deployable anywhere
Enhanced user experience for authorization modeling
Complete control over your authorization data
Customizable interface for specific needs
Seamless integration with existing systems

OpenFGA Studio streamlines the process of creating, testing, and managing authorization models, making complex authorization logic more accessible and manageable. Built with modern web technologies including React, TypeScript, and Material-UI, it provides a robust and intuitive interface for working with OpenFGA.

Key Features

1. Store Management

The interface provides a straightforward way for managing OpenFGA stores. You can:

Create new authorization stores
Switch between existing stores
View and manage store configurations
Track model versions and changes

2. Visual Authorization Model Editor

The model editor is a powerful interface for defining authorization rules with features including:

Syntax highlighting for better readability
Real-time validation against OpenFGA schema
Support for both DSL and JSON formats
Error highlighting and suggestions
Easy switching between model versions

3. Interactive Graph Visualization

Understand your authorization model at a glance with:

Visual representation of relationships between types
Interactive node exploration
Relationship flow visualization
Dynamic updates as you modify the model
Zoom and pan controls for large models

4. Advanced Tuple Management

The tuple management interface makes it easy to define and manage relationships:

Assisted tuple creation with type suggestions
Support for direct (freeform) tuple input
Batch operations for efficient management
Reverse chronological listing of tuples
Quick delete operations

5. Conditional Relationship Support

Handle complex authorization scenarios with conditional relationships:

Dynamic condition parameter inputs
Type-aware parameter validation
Timestamp and duration support
Visual feedback for condition state

6. Comprehensive Query Testing

Test your authorization rules with an intuitive interface:

Features include:

Visual query builder
Direct query input support
Real-time query validation
Historical query tracking
Quick query replay

7. Conditional Access Testing

Test complex conditional access patterns:

Test time-based access rules
Validate contextual conditions
Dynamic parameter inputs
Clear success/failure indicators

8. Developer-Friendly Features

OpenFGA Studio is built with developers in mind:

Clean, modern UI with dark mode support
Keyboard shortcuts for common operations
Copy/paste support for all fields
Detailed error messages
Response timing information

Technical Implementation

OpenFGA Studio is built with modern web technologies:

Frontend: React with TypeScript for type safety
UI Framework: Material-UI for consistent, responsive design
State Management: React hooks and context for efficient state handling
Build Tool: Vite for fast development and optimized production builds
API Integration: Axios for reliable API communication
Graph Visualization: React Flow for interactive model visualization

Common Use Cases

Authorization Modeling
- Design role-based access control (RBAC) systems
- Implement attribute-based access control (ABAC)
- Model relationship-based authorization
Testing and Validation
- Verify access control rules
- Test time-based permissions
- Validate complex conditional access
Development and Debugging
- Debug authorization issues
- Prototype authorization models
- Document access control patterns

Conclusion

OpenFGA Studio simplifies the complex task of fine-grained authorization modeling and testing. Whether you're designing a new authorization system or maintaining an existing one, this tool provides the features needed to work efficiently with OpenFGA.

The combination of visual tools, intuitive interfaces, and powerful testing capabilities makes it an essential tool for developers working with authorization systems. The tool continues to evolve with new features and improvements based on community feedback and real-world usage patterns.

Feel free to contribute or request features at OpenFGA Studio

Enhancing the VS Code Agent Mode to integrate with Local tools using Model Context Protocol (MCP)

Prakash — Sun, 18 May 2025 20:17:53 +0000

Enhancing the VS Code Agent Mode to integrate with Local tools using Model Context Protocol (MCP)

Building a Todo List Server with Model Context Protocol (MCP)

This blog post walks through creating a Todo List server using the Model Context Protocol (MCP), demonstrating how to build AI-friendly tools that integrate seamlessly with VS Code.

🔗 Source Code: The complete implementation is available on GitHub

The Evolution of AI-Assisted Development
What is Model Context Protocol (MCP)?
Architecture Overview
Prerequisites
Setting Up the Project
Implementing the MCP Server
VS Code Integration
Using the Todo MCP Server
Next Steps and Improvements
Troubleshooting
Resources

The Evolution of AI-Assisted Development

I have been using VS Code with GitHub Copilot for development purposes. The introduction of text-based chat, which brought GPT capabilities directly into the IDE, was revolutionary.

GitHub Copilot and the Local Tools Gap

GitHub Copilot has revolutionized how developers write code by providing intelligent code suggestions and completions. While it excels at understanding code context and generating relevant snippets, there has been a notable gap in its ability to interact with local development tools, intranet KBs, and execute actions in the development environment. This limitation means that while Copilot can suggest code, it cannot directly help with tasks like running commands, managing files, or interacting with local services.

Agent Mode: Bridging the Gap

The introduction of Agent Mode in GitHub Copilot represents a significant step forward in AI-assisted development. It enables Copilot to:

Execute terminal commands
Modify files directly
Interact with the VS Code environment
Handle project-specific tasks

This advancement transformed Copilot from a passive code suggestion tool into an active development partner that can help manage your entire development workflow. Here are some powerful capabilities and example interactions:

1. Build and Test Automation

Trigger Maven builds with specific profiles:

"Run mvn clean install with the 'production' profile for my project"

Execute JUnit test suites:

"Execute all JUnit tests in the UserServiceTest class"

Run code quality tools:

"Run ESLint on all JavaScript files in the src directory"
"Start a local Sonar analysis with coverage and security scan"

2. Documentation and Release Management

Generate release documentation:

"Generate release notes for changes between tag v1.2.0 and v1.3.0"

Technical documentation:

"Create a technical design document for the authentication service"
"Update the API documentation in Confluence for the new endpoints"

3. Project Management Integration

JIRA ticket management:

"Create a JIRA ticket for the memory leak bug we found in the login service"
"Convert all TODO comments in AuthService.java to JIRA tickets"

Sprint management:

"Update the status of PROJ-123 to 'In Review' and add a comment with the PR link"
"Show me all JIRA tickets assigned to me that are blocking the current sprint"

4. Cross-Repository Operations

Multi-repo analysis:

"Check if the latest changes in the API repo are compatible with our client library"
"Run integration tests across both the frontend and backend repositories"

Try the above prompts in VSCode Agent mode and see the magic.

While these capabilities demonstrate the power of Agent Mode, they highlight a crucial challenge: the need for external API integrations. Each of these tasks requires:

Authentication with external services (JIRA, Confluence, Sonar)
Managing different API versions and endpoints
Handling various authentication methods
Maintaining connection states and sessions
Coordinating operations across multiple systems

This complexity creates significant overhead for developers who need to:

Implement and maintain integration code for each service
Handle authentication and authorization
Manage API versioning and changes
Deal with different response formats and error handling

MCP: The New Standard for AI Tool Integration

Model Context Protocol (MCP) emerges as the next evolution in this space, providing a standardized way for AI models to interact with development tools and services. Unlike traditional approaches where AI assistants are limited to suggesting code, MCP enables:

Direct Tool Integration
- AI models can directly invoke local tools
- Real-time interaction with development environment
- Standardized communication protocol
Extensible Architecture
- Custom tool definitions
- Plugin-based system
- Easy integration with existing services
Development Environment Awareness
- Context-aware assistance
- Access to local resources
- Real-time feedback loop

What is Model Context Protocol (MCP)?

Model Context Protocol (MCP) is a specification that enables AI models to interact with external tools and services in a standardized way. It defines how tools can expose their functionality through a structured interface that AI models can understand and use.

Key benefits of MCP that I have personally benefited from:

Standardized tool definitions with JSON Schema
Real-time interaction capabilities
Session management
Built-in VS Code integration

More about MCP Architecture Documentation

How MCP Tools Work

Each MCP tool follows a standardized structure:

{
  name: "toolName",
  description: "What the tool does",
  parameters: {
    // JSON Schema definition of inputs
  },
  returns: {
    // JSON Schema definition of outputs
  }
}

When an AI model wants to use a tool:

It sends a request with the tool name and parameters
The MCP server validates the request
The tool executes with the provided parameters
Results are returned in a standardized format

This structured approach ensures:

Consistent tool behavior
Type safety throughout the system
Easy tool discovery and documentation
Predictable error handling

Architecture Overview

Here's how the different components interact in our MCP Todo implementation:

graph TD
    A[GitHub Copilot] -->|Natural Language Commands| B[VS Code]
    B -->|MCP Protocol| C[MCP Todo Server]
    C -->|CRUD Operations| D[(LowDB/Database)]
    C -->|Real-time Updates| B
    B -->|Command Results| A

Prerequisites

To follow along, you'll need:

Node.js (v22 or higher)
VS Code
Basic understanding of Express.js
npm or yarn package manager

Setting Up the Project

First, create a new project and initialize npm:

mkdir mcp-todo-server
cd mcp-todo-server
npm init -y

Install required dependencies:

npm install @modelcontextprotocol/sdk express lowdb zod

For this demonstration, we're using lowdb to manage tasks in a JSON file without actual integration with an external system. In a production environment, the lowdb functions can be replaced with actual JIRA CRUD API calls for end-to-end implementation.

Create the basic directory structure:

mcp-todo-server/
├── src/
│   ├── config/
│   ├── tools/
│   ├── utils/
│   └── server.js
└── package.json

Implementing the MCP Server

1. Basic Server Setup

We started with a basic Express server that implements the MCP protocol. The server uses StreamableHTTP for real-time communication and session management.

Key components in server.js:

Express server setup
MCP SDK integration
StreamableHTTP transport configuration
Session management for maintaining tool state

2. Database Configuration

We used lowdb, a lightweight JSON database, to persist our todos. The database configuration in config/db.js handles:

JSON file storage
Basic CRUD operations
Data persistence between server restarts

3. Implementing Todo Tools

We implemented four main tools for managing todos:

createTodo
- Creates new todo items
- Validates input using Zod schema
- Returns the created todo with a unique ID
listTodos
- Lists all todos or filters by completion status
- Formats output for easy reading
- Supports real-time updates
updateTodo
- Updates todo completion status
- Validates input parameters
- Returns updated todo information
deleteTodo
- Removes todos by ID
- Provides completion confirmation
- Handles error cases gracefully

VS Code Integration

To enable VS Code to use our MCP server, follow these steps:

Enable Agent mode in VS Code. Click on the drop down just before the model listing and select agent from it.

Then click on the Gear icon next to the speaker icon in the above image and select "Add more tools" then select "Add MCP Server"

Then select HTTP or Server-Sent Events and provide the URL based on the server we created. In this case, it's http://localhost:3000. Then select a name for the server.

Alternatively you can Press Ctrl+Shift+P (Windows/Linux) or Cmd+Shift+P (Mac) to open the Command Palette. Type "Open Settings (JSON)" and select it and add the following configuration:

{
    "mcp": {
        "servers": {
            "my-mcp-server": {
                "url": "http://localhost:3000/mcp"
            }
        }
    }
}

You can use the 4th step to verify if the server is added correctly after the first 3 steps are done. The User Settings option has Start, Stop, and Restart options. This step helped me identify if there are any issues with the MCP tools server effectively.

Reload VS Code to apply the changes or use the Start, Stop, Restart options in the settings.json as shown above.
After successful addition of the MCP server, you should see the tools listed when you click the gear icon in the Copilot chat window.

Using the Todo MCP Server

Here are some example prompts you can use in VS Code with GitHub Copilot to interact with the todo server. Each example includes a screenshot of the actual interaction:

Creating a Todo

   Prompt: "Create a new todo item called 'Review PR #123'"
   Response: Successfully created todo "Review PR #123"

Listing Todos

   Prompt: "Show me all my todos"
   Response: Here are your todos:
   - Review PR #123 (Not completed)
   - Update documentation (Completed)
   - Setup test environment (Not completed)

Updating a Todo

   Prompt: "Mark the todo about PR review as completed"
   Response: Updated "Review PR #123" to completed

Deleting a Todo

   Prompt: "Delete the todo about documentation"
   Response: Successfully deleted "Update documentation"

Filtering Todos

   Prompt: "Show me only completed todos"
   Response: Completed todos:
   - Review PR #123

Next Steps and Improvements

Potential enhancements for the project:

Authentication
- Add user authentication
- Implement role-based access
Advanced Features
- Due dates for todos
- Categories/tags
- Priority levels
Performance
- Caching
- Database optimization
- Rate limiting
Testing
- Unit tests
- Integration tests
- Load testing

Troubleshooting

Common Issues and Solutions

Server Connection Issues
- Verify the server is running on port 3000
- Check VS Code settings for correct server URL
- Ensure no firewall blocking the connection
Tool Registration Problems

   Error: Tool 'createTodo' not found
   Solution: Check if server is properly initializing tools in server.js

Schema Validation Errors
- Ensure todo items match the required schema
- Check Zod validation rules in tool implementations
- Verify JSON payload format
Real-time Updates Not Working
- Confirm SSE (Server-Sent Events) connection is established
- Check browser console for connection errors
- Verify StreamableHTTP transport configuration

Source Code Reference

Key implementation files:

Server setup: src/server.js
Tool implementations:
Database configuration: src/config/db.js

Conclusion

We've successfully built a fully functional MCP-compatible Todo server that:

Implements CRUD operations
Maintains persistent storage
Provides real-time updates
Integrates seamlessly with VS Code

This implementation serves as a great starting point for building more complex MCP tools and understanding how AI models can interact with custom tools through the Model Context Protocol.

Resources

You can also:

Report bugs by creating issues
Suggest improvements through discussions
Help improve documentation
Originally posted at ITechGenie

Creating a browser extension for Chrome / Edge

Prakash — Mon, 17 Jun 2024 20:32:40 +0000

Creating a browser extension has never been easier, thanks to the comprehensive documentation and support provided by browser vendors. Below, I’ll walk through the steps to create a simple extension for both Chrome and Microsoft Edge using Manifest V3. We will use this tool to print the list of HTTP requests that are fired in a given webpage and list it in the extension.

Basics of extensions:

Manifests – A manifest is a JSON file that contains metadata about a browser extension, such as its name, version, permissions, and the files it uses. It serves as the blueprint for the extension, informing the browser about the extension’s capabilities and how it should be loaded.

Key Components of a Manifest File:

Here are the key components typically found in a Manifest V3 file:

1. Manifest Version: There are different versions of the manifest file, with Manifest V3 being the latest and most widely adopted version. Manifest V3 introduces several changes aimed at improving security, privacy, and performance with lot of controversies around it. Read more about the controversies at Ghostery.

2. Name and Version: These fields define the name and version of the extension. Choose a unique name and version. An excellent guide of version semantics is available here.

3. Description: A short description of the extension’s functionality.

4. Action: Defines the default popup and icon for the browser action (e.g., toolbar button).

5. Background: Specifies the background script that runs in the background and can handle events like network requests and alarms.

6. Content Scripts: Defines scripts and stylesheets to be injected into matching web pages.

7. Permissions: Lists the permissions the extension needs to operate, such as access to tabs, storage, and specific websites.

8. Icons: Specifies the icons for the extension in different sizes. For this post I created a simple icon using Microsoft Designer. I gave a simple prompt with the description above and I got the below image. Extension requires different sizes for showing it in different places. I used Chrome Extension Icon Generator and generated different sizes as needed.

9. Web Accessible Resources: Defines which resources can be accessed by web pages.

Create a project structure as follows:

HttpRequestViewer/
|-- manifest.json
|-- popup.html
|-- popup.js
|-- background.js
|-- history.html
|-- history.js
|-- popup.css
|-- styles.css
|-- icons/
    |-- icon.png
    |-- icon16.png
    |-- icon32.png
    |-- icon48.png
    |-- icon128.png

Manifest.json

{
  "name": "API Request Recorder",
  "description": "Extension to record all the HTTP request from a webpage.",
  "version": "0.0.1",
  "manifest\_version": 3,
  "host\_permissions": \[""\],
  "permissions": \["activeTab", "webRequest", "storage"\],
  "action": {
    "default\_popup": "popup.html",
    "default\_icon": "icons/icon.png"
  },
  "background": {
    "service\_worker": "background.js"
  },
  "icons": {
    "16": "icons/icon16.png",
    "32": "icons/icon32.png",
    "48": "icons/icon48.png",
    "128": "icons/icon128.png"
  },
  "content\_security\_policy": {
    "extension\_pages": "script-src 'self'; object-src 'self';"
  },
  "web\_accessible\_resources": \[{ "resources": \["images/\*.png"\], "matches": \["https://\*/\*"\] }\]
}

popup.html

We have two options with the extension.

1. A button with record option to start recording all the HTTP requests

2. Link to view the history of HTTP Requests recorded

<!DOCTYPE html>
<html>
  <head>
    <title>API Request Recorder</title>

    <link rel="stylesheet" href="popup.css" />
  </head>
  <body>
    <div class="heading">
      <img class="logo" src="icons/icon48.png" />
      <h1>API Request Recorder</h1>
    </div>
    <button id="startStopRecord">Record</button>

    <div class="button-group">
      <a href="#" id="history">View Requests</a>
    </div>

    <script src="popup.js"></script>
  </body>
</html>

popup.js

Two event listeners are registered for recording (with start / stop) and viewing history.

First event is used to send a message to the background.js, while the second one instructs chrome to open the history page in new tab.

document.getElementById("startStopRecord").addEventListener("click", () => {
  chrome.runtime.sendMessage({ action: "startStopRecord" });
});

document.getElementById("history").addEventListener("click", () => {
  chrome.tabs.create({ url: chrome.runtime.getURL("/history.html") });
});

history.html

<!DOCTYPE html>
<html>
  <head>
    <title>History</title>
    <link rel="stylesheet" href="styles.css" />
  </head>
  <body>
    <h1>History Page</h1>
    <table>
      <thead>
        <tr>
          <th>Method</th>
          <th>URL</th>
          <th>Body</th>
        </tr>
      </thead>
      <tbody id="recorded-data-body">
        <!-- Data will be populated here -->
      </tbody>
    </table>
    <script src="history.js"></script>
  </body>
</html>

history.js

Requests background.js to “getRecordedData” and renders the result in the html format.

document.addEventListener("DOMContentLoaded", () => {
  chrome.runtime.sendMessage({ action: "getRecordedData" }, (response) => {
    const tableBody = document.getElementById("recorded-data-body");
    response.forEach((record) => {
      const row = document.createElement("tr");
      const urlCell = document.createElement("td");
      const methodCell = document.createElement("td");
      const bodyCell = document.createElement("td");

      urlCell.textContent = record.url;
      methodCell.textContent = record.method;
      bodyCell.textContent = record.body;

      row.appendChild(methodCell);
      row.appendChild(urlCell);
      row.appendChild(bodyCell);
      tableBody.appendChild(row);
    });
  });
});

background.js

Background JS works as a service worker for this extension, listening and handling events.

The background script does not have access to directly manipulate the user page content, but can post results back for the popup/history script to handle the cosmetic changes.

let isRecording = false;
let recordedDataList = \[\];

chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
  console.log("Obtined message: ", message);
  if (message.action === "startStopRecord") {
    if (isRecording) {
      isRecording = false;
      console.log("Recording stopped...");
      sendResponse({ recorder: { status: "stopped" } });
    } else {
      isRecording = true;
      console.log("Recording started...");
      sendResponse({ recorder: { status: "started" } });
    }
  } else if (message.action === "getRecordedData") {
    sendResponse(recordedDataList);
  } else {
    console.log("Unhandled action ...");
  }
});

chrome.webRequest.onBeforeRequest.addListener(
  (details) => {
    if (isRecording) {
      let requestBody = "";
      if (details.requestBody) {
        if (details.requestBody.formData) {
          requestBody = JSON.stringify(details.requestBody.formData);
        } else if (details.requestBody.raw) {
          requestBody = new TextDecoder().decode(new Uint8Array(details.requestBody.raw\[0\].bytes));
        }
      }
      recordedDataList.push({
        url: details.url,
        method: details.method,
        body: requestBody,
      });
      console.log("Recorded Request:", {
        url: details.url,
        method: details.method,
        body: requestBody,
      });
    }
  },
  { urls: \[""\] },
  \["requestBody"\]
);

Lets load the Extension

All set, now lets load the extension and test it.

Open Chrome/Edge and go to chrome://extensions/ or edge://extensions/ based on your browser.
Enable “Developer mode” using the toggle in the top right corner.
Click “Load unpacked” and select the directory of your extension.

Your extension should now be loaded, and you can interact with it using the popup.
When you click the “Record” button, it will start logging API requests to the console.

Click the “Record” button again and hit the “View requests” link in the popup to view the history of APIs.

I have a sample page (https://itechgenie.com/demos/apitesting/index.html) with 4 API calls, which also loads images based on the API responses. You could see all the API requests that is fired from the page including the JS, CSS, Images and API calls.

Now its up to the developers imagination to build the extension to handle these APIs request and response data and give different experience.

Code is available in GitHub at HttpRequestViewer

Post originally shared at ITechGenie.com