Cross-Language

Overview

Modern codebases rarely live in a single language. A typical service might have TypeScript on the frontend calling a Python API, which in turn writes to SQL tables, while a performance-critical path calls into a C library via Rust FFI.

sqry’s unified graph detects these cross-language relationships automatically during indexing. The detection runs in Pass 5 of the multi-pass graph build pipeline, after all per-language symbol graphs are constructed. sqry matches declarations in one language to definitions in another — for example, matching a Rust extern "C" declaration to the corresponding C function definition, or matching a fetch("/api/users") call in TypeScript to a @app.route("/api/users") handler in Python.

Cross-language edges are first-class nodes in the graph and are queryable with the same tools and syntax as same-language edges.


Supported Edge Types

Edge typeExampleLanguages
ffi_callRust extern "C" declaration matched to C/C++ function definitionRust → C, Rust → C++, C → C++
http_requestfetch("/api/users") or axios.post("/users") matched to route handlerJS/TS → Python, JS/TS → Go, JS/TS → Java
grpc_callgRPC stub call matched to service method definitionAny client → any server language
db_querySQL SELECT/INSERT/UPDATE/DELETE referencing a named tableSQL → table definition (any language)
web_socketWebSocket emit/on matched across client and serverJS/TS ↔ Python, JS/TS ↔ Go
graphql_operationGraphQL query/mutation matched to resolverJS/TS, Python
message_queueMessage producer matched to consumer by topic/queue nameAny language
process_execShell exec/spawn calls referencing an external binary or scriptShell/Bash → any

Detection is heuristic-based and works on naming conventions, route strings, and extern declarations. Accuracy improves when codebases follow standard framework patterns (Express, FastAPI, Gin, Spring MVC, etc.).

Additional edge types

Beyond the primary types above, sqry also detects:

Edge typeDescription
file_ipcFile-based inter-process communication (shared files, pipes)
protocol_callGeneric protocol-based calls not covered by specific types
web_assembly_callWebAssembly module imports and exports

FFI detection by language

sqry detects FFI boundaries for 11 languages. See Language Support — FFI Support for the complete list of supported mechanisms per language (e.g., Rust extern "C", Go CGo, Java JNI/JNA, Python ctypes/cffi).


CLI Queries

List all cross-language edges in the current workspace:

sqry graph cross-language

Filter by source language and edge type:

# All FFI calls originating from Rust
sqry graph cross-language --from-lang rust --edge-type ffi

# All SQL table access edges
sqry graph cross-language --from-lang sql --edge-type table

# All HTTP calls from TypeScript to any backend
sqry graph cross-language --from-lang typescript --edge-type http

# Flutter/Dart platform channel invocations
sqry graph cross-language --from-lang dart --edge-type channel_invoke

Combine with visualization to produce a cross-language dependency diagram:

sqry visualize "callers:main" --format mermaid
sqry export --format dot --output-file cross-lang.dot

MCP Tool

The cross_language_edges MCP tool exposes cross-language relationship data to AI assistants via the Model Context Protocol. It is available to any MCP client (Claude, Codex, Gemini, Cursor, Windsurf) connected to a running sqry mcp server.

The tool returns a structured list of cross-language edges, each with:

This lets an AI assistant answer questions like “what Python routes does the TypeScript frontend call?” or “which C functions are exposed to Rust via FFI?” with ground-truth data from the graph, rather than guessing from code patterns.

The cross_language_edges tool can be enabled or disabled independently using the SQRY_MCP_ENABLE_CROSS_LANGUAGE environment variable:

# Disable cross-language edges in the MCP server (all other tools unaffected)
export SQRY_MCP_ENABLE_CROSS_LANGUAGE=false