Tracking Request/Response for Cloud Foundry Calls

[Suyash08Oct]

trafficstars

Requirement: Passing cloud foundry user related data from the application with each cloud foundry requests and need to send the respective response headers back to the calling application.

For Example: For Creating a Service Key, the code flow will be

Application ----> Mono<Void> createServiceKey(CreateServiceKeyRequest request) ----> Mono<CreateServiceKeyResponse> requestCreateServiceKey ----> Mono<CreateServiceKeyResponse> create(CreateServiceKeyRequest request) ----> <T> Mono<T> post(Object requestPayload, Class<T> responseType, Function<UriComponentsBuilder, UriComponentsBuilder> uriTransformer) ----> Http Client (for HTTP Related Operations)

Is there any way from which we can track the Http Client Response Headers from the calling application.

[dmikusa]

Is there any way from which we can track the Http Client Response Headers from the calling application.

I don't believe there is a way to get the headers. The operations library is intentionally higher level, but even using the client directly, it does not expose the headers.

What information are you trying to retrieve from the headers?

[Suyash08Oct]

My application has multiple Cloud Foundry Users, which we select as a round robin fashion. If we can use the CF provided headers (X-Ratelimit-Limit, X-Ratelimit-Remaining, X-Ratelimit-Reset, X-Vcap-Request-Id), sending the headers in response to the application, we can use this headers for tracking each request and optimize our algorithm to utilize all the Cloud Foundry Users by distributing the load of cloud foundry calls.

[dmikusa]

Most (possibly all?) of the response objects that we have inherit from are based on https://github.com/cloudfoundry/cf-java-client/blob/main/cloudfoundry-client/src/main/java/org/cloudfoundry/client/v2/Resource.java. This wraps the general format of a CAPI response body exposing the entity and metadata. There are similar types for v3.

I don't think we are wrapping any header information into those request objects.

I don't think we want to expose a generic set of headers, but I could see us adding support for rate limiting or possibly the vcap request id, given that's a specific feature of CAPI.

There's https://github.com/cloudfoundry/cf-java-client/issues/960 which has a similar request around rate limiting. If that is of interest let me know, I will mark this as an enhancement request.

[Suyash08Oct]

Yes, It will be good, if we have support for rate limiting and vcap request id for tracking. For the time being, is there any possible way where we can use context of Mono, to hold the headers and pass the same to upstream data pipeline.

[Suyash08Oct]

Thanks for marking it as an enhancement. It will be an exciting opportunity for contributing to this enhancement. Please acknowledge if we can do so, and provide the guidelines for the same.

[dmikusa]

Yes, you're absolutely welcome to contribute a PR for this feature. We have Development instructions here. This will help with the basics like getting your dev environment set up and understanding a couple of the libraries we use.

Beyond that, we have v2 and v3 versions of the client. Most of the new feature work like this being done now is going into the v3 client, so I would suggest targeting v3 but it's up to you. We'd accept a PR for v2, if that's something you require. Just keep in mind that the CFF has deprecated v2. There is no timeline yet for when it'll be removed, but at some point, it'll be removed so support for rate limits will need to work for v3 as well.

For the v2 API, you're probably looking at starting with changes to Resource. Resource is the basis for all response data. I haven't thought it through, but it seems like adding a property there that's of type RateLimits or something like that would be a way to expose that information to users without too much change.

Something similar might work for the Resource class in the v3 API as well.

Don't feel like you have to approach the solution that way though. I'm just trying to provide some suggestions to get you started. I'd be open to other implementations.

If you have questions or want to discuss more before you start implementing, feel free to ask here or on the CFF Slack. Thanks!