0

I already have REST API (for System-to-System communication) which takes lot of time to process.

I want to have asynchronous processing. I see two options here:

  1. To make the API itself as asynchronous, where it returns a LOCATION header giving another URI to fetch result.

  2. To make the client asynchronous - using asynchronous HTTP Client or AsyncRestTemplate etc.

I was wondering what is better way in such scenarios, as both seems to solve the issue.

Kumar
  • 1,536
  • 2
  • 23
  • 33
  • first of all which tech stacks you are using? did you check which process are most expensive and why? did you consider anything for handling long running requests as back ground job for doing the heavy calculations in the background? in python we use celery for that mostly. – auvipy Dec 08 '22 at 13:52
  • @auvipy: I am on JAVA / Spring. We have some heavy computational task, which requires lot of effort to refactor (and may not result in much performance benefit)...so we want to look for asynchronous processing and very weighing option if we should make client asynchronous or make api itself asynchronous ... – Kumar Dec 08 '22 at 17:54
  • I think in that case you should try rabbitmq background task handling. https://roytuts.com/spring-boot-rabbitmq-work-queues-example/ – auvipy Dec 11 '22 at 05:12

2 Answers2

1

There are some pros and cons to each of the options you mentioned that you may want to consider when making a decision.

Asynchronous API

This approach has a lot of benefits, such as allowing the API to process requests in parallel and improving the overall performance and scalability of the system. However, this approach can also add some complexity to the API, as it requires the API to implement asynchronous processing and provide a mechanism for clients to fetch the result of a request.

Asynchronous client

This approach can provide a simpler and more straightforward solution, as it does not require any changes to the API itself. This approach can also improve the performance and scalability of the system, as it allows the client to process multiple requests in parallel and handle responses asynchronously. However, this approach may require the client to implement additional logic to handle asynchronous processing and fetching results, which can add some complexity to the client.

Summary

Making the API asynchronous can provide better performance and scalability, but may require more complex implementation, while making the client asynchronous can provide a simpler solution, but may not provide the same level of performance and scalability. You will need to weigh the pros and cons of each approach and decide which is best for your specific system based on your requirements and constraints.

stbychkov
  • 301
  • 2
  • 4
  • There's not enough here to make a good recommendation. They're all fine solutions, and services can also call each other. Any way to get the result back to the client is _generally probably fine_ unless you have specific constraints that you're not sharing. – Evert Dec 08 '22 at 02:47
  • @Evert: What kind of constraints you are looking? Can you please elaborate, so I can answer – Kumar Dec 08 '22 at 17:56
1

It depends on your specific use case and requirements.

If you have a lot of requests coming in from multiple clients, making the API asynchronous may be the best option as it allows you to scale better and process requests in parallel.

On the other hand, if your API is already built and you are just looking to improve performance of the requests, using an asynchronous client may be the best option as it will allow the requests to be sent in parallel and processed faster.

Hubert Jakubiak
  • 853
  • 8
  • 19