I want to standup an endpoint /foo which is a synchronous endpoint for clients but the response is dependent on a callback /foo_callback being called on the app as a result of the request to the synchronous endpoint.
to elaborate the workflow:
Flow diagram
I havent decided on a technology to use so ideally would look for a recommendation.
High level what I am thinking of is starting an async thread in the request handler and check for an update on a singleton map to see if the server has responded but I am wondering if there is a better way
I dont have control over the client and cannot really use websocket or long polling.
Related
For the last week I've been researching a lot on the microservice architecture pattern and its requirements and constraints.
The majority of ressources suggest to use event buses/message brokers (asynchronous communication) to communicate between microservices rather than using REST API endpoints.
Synchronous calling would result in a higher response time and may cause cascading failure in case of a particular microservice failing in the chain.
Question:
Let's say the user requests a particular functionality or page on a website/mobile app which then needs to fetch data from multiple microservices and use theire respective functionalities to provide the desired outcome. But to achieve the desired outcome (response to client) ALL the services need to do their work before the backend sends the response back to the client (website/mobile app).
But if we use asynchronous service requests - which means the calling service doesnt wait for a response and would send its own response back to the client without getting the data from the asynchronously called service - the outcome might not be complete if an asychronously called service doesnt respond in time (service is unavailable or network issues). This would mean that the backend will send an incomplete response back to the client which is not acceptable.
How can I deal with this issue or did I get the concept wrong?
I'm thankful for every answer
If it's absolutely essential that a request gets a full response (i.e. that the request is synchronous), that's a strong argument in favor of the service stitching together synchronous requests and responses (and potentially needing to handle rollback in cases of partial success etc.).
Many requests don't fall into that pattern, though. For instance, a response might well be interpretable as "we've received your request and the operation will be performed. You can track the progress of your operation by using this request ID"; such an approach fits well with asynchronous messaging.
Let's imagine there is a server, that when receives a request with a car model queries all known car dealers looking for the cheapest one and responds back with the price (using whatever protocol). This actions takes a while.
In a casual blocking request/response server model, I do
request = "audi a8" // prepare a request and one line after have the response
response = server.findCheapestCar(request) // takes 20 seconds
I don't want to block my client main thread for 20 seconds, so would rather want it to be executed asynchronously. My understanding for something being asynchronous is that I can pass some sort of an object to it and carry one with my work. Once the server is ready with the response it will notify the object I passed -> Casual callback pattern.
This approach would require library match - both client ad the server need to know the object. But I want my asynchronous server built on Netty to be able to handle requests from various clients (C++/Python and others).
Where is the asynchronousness of netty coming from? What do I need on the client side to benefit from the asynchronousness?
Where is the asynchronousness of netty coming from?
Netty adopted the principle of eventloops which you may known from a language like JavaScript. This allows netty to work fully asynchronous. (For more information about eventloops and the basic underlying principle I would recommend this video about the evenloop in JavaScript)
What do I need on the client side to benefit from the asynchronousness?
Client sends request (containing payload and request id = clientside incrementing integer)
Server process the request for 50sec
Server sends response (containing the payload and the same request id the client send in his request)
Client receives the response and looks up the request id (If the client is able to find the request id and its underlying callback it will invoke it)
Hope that helped
I've been reading about microservices, and have found a lot of interesting advice in Jonas Bonér's Reactive Microservices Architecture (available to download free here). He emphasises the need for asynchronous communication between miroservices, but says that APIs for external clients sometimes need to be synchronous (often REST).
I've been trying to think how asynchronous response messages sent back from microservices should best be routed back to the waiting client. To me the most obvious way would be to record something like a request id in all messages sent when processing the request, and then copy this id into response messages sent by the services. The public API would block when processing the request, collecting all expected response messages which have the matching id, before finally sending the response to the client.
Am I on the right lines here? Are there better approaches? Do any frameworks take the work of doing this routing away from the developer (I'm looking at Spring Cloud Streams etc, but others would be interesting too)?
He emphasises the need for asynchronous communication between
miroservices, but says that APIs for external clients sometimes need
to be synchronous (often REST).
When dealing with client - backend communications you can have a couple of types of operations and they should be handled seperetly (look at the idea of CQS):
State changing operations - they should be one way fire and forget using messaging (it can be the client calling an HTTP API and the api dispatching the message)
read operations: synchronous (request response) operations (using an HTTP API) and this is does not involve any messaging what so ever
Does that make sense?
How can i implement an asynchronous callback scenario in Apigee.
For example i need to call a host and the host may take some time to process response. Once the response is ready that needs to be delivered to the caller/client.
Thanks in Advance
Regards
Can not claim that it is a standard way of doing this, however here is a design:
Assumption: The target host must support registering a call back URL.
When the client calls Apigee proxy, Apigee proxy in the middle can generate a unique callback URL and send to the target as a parameter when making the API request. In the meantime it would have to block the client ( and start polling an internal storage).
The callback URL would be itself be a proxy in Apigee that receives the response from the target side and then updates an entry in Apigee persistence store, which is being polled by the first proxy.
If the callback happens within say x seconds, then the apigee proxy can send the response back to the client. If it does not happen within that time than it can send back some error.
To implement you can use Key Value Map or Caching policy in apigee for the transient persistence store. And for blocking the client and polling the persistence store use java or javascript policies
Take a look at https://github.com/apigee/api-platform-samples/tree/master/sample-proxies/async-callout and see if that helps. This sample makes the requests to the target, stores the response handles in the JS "session", goes away to do other things, and then retrieves the handles from the "session" and checks the responses.
I need to send a asynchronous message to client from my CXF (JAX WS) webservice layer...
How client would be capable of receiving it?What steps need to be taken care to achieve this?Is there a sample tutorial available?
You have two options to achieve asynchronous calls from client with CXF.
You can poll the service for response
You can define a callback which will be executed when the server's job is done
Each solution has pros and cons, so choose according to your needs.
The polling gives you a Response object and you can test if the call is complete on it by response.isDone(). (if not, wait some time, then send another request)
The callback gives you a Future object which wraps the call, you can define an AsyncHandler for instance when you call the service to define what will be run when the process is finished.
From the server side, you should take a look at WS-Addressing (to define a replyTo endpoint for callback if needed) and WS-POLICY: http://cxf.apache.org/docs/ws-addressing.html
Note that if you need to use callbacks (it seems so), you will have to define a CXF client on the client side to enable WS-addressing (on the cxf bus).