Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
64 changes: 44 additions & 20 deletions .kiro/skills/product/SKILL.md
Original file line number Diff line number Diff line change
@@ -1,36 +1,60 @@
---
name: product
description: Graph Explorer product overview including supported graph types, query languages, databases, key features, and high-level architecture.
tools: ["fs_read", "grep", "glob", "web_search"]
description: "Graph Explorer product context β€” supported databases, query languages, features, and architecture. Use when the user asks about Graph Explorer capabilities, deployment options, supported databases, query language choices, or how the system is structured."
---

# Graph Explorer Product Overview

Graph Explorer is a React-based web application that enables users to visualize and explore graph data without writing queries. It supports multiple graph database types and query languages.
Graph Explorer is a React-based web application for visualizing and exploring graph data without writing queries. It supports multiple graph databases and query languages through a connector abstraction.

## Core Purpose
## Quickstart
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "Core Purpose" section describes the product's use case, which the agent can't derive from code alone. It helps the agent understand what problem Graph Explorer solves, not just what it is. I'd prefer to keep it since the vagueness is deliberate β€” it stays accurate as the app evolves.


- Visualize property graphs (LPG) and RDF data
- Interactive graph exploration without requiring query knowledge
- Connect to various graph databases over HTTP
Clone the repo and launch with the Air Routes sample dataset:

## Supported Graph Types & Query Languages
```bash
cd graph-explorer/samples/air_routes
docker compose up
```

- **Property Graphs**: Gremlin, openCypher
- **RDF Graphs**: SPARQL 1.1 protocol
- **Databases**: Amazon Neptune, Amazon Neptune Analytics, Apache TinkerPop Gremlin Server REST endpoints, JanusGraph
Open [http://localhost:8080/explorer](http://localhost:8080/explorer). A default Gremlin connection is pre-configured.

For production deployment, pull the official image from ECR Public:

```bash
docker pull public.ecr.aws/neptune/graph-explorer
docker run -p 80:80 -p 443:443 --env HOST=localhost public.ecr.aws/neptune/graph-explorer
```
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This "Quickstart" section duplicates the user guide and isn't something the agent would typically need to perform. If it ever does, it can discover the quick start instructions from the existing docs via progressive disclosure. I'd drop this section to keep the skill focused on product context rather than setup steps.


Then open `https://localhost/explorer`.

## Supported Databases & Query Languages

| Graph Model | Query Language | Databases |
|---|---|---|
| Property Graph (LPG) | Gremlin | Amazon Neptune, Apache TinkerPop Gremlin Server, JanusGraph |
| Property Graph (LPG) | openCypher | Amazon Neptune, Amazon Neptune Analytics |
| RDF | SPARQL 1.1 | Amazon Neptune |
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the intent here, but I worry this table is too prescriptive for an agent facing doc. These are providers we've tested, not an exhaustive set of what's supported. There are other Gremlin and SPARQL compatible databases that would work fine but aren't listed. Could we rename the column to "Example Databases" to frame these as known-good examples rather than a definitive list? Otherwise the agent might reject valid configurations just because they're not in the table.


**When to use which:**
- **Gremlin** β€” Traversal-based queries on property graphs. Best for path-finding and step-by-step graph walks.
- **openCypher** β€” Declarative pattern matching on property graphs. Best for subgraph pattern queries.
- **SPARQL** β€” RDF triple pattern matching. Required when the data is RDF/linked data.

## Key Features

- **Connections Management**: Create and manage database connections
- **Graph Visualization**: Interactive graph view with search, custom queries, and styling
- **Tabular View**: Show/hide nodes and edges, export to CSV/JSON
- **Data Explorer**: List all nodes and properties for a specific node type and send to graph view
- **Schema Explorer**: View node types and their relationships as a graph
- **Authentication**: AWS IAM authentication via SigV4 signing protocol
- **Connections**: Create and manage database connections (`Connections` page). See `docs/features/connections.md`.
- **Graph View**: Interactive canvas with search, neighbor expansion, custom queries, and node styling. See `docs/features/graph-view.md`.
- **Data Table**: Paginated tabular view with export to CSV/JSON. See `docs/features/data-table.md`.
- **Schema View**: Visual overview of node types and edge relationships. See `docs/features/schema-view.md`.
- **AWS IAM Auth**: SigV4 signing via the proxy server for Neptune connections.

## Architecture

- **Frontend**: TypeScript React application served via Vite
- **Backend**: Express.js proxy server for authentication and request routing
- **Deployment**: Docker containers, supports local and cloud deployment (EC2, ECS)
Two packages in a pnpm monorepo:

- **`packages/graph-explorer`** β€” React client. Constructs queries, manages state (Jotai atoms), renders the graph (Cytoscape.js), and caches remote data (TanStack Query).
- **`packages/graph-explorer-proxy-server`** β€” Express server. Forwards requests to the database, handles SigV4 signing for Neptune, and serves built client assets.

The proxy exists because browsers cannot perform SigV4 signing directly. For non-Neptune databases, the client can connect to the endpoint directly (no proxy required). All user data (preferences, connections, query history) is stored client-side in IndexedDB via localforage.

See `docs/architecture.md` for the full system diagram and library reference.