Can spring cloud gateway create issue with blocking/synchronous micro-services?

[Puspender Tanwar]

From the docs  https://docs.spring.io/spring-cloud-gateway/docs/current/reference/html/#gateway-starter

Spring Cloud Gateway is built on Spring Boot 2.x, Spring WebFlux, and Project Reactor. As a consequence, many of the familiar synchronous libraries (Spring Data and Spring Security, for example) and patterns you know may not apply when you use Spring Cloud Gateway

I have two services which are blocking/synchronous in nature, but the Spring Cloud Gateway is on non-blocking model. So, should I use Spring Cloud Gateway as an API gateway?

[Tim Holloway]

Anything that goes through an HTTP(S) interface must be non-blocking. The HTTP protocol is not a continuous-connection protocol, but rather one that connects, submits data, gets a single response returned as quickly as possible, then closes the connection until it makes the next request (if any). That's a basic characteristic of the Internet and not a Java or Spring - or cloud - limitation.

Some might argue that anything that can block shouldn't be called "micro", for that matter, but essentially if you want "blocking", you'll have to fake it the same way that AJAX fakes a "continuous" updating connection for HTTP.

[Puspender Tanwar]

Tim Holloway wrote:connects, submits data, gets a single response returned as quickly as possible, then closes the connection until it makes the next request (if any). That's a basic characteristic of the Internet and not a Java or Spring - or cloud - limitation.

Doesn't the reactive programming solve this? In reactive model, a thread is assigned to a request and if that takes some time, that thread can be used by some other connection request and once the response is ready that is sent back using some thread.

Why I am concerned? I read it somewhere that we shouldn't mix reactive and blocking architecture.

[Tim Holloway]

I never really studied the Reactive Model as such, so I can't say definitively, but from what I can see, that's exactly what's wrong with the standard Node sqlite3 module. It posts a request, returns, and lets Some Other Thread deal with the post-call behavior.

Except that the better-sqlite3 people claim to have done a study indicating that while that approach certainly makes code more complex, it doesn't provide any worthwhile boost in actual performance. SQLite in particular is almost always invoked as a local database, so there's not even network latency to slow it down.