1

We are going to write a server side for high load application.

A client from browser makes a call, which will be processed for a long time - let's say 1-3 minutes (we call external services during processing, they may be asynchronic etc)

What is better - make a browser HTTP call wait all this time for an answer or return immediately and browser will make a polling? May be websocket?

Will the answer affect what type of framework should we use on server side - old good Spring MVC or something reactive like Spring Flux or Vert.x?

Pavel Bernshtam
  • 4,232
  • 8
  • 38
  • 62

1 Answers1

1

The question is very broad, but I'll try my best to address it shortly.

If your request is, as you say, 1-3 minutes long, you're much better off with polling. Otherwise, you'll have to extend HTTP timeouts. WebSockets is also an option, but it mainly depends on amount of clients you're dealing with, and how many service instances you're willing to have.

It doesn't matter that much what you're using on the backend. For short lived requests, something like Vert.x would be definitely better, but if you have those long 1m requests, you'll be using worker vertices anyway, meaning same old thread pool model.

Alexey Soshin
  • 16,718
  • 2
  • 31
  • 40
  • Thank you! Can you explain when websockets are preferable than polling? – Pavel Bernshtam Feb 24 '20 at 12:02
  • 1
    WebSockets provide you with near-realtime data. If you needed updates in terms of milliseconds, I would recommend using websockets. But since your entire request is 1m, the experience won't be affected much if you wait another 5s to update the user. – Alexey Soshin Feb 24 '20 at 14:26