urirun

Transporty

urirun trzyma kontrakt URI oddzielnie od transportu. Ten sam URI można wywołać lokalnie, przez endpoint usługi albo przez orkiestrator przepływu. Registry, JSON Schema i bramka polityki to kontrakt; transport jedynie przenosi {uri, payload} tam, gdzie v2.run to wykonuje.

v2/examples/transports napędza jedno registry przez pięć transportów (in-process, kolejka, serverless, HTTP, gRPC) i dostarcza jednokomendowy scan_and_run.py.

Lokalnie i shell

Kolejka i serverless

Docker

Przykłady Docker używają targetów URI jako nazw usług:

python://python-worker/text/normalize
node://node-worker/text/slugify
shell://shell-worker/report/write

Zobacz v2/examples/docker_uri_flow, gdzie usługi Compose publikują bindingi, a orkiestrator uruchamia wieloetapowy flow URI.

HTTP i przeglądarka

Przykład HTML w v2/examples/html_uri_app ładuje dokument bindingów, renderuje formularze URI i woła backend Pythona przez POST /api/run.

Backend może wystawiać logi, ostatnie wywołania, narzędzia MCP i kartę A2A z tego samego registry, więc akcje frontendu używają tych samych nazw URI co backend.

gRPC

urirun.v2_grpc udostępnia mały interfejs RPC: listowanie tras, wywołania unary i strumieniowe. Zainstaluj opcjonalny zestaw zależności:

pip install "urirun[grpc] @ git+https://github.com/tellmesh/urirun.git@main#subdirectory=adapters/python"

v2/examples/multi_transport miesza workerów HTTP i gRPC, automatycznie generuje jedno registry z ich tras, wykrywa konflikty i uruchamia flow, którego kroki trafiają do różnych transportów.

MCP i A2A

Ponieważ bindingi v2 zawierają JSON Schema, registry można rzutować na:

Wykonanie nadal przechodzi przez tę samą bramkę polityki urirun.