Apigee to create a reactive Rest API for continuously broadcasting chunks of data

Not applicable

We are trying to build a facade API to deliver a large amount of data to our client application for which we are not planning our client to wait for the processing and we deliver as soon as we get a chunk of data from our backend.

We are planning to build a spring webflux API to support reactive streaming API but can APIGEE be a facade layer here to which our client UI can listen continuously.

Please let me know if you can suggest any other approach also.

2 3 1,202
3 REPLIES 3

Sorry, I've been away and unable to respond.

I think when you say "reactive" you are referring to the implementation of the service that exposes the API. You're tlaking about internal libraries and code patterns.

That is irrelevant to APigee Edge.

Apigee Edge is a Layer 7 network proxy. Inbound it receives HTTP requests, and it then proxies those requests to another target, usually an HTTP target. It does not matter how that HTTP target is constructed internally.

I think there is something special about the interaction pattern between client and service in your case. But I'm not clear on it.

Maybe you could elaborate on that. The client sends X, the server responds with Y. Maybe there are additional details around that.

Skip the details about how, internally, your service code is constructed.

Not applicable

@Dino-at-Google In order to achieve a continous data flow from backend to UI where UI don't have to wait for an orchestration to complete, we are developing a spring based reactive service which will broadcast the data continuously asynchronously and UI will be working as webclient to receive this data.

I want to know if we can introduce APIGEE here which will be active as a receiver for spring service, providing security and sending the same data to webclient without breaking the service connection.

I guess "broadcast the data continuously asynchronously" implies websockets or http/2 ?

Apigee Edge does not currently support http/2 or websockets.

(Also: I still think your mention of Spring is irrelevant and potentially confusing. It should not (does not) matter what framework is used to implement either client or service)