Azure Logic Apps UX Monorepo

Welcome to the monorepo for the user experience (UX) components and tools for Azure Logic Apps. This repository contains the core UI libraries, standalone designer, documentation site, and VS Code extension for authoring and managing Logic Apps with a modern, extensible user experience.

Getting Started

Documentation for getting started, including setup and usage, can be found at: https://aka.ms/logicappsux

If you're interested in contributing or running components locally, see the specific README files inside relevant applications and libraries (e.g., apps/Standalone, apps/docs, etc.).

Repository Structure

This repository is organized as a PNPM-powered monorepo with Turborepo for managing builds and dependencies. Key directories include:

• apps/
• Standalone/: The standalone Logic Apps Designer (React, TypeScript, Vite).
• docs/: Documentation website (built with Docusaurus).

• vs-code-designer/: VS Code extension for Logic Apps Designer.

• libs/: Shared libraries and UI packages used across applications.

• e2e/: End-to-end testing setup.

• Localize/: Localization resources.

See each application's README for more details and setup instructions.

AI-Assisted Development (Knowledge Graphs)

This repo uses Graphify to maintain per-library knowledge graphs that map code structure, identify core abstractions, and surface cross-file relationships. These graphs help both AI coding assistants and developers navigate the codebase structurally instead of grepping blindly.

What's in the graphs

Each library has a graphify-out/ directory inside src/ containing:

Current library graphs:

How graphs stay up to date

Graphs are auto-rebuilt by CI via the update-knowledge-graphs.yml GitHub Action whenever TypeScript source files change on main. No manual action needed — pull latest main and the graphs are current.

AI assistant integration

Graphs work automatically with AI coding tools — no per-user setup required:

Optional: CLI queries (power users)

For interactive graph queries, install the Graphify CLI:

# One-time setup — installs graphify CLI + Copilot CLI skill
pnpm run graphify:setup

# Query the graph
graphify query "how does the serialization pipeline work?" \
  --graph libs/designer-v2/src/graphify-out/graph.json

# Trace shortest path between two abstractions
graphify path "serializeWorkflow" "BJSDeserializer" \
  --graph libs/designer-v2/src/graphify-out/graph.json

# Explain a god node and its neighbors
graphify explain "getOperationSettings" \
  --graph libs/designer-v2/src/graphify-out/graph.json

# Generate interactive HTML visualization (open in browser)
cd libs/designer-v2 && graphify update src/
open src/graphify-out/graph.html

Manual rebuild

If you need to rebuild graphs locally (e.g., on a feature branch before CI runs):

# Rebuild all libs (pure AST extraction, no LLM, runs in seconds)
pnpm run graphify:rebuild

# Rebuild a specific lib
pnpm run graphify:rebuild -- designer-v2

Requires Python 3.10+ and pipx install graphifyy. The pnpm run graphify:setup command handles both.

Before & after: Real examples from this repo

"What are the core abstractions in designer-v2?"

Prompt: "What are the most important functions and abstractions in the designer-v2 library? Rank them by how central they are to the codebase."

With Graphify, the answer is immediate:

God Nodes (most connected):
1. getOperationSettings()         — 52 edges
2. getReactQueryClient()          — 45 edges
3. isNullOrUndefined()            — 32 edges
4. initializeOperationDetails()   — 24 edges
5. getOperationManifest()         — 21 edges

"What depends on getOperationSettings?"

Prompt: "I need to understand the full dependency chain of getOperationSettings(). What calls it, what does it call, and what consumes its output?"

With Graphify:

Node: getOperationSettings()
  Source:    settings.ts L130 | Community: 8 | Degree: 52
  --> initializeOperationDetails()        [calls] [INFERRED]
  --> initializeOperationDetailsForManifest() [calls] [INFERRED]
  --> isSplitOnSupported()                [calls] [EXTRACTED]
  --> isRetryPolicySupported()            [calls] [EXTRACTED]
  --> isConcurrencySupported()            [calls] [EXTRACTED]
  ... and 47 more with source locations

"What are the surprising/hidden couplings in the codebase?"

Prompt: "What are the non-obvious dependencies in designer-v2? Show me cross-module connections that a developer wouldn't expect from the directory structure alone."

With Graphify (from the actual report):

Surprising Connections:
- DesignerReactFlow() --calls--> useNotes()
  ui/DesignerReactFlow.tsx → core/state/notes/notesSelectors.ts

- usePanelTabs() --calls--> useSettingValidationErrors()
  ui/panel/nodeDetailsPanel/usePanelTabs.tsx → core/state/setting/settingSelector.ts

- onComboboxMenuOpen() --calls--> loadDynamicValuesForParameter()
  ui/panel/.../parametersTab/index.tsx → core/utils/parameters/helper.ts

These are the hidden couplings that cause unexpected bugs when you change "unrelated" code.

Response quality: Real side-by-side test

We gave two AI agents the exact same prompt. One explored blind (grep/view only), the other started with the knowledge graph.

Prompt given to both agents:

"I need to change how operation settings are resolved. What will I break and what's the safest way to approach this?"

The library is at libs/designer-v2/src/. Focus on giving a concrete, actionable answer — what files, what functions, what dependencies. Be specific about what you're confident about vs what you might be missing.

The blind agent was limited to ~10 tool calls (grep/glob/view). The graph agent was instructed to read GRAPH_REPORT.md and run graphify explain "getOperationSettings()" before exploring further.

The key difference isn't speed — it's completeness and confidence. The blind agent missed 3 of 8 call sites because it hit its exploration budget. The graph agent found all 8 and could verify completeness against the graph's known edge count. When an AI tells you "this is the full list" vs "I might be missing some" — that's the difference between a safe refactor and a broken deploy.

Implementation quality: Planning a new feature

We gave two AI agents the exact same implementation prompt. One explored blind, the other started with the knowledge graph.

Prompt given to both agents:

"Add a new 'timeout' host option to designer-v2 that lets the host configure a default timeout (in seconds) for all HTTP actions. When set, the designer should pre-populate the timeout setting for any new HTTP action added to the canvas."

The library is at libs/designer-v2/src/. DO NOT write the code — produce an implementation plan: which files need to change and why, the sequence of changes, which existing patterns to follow, what tests to add/update, and risks/edge cases.

The blind agent was limited to ~12 tool calls. The graph agent was instructed to read GRAPH_REPORT.md, run graphify explain on getOperationSettings() and initializeOperationDetails(), and query "how are host options used in designer" before exploring further.

The implementation difference: The blind agent produced a plan that would compile and mostly work — but would silently miss HTTP actions added via the agent tool path and MCP path. Those would get no default timeout while regular HTTP actions would. The graph agent's plan covers all paths because the graph showed all 5 entry points into getOperationSettings(). That's the difference between a feature that works in the happy path and a feature that works everywhere.

Use cases: How knowledge graphs improve AI-assisted development

1. Onboarding — "Where do I even start?"

Instead of asking an AI assistant to explore a 96K-line library blind, point it at the graph report:

``` Read libs/designer-v2/src/graphify-out/GRAPH_REPORT.