inadequate-blush

Accessing the Internal Route Matcher

bit of a weird one: i'm working on an application which uses llms + tools to hit some "endpoints" like

/api/v1/posts

/api/v1/posts

/api/v1/posts/1234

/api/v1/posts/1234

. i've put endpoints in quotes because, while they are currently implemented as endpoints, that is really just an abstraction i've found useful for language models - they are extremely reliable at generating well formed URLs. in reality, these endpoints need not be exposed to anyone other than the llm. right now the tool definition looks something like:

tool({
  name: "getDataFromAPI",
  schema: z.string().describe("... my formal spec of my 'api' routes ....",
  execute: (endpoint: string) => return fetch(endpoint).then(r => r.json) // error handling omitted.
})

tool({
  name: "getDataFromAPI",
  schema: z.string().describe("... my formal spec of my 'api' routes ....",
  execute: (endpoint: string) => return fetch(endpoint).then(r => r.json) // error handling omitted.
})

the issue here is the fetch. there is no reason perform a real fetch request to a real endpoint when the API itself is just a construct for the llm. in reality, it would be much more efficient to:

tool({
  name: "getDataFromAPI",
  schema: z.string().describe("... my formal spec of my 'api' routes ....",
  execute: (endpoint: string) => match(endpoint, {
    "/api/v1/posts": () => getPosts(),
    "/api/v1/posts/:id", ({id}) => getPostByID(id)
  })
})

tool({
  name: "getDataFromAPI",
  schema: z.string().describe("... my formal spec of my 'api' routes ....",
  execute: (endpoint: string) => match(endpoint, {
    "/api/v1/posts": () => getPosts(),
    "/api/v1/posts/:id", ({id}) => getPostByID(id)
  })
})

of couse, we need the

match

match

function. basically a router. i could:
1. build my own,
2. depend on some battle tested router, or better yet:
3. access the router built in to TSS

i don't know if #3 is possible! is it?

TanStack•12mo ago

inadequate-blush

Accessing the Internal Route Matcher

bit of a weird one: i'm working on an application which uses llms + tools to hit some "endpoints" like

/api/v1/posts

/api/v1/posts

/api/v1/posts/1234

/api/v1/posts/1234

tool({
  name: "getDataFromAPI",
  schema: z.string().describe("... my formal spec of my 'api' routes ....",
  execute: (endpoint: string) => return fetch(endpoint).then(r => r.json) // error handling omitted.
})

tool({
  name: "getDataFromAPI",
  schema: z.string().describe("... my formal spec of my 'api' routes ....",
  execute: (endpoint: string) => return fetch(endpoint).then(r => r.json) // error handling omitted.
})

the issue here is the fetch. there is no reason perform a real fetch request to a real endpoint when the API itself is just a construct for the llm. in reality, it would be much more efficient to:

tool({
  name: "getDataFromAPI",
  schema: z.string().describe("... my formal spec of my 'api' routes ....",
  execute: (endpoint: string) => match(endpoint, {
    "/api/v1/posts": () => getPosts(),
    "/api/v1/posts/:id", ({id}) => getPostByID(id)
  })
})

tool({
  name: "getDataFromAPI",
  schema: z.string().describe("... my formal spec of my 'api' routes ....",
  execute: (endpoint: string) => match(endpoint, {
    "/api/v1/posts": () => getPosts(),
    "/api/v1/posts/:id", ({id}) => getPostByID(id)
  })
})

of couse, we need the

match

match

function. basically a router. i could:
1. build my own,
2. depend on some battle tested router, or better yet:
3. access the router built in to TSS

i don't know if #3 is possible! is it?

Accessing the Internal Route Matcher

Similar Threads

Accessing the Internal Route Matcher

Similar Threads

Similar Threads

Similar Threads