Web反应式编程-从HTTP客户端的角度来看有什么优势? [英] Web Reactive Programming - What are the advantages from the HTTP client point of view?
问题描述
让我们假设控制器的以下两种情况会产生一些带有延迟的随机数:
Lets suppose these two scenarios of a controller that generates some random numbers with a delay:
1)响应式Spring 5响应式应用程序:
@GetMapping("/randomNumbers")
public Flux<Double> getReactiveRandomNumbers() {
return generateRandomNumbers(10, 500);
}
/**
* Non-blocking randon number generator
* @param amount - # of numbers to generate
* @param delay - delay between each number generation in milliseconds
* @return
*/
public Flux<Double> generateRandomNumbers(int amount, int delay){
return Flux.range(1, amount)
.delayMillis(delay)
.map(i -> Math.random());
}
2)具有DeferredResult的传统Spring MVC:
2) Traditional Spring MVC with DeferredResult:
@GetMapping("/randomNumbers")
public DeferredResult<Double[]> getReactiveRandomNumbers() {
DeferredResult<Double[]> dr = new DeferredResult<Double[]>();
CompletableFuture.supplyAsync(() -> {
return generateRandomNumbers(10, 500);
}).whenCompleteAsync((p1, p2) -> {
dr.setResult(p1);
});
return dr;
}
/**
* Blocking randon number generator
* @param amount - # of numbers to generate
* @param delay - delay between each number generation in milliseconds
* @return
*/
public Double[] generateRandomNumbers(int amount, int delay){
int generated = 0;
Double [] d = new Double[amount];
while(generated < amount){
try {
Thread.sleep(delay);
} catch (InterruptedException e) {}
d[generated] = Math.random();
generated++;
}
return d;
}
从HTTP客户端(浏览器，AJAX请求)的角度来看，这两种方案之间没有任何区别.我的意思是，客户端将等待所有结果发送完毕，直到提交完整响应后才进行处理.
From the perspective of a HTTP client (browser, AJAX request) there isn't any difference between both scenarios. I mean the client will wait until all the results are sent, and won't process them until the whole response is committed.
这就是说，尽管spring web react让我们认为它正在将结果发送回生产过程中，但实际上，这种情况不会发生，并且客户将无法处理所有结果数字已经生成.
That is to say, although spring web reactive makes us think that it's sending the results back as they are being produced, in reality it doesn't happen that way and the client won't be able to process the results until all the numbers have been generated.
使客户端完全反应的直接方法是使用WebSockets.
The straightforward way to make the client fully reactive would be to use WebSockets.
因此，除了很酷的东西(例如漂亮的语义，组合...)之外，考虑到浏览器的HTTP请求不是被动的，并且等效于使用传统的HTTP请求，使用Spring Web Reactive的意义何在? DeferredResult?
So, apart from the cool stuff (such as nice semantics, composition...), what is the point of using Spring Web Reactive considering that browser HTTP requests aren't reactive and are equivalent to using the traditional DeferredResult?
推荐答案
有区别，所以让我尝试对其进行分解.
There are differences so let me try to break it down.
对于DeferredResult<Double[]>返回值，显然必须先准备好数组，然后才能将该值写入响应.
For the DeferredResult<Double[]> return value clearly the array has to be prepared first before the value can be written to the response.
Spring Web Reactive会在Flux<Double>可用时写入每个单独的值.现在，从浏览器的角度来看，您可能看不到实际的差异，因为在收到完整的JSON数组之前，它不会给您提供完整的JSON数组.
Spring Web Reactive does write each individual value from a Flux<Double> as it becomes available. Now from a browser perspective you may not see an actual difference because it won't give you the full JSON array until it's received in its entirety.
这更多地是关于如何流式传输到浏览器的问题?例如，如果将"Accept: text/event-stream"添加为请求标头，则可以在浏览器中将每个double用作一个单独的事件.因此，服务器具有执行并有效执行此操作的能力.
This is more a question of how to stream into a browser? For example if you add "Accept: text/event-stream" as a request header you can then consume each double as an individual event in the browser. So the capability of the server to do it and do it efficiently is there.
这篇关于Web反应式编程-从HTTP客户端的角度来看有什么优势?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
