3 ms·

As an end user of APIs, agents sound like a good idea. As a creator of APIs, agents seem scary from an optimization/caching point of view. I’d rather serve th

As an end user of APIs, agents sound like a good idea. As a creator of APIs, agents seem scary from an optimization/caching point of view. I’d rather serve the same request 10,000 (which could be cached) than have 1,000 different agents making requests (which would be hard to cache).

carry_bit 6y ago
Is it really much different? In the data flow you're just conceptually moving the network from being after the agent to being before the agent. You can still have the cache in the same spot, it's just that the agent is hitting it directly now instead of over the network.
- tux1968 6y ago
  As far as the actual data access goes, it is equivalent, but you can't cache the agent process itself. So every agent is potentially repeating work centrally, rather than spreading that load out to each client. That may still be a worthwhile win, but it is a new burden on the data centre.
  - AriaMinaei 6y ago
    Maybe agents could create rest endpoints of their own with its own cache? Edit: Just wrote some pseudo code: https://gist.github.com/AriaMinaei/69e1a9166e7ffbd61e7f6709d7a819b8 https://gist.github.com/AriaMinaei/69e1a9166e7ffbd61e7f6709d...
nine_k 6y ago
Agents should use a limited, non-Turing-complete model of evaluation. They could combine API calls locally and run simple FSMs which are easy to formally check for e.g. absence if loops. This could save round-trips without needing to sacrifice general orthogonal APIs. Imagine that you could give an app server a formula to combine several API calls, much like you give an SQL server a formula to join and filter tables. Also, you can easily cache agents by calculating a hash of their source, and call them repeatedly without resending their bodies, much like "prepared statements" work in SQL databases.
- AriaMinaei 6y ago
  I agree. Though not sure about the non-Turing-complete-ness. How about each agent has a budget. Agents that blow the budget get dropped. Like this: https://gist.github.com/AriaMinaei/69e1a9166e7ffbd61e7f6709d7a819b8 https://gist.github.com/AriaMinaei/69e1a9166e7ffbd61e7f6709d...
- chabad360 6y ago
  You sound like your describing (to an extent) GraphQL
- rumanator 6y ago
  > Agents should use a limited, non-Turing-complete model of evaluation. That doesn't solve any of the caching worries. If it's not a resource then it's not cacheable. > This could save round-trips without needing to sacrifice general orthogonal APIs. Since the inception of HTTP2, a relative large number of requests of cached resources easily beat a relatively small number of requests that are computationally demanding or hit a database.

carry_bit 6y ago

Is it really much different? In the data flow you're just conceptually moving the network from being after the agent to being before the agent. You can still have the cache in the same spot, it's just that the agent is hitting it directly now instead of over the network.

tux1968 6y ago
As far as the actual data access goes, it is equivalent, but you can't cache the agent process itself. So every agent is potentially repeating work centrally, rather than spreading that load out to each client. That may still be a worthwhile win, but it is a new burden on the data centre.
- AriaMinaei 6y ago
  Maybe agents could create rest endpoints of their own with its own cache? Edit: Just wrote some pseudo code: https://gist.github.com/AriaMinaei/69e1a9166e7ffbd61e7f6709d7a819b8 https://gist.github.com/AriaMinaei/69e1a9166e7ffbd61e7f6709d...

nine_k 6y ago

Agents should use a limited, non-Turing-complete model of evaluation. They could combine API calls locally and run simple FSMs which are easy to formally check for e.g. absence if loops. This could save round-trips without needing to sacrifice general orthogonal APIs. Imagine that you could give an app server a formula to combine several API calls, much like you give an SQL server a formula to join and filter tables. Also, you can easily cache agents by calculating a hash of their source, and call them repeatedly without resending their bodies, much like "prepared statements" work in SQL databases.

AriaMinaei 6y ago
I agree. Though not sure about the non-Turing-complete-ness. How about each agent has a budget. Agents that blow the budget get dropped. Like this: https://gist.github.com/AriaMinaei/69e1a9166e7ffbd61e7f6709d7a819b8 https://gist.github.com/AriaMinaei/69e1a9166e7ffbd61e7f6709d...
chabad360 6y ago
You sound like your describing (to an extent) GraphQL
rumanator 6y ago
> Agents should use a limited, non-Turing-complete model of evaluation. That doesn't solve any of the caching worries. If it's not a resource then it's not cacheable. > This could save round-trips without needing to sacrifice general orthogonal APIs. Since the inception of HTTP2, a relative large number of requests of cached resources easily beat a relatively small number of requests that are computationally demanding or hit a database.