In light of #64 caused by API requests processing - I think for automation that will be much better to have some sort of one channel of communicating, so jenkins will not need to constantly establish multiple new connections to send new application or track the status by polling. This will require some advanced GRPC systems, but in theory worth a shot.
We will for sure need to save the original API and keep it priority for easy access and small workloads, but also to have an automated way to generate GRPC specs for high-load systems and save the CPU/MEM resources of Fish for something more useful..
Expected Behaviour
One connection to grpc should give all the interfaces available through the API with an addition of notifying the client on listened items changes.
Actual Behaviour
It's required to establish new connection for each particular request and waste time & resources on ensuring the connected client have the permissions to connect.
In light of #64 caused by API requests processing - I think for automation that will be much better to have some sort of one channel of communicating, so jenkins will not need to constantly establish multiple new connections to send new application or track the status by polling. This will require some advanced GRPC systems, but in theory worth a shot.
We will for sure need to save the original API and keep it priority for easy access and small workloads, but also to have an automated way to generate GRPC specs for high-load systems and save the CPU/MEM resources of Fish for something more useful..
Expected Behaviour
One connection to grpc should give all the interfaces available through the API with an addition of notifying the client on listened items changes.
Actual Behaviour
It's required to establish new connection for each particular request and waste time & resources on ensuring the connected client have the permissions to connect.