Usecase
A setup or hosting situation or service might need additional settings in HttpClientInterface $httpClient generated in the Bridge createProvider factory. The bridge usually creates one for itself if not given as a parameter. But some setups might need an additional proxy configuration, SOCKS5 configuration, additional headers (load balancing/routing/tracking etc) or timeouts. This would be solved by injecting a pre-configured HttpClientInterface $httpClient.
It can only been done here, as Symfony AI propagates the here generated/injected httpClient to all models, each hold their own reference to this $httpClient.
My concrete usecase is that the connection_timeout parameter is fixed to 60 second, and that is not enough for lets say open-ai image generation.
Another usecase could be with testing in order to mock an HTTP request and answer to prevent connections to the AI Provider Platforms.
Possible Solution
Symfony way
in a pure Symfony application one would probably register a listener to the Symfony\AI\Platform\Event\InvocationEvent which is dispatched during the Provider->invoke method as a last chance before sending the request to the ai-platform (Symfony\AI\Platform\Provider:: Line 94-95). Here you would have access to the $httpClient object.
But for that to work the Provider would need to be created with a Symfony\Contracts\EventDispatcher\EventDispatcherInterface compatible EventDispatcher which could be the TYPO3 EventDispatcherAdapter as far as I can see? But this would have to be implemented and injected in (latest main branch) B13\Aim\Provider\SymfonyAi\SymfonyAiPlatformAdapter::buildFactoryArguments
Pros
- Almost no dependency in b13/aim
- Reuse existing infrastructure
- per model/task settings possible
Cons
- maybe sideeffects because a for now inert feature inside symfony/ai is active by giving an event dispatcher?
- event registration might be different?
- ?
Alternative : a new TYPO3 Event in SymfonyAiPlatformAdapter::buildFactoryArguments
An alternative would be to have our own TYPO3 Event dispatched in SymfonyAiPlatformAdapter::buildFactoryArguments to further modify the argument list given to the provider factory
Pros
- TYPO3 pure solution
- more global approach, per platform solution instead of per model solution
Cons
- less granular
- more API to maintain on b13/aim part?
Alternative 2: make the $httpClient an option in B13\Aim\Domain\Model\ProviderConfiguration
If B13\Aim\Domain\Model\ProviderConfiguration would have a Parameter like
public ?Symfony\Contracts\HttpClient\ClientInterface $httpClient = null;
which would then be injected as the $httpClient parameter in SymfonyAiPlatformAdapter::buildFactoryArguments or SymfonyAiPlatformAdapter::getPlatform.
Then the $httpClient could be modified with an AiMiddleWare (B13\Aim\Middleware\AiMiddlewareInterface) where the ProviderConfiguration is available as a process parameter.
Pros
- probably the least intrusive option
- At least a per task (image generation, text generation) granularity
- maybe easier to use?
Cons
- A parameter that is not otherwise used in the class.
- Another getter/setter if public is not desired
Usecase
A setup or hosting situation or service might need additional settings in
HttpClientInterface $httpClientgenerated in the Bridge createProvider factory. The bridge usually creates one for itself if not given as a parameter. But some setups might need an additional proxy configuration, SOCKS5 configuration, additional headers (load balancing/routing/tracking etc) or timeouts. This would be solved by injecting a pre-configuredHttpClientInterface $httpClient.It can only been done here, as Symfony AI propagates the here generated/injected httpClient to all models, each hold their own reference to this $httpClient.
My concrete usecase is that the connection_timeout parameter is fixed to 60 second, and that is not enough for lets say open-ai image generation.
Another usecase could be with testing in order to mock an HTTP request and answer to prevent connections to the AI Provider Platforms.
Possible Solution
Symfony way
in a pure Symfony application one would probably register a listener to the
Symfony\AI\Platform\Event\InvocationEventwhich is dispatched during the Provider->invoke method as a last chance before sending the request to the ai-platform (Symfony\AI\Platform\Provider::Line 94-95). Here you would have access to the $httpClient object.But for that to work the Provider would need to be created with a
Symfony\Contracts\EventDispatcher\EventDispatcherInterfacecompatible EventDispatcher which could be the TYPO3 EventDispatcherAdapter as far as I can see? But this would have to be implemented and injected in (latest main branch)B13\Aim\Provider\SymfonyAi\SymfonyAiPlatformAdapter::buildFactoryArgumentsPros
Cons
Alternative : a new TYPO3 Event in SymfonyAiPlatformAdapter::buildFactoryArguments
An alternative would be to have our own TYPO3 Event dispatched in
SymfonyAiPlatformAdapter::buildFactoryArgumentsto further modify the argument list given to the provider factoryPros
Cons
Alternative 2: make the $httpClient an option in B13\Aim\Domain\Model\ProviderConfiguration
If
B13\Aim\Domain\Model\ProviderConfigurationwould have a Parameter likewhich would then be injected as the $httpClient parameter in
SymfonyAiPlatformAdapter::buildFactoryArgumentsorSymfonyAiPlatformAdapter::getPlatform.Then the $httpClient could be modified with an AiMiddleWare (B13\Aim\Middleware\AiMiddlewareInterface) where the ProviderConfiguration is available as a process parameter.
Pros
Cons