The (somewhat) new reactive API to Quarkus is awesome, but it introduces some complexity when writing code (much like in async code in JavaScript in my opinion).
How is it integrating with metrics/tracing/jwt APIs ? or anything that is passed by thread context?
Thnx
The integration is managed for you. Tracing and JWT are handle using context propagation. Metrics works flawlessly. Please report an issue if you see limitations or bugs.
Related
Spring boot 2.1.5
Project Reactor 3.2.9
I am setting up a bunch of rest reactive APIs using the above-mentioned frameworks and I am running into an annoying problem with MDC (mapped diagnostic context). My applications are in JAVA.
MDC relies on thread locals to store the current query's mapped context to put in the logs. That system, obviously, is not perfect and contradicts the reactive pattern since the different steps of your execution will be executed through different threads.
I have run into the same problem with the Play Reactive framework but found a workaround there by copying the mapped context transparently from one actor to another.
For spring and reactor, I could not find a satisfying solution yet.
Some random examples found on the internet:
First - It works but forces you to use a bunch of utility methods
Same thing
Second - It tries to copy the context during the onNext publisher event but seems to lose some features on the way of doing that. The signal context, for example, is lost.
I am in need of a proper solution to deal with this:
A library which would make the link between MDC and reactor?
A way to tweak reactor/spring to achieve it transparently?
Any advice?
"I could not find a satisfying solution yet."
Working with contexts is the only solution for the moment. Since as you said threadlocals goes against everything that has to do with reactive programming. Using thread local as a storage point during a request is a resource heavy way of solving things and in my opinion poor design. Unless logging frameworks themselves come up with a better solution to the problem we developers must pass the data through the context to accommodate for the logging frameworks blocking nature.
Reactive programming is a paradigm shift in the programming world. Other things like database drivers, that use threadlocal to rollback transactions are also in big trouble. the JDBC database driver spec is defined as blocking in nature, and atm. there has been attempts by spring and the R2DBC project to define a new JDBC driver spec that is inherently non/blocking. This means that all vendors must rewrite ther database driver implementations from scratch.
Reactive program is so new that lots of libraries need to rewrite entire codebases. The logging frameworks as we know it needs to be rewritten from the ground up which is a huge task. And the context in reactive is actually something that should not even be in reactive programming, it was implemented just to accommodate for MDC problems.
It's actually a lot of overhead needing to pass data from thread to thread.
So what can we do?
push on logging frameworks, and/or help logging frameworks to rewrite their codebase
Accept that there is no "tweak" that will magically fix this
use the context and the way suggested in the blogposts
Project reactor context
My application is heavily relying on asynchronous web-services.
It is built with spring boot 1.5.x, which allows me to utilize standard Java 8 CompletableFuture<T> in order to produce deferred async responses. For more info see
https://nickebbitt.github.io/blog/2017/03/22/async-web-service-using-completable-future
Spring boot 2.0.x now comes with the starter pack that can utilize reactive paradigm. Spring WebFlux is the framework, which is implementing reactive HTTP.
Since I have my API implemented as described in the first paragraph, will I gain much by redoing my services to use non-blocking reactive approach? In a nutshell, I'll have non-blocking API as well, right?
Is there an example how to convert async API that is based on CompletableFuture<T> to Mono<T>\Flux<T>?
I was thinking to get rid of servlet-based server altogether (Jetty in my case) and go with Netty + Reactor.
Needless to say that I am new to the whole reactive paradigm.
I would like to hear your opinions.
I have two things to say:
Q: Is there an example how to convert async API that is based on CompletableFuture to Mono\Flux?
A:
1) You have to configure endpoint in a bit different way https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html
2) CompletableFuture to Mono\Flux example: Mono.fromFuture(...)
As for the question: "will I gain much by redoing my services to use non-blocking reactive approach". The general answer is provided in the documentation: https://docs.spring.io/spring-framework/docs/current/reference/html/web-reactive.html#webflux-performance .. and it is no.
Performance has many characteristics and meanings. Reactive and non-blocking generally do not make applications run faster. They can, in some cases, (for example, if using the WebClient to run remote calls in parallel). On the whole, it requires more work to do things the non-blocking way and that can slightly increase the required processing time.
The key expected benefit of reactive and non-blocking is the ability to scale with a small, fixed number of threads and less memory. That makes applications more resilient under load, because they scale in a more predictable way. In order to observe those benefits, however, you need to have some latency (including a mix of slow and unpredictable network I/O). That is where the reactive stack begins to show its strengths, and the differences can be dramatic.
This is general answer, but the specifics will depend and you must measure and see. I would start by recreating a simple part of the application and checking the performance of both in an isolated environment.
I'm looking at Spring REST Docs and wondering if it has the ability to interrogate #RestController methods to produce basic documentation describing a Rest API (methods, http method, parameters, response type)? I believe Springfox Spring/Swagger does that, and would be easier than having to write a test to get that basic info/documentation.
Also, since I don't want to run integration tests in a Production environment, is the Spring RestDocs approach to run your integration tests in a Test environment and then copy the generated docs/snippets into the war so it can be viewed in a Prod environment?
I'm looking at Spring REST Docs and wondering if it has the ability to interrogate #RestController methods to produce basic documentation describing a Rest API
Spring REST Docs is test-driven and deliberately doesn't take the approach of introspecting #RestController methods. You REST API documentation is describing HTTP requests and responses. By being test-driven and working with real or mocked HTTP requests and responses, REST Docs ensures that what you're documenting is what users of your API will be dealing with.
The problem with introspecting #RestController methods is that it's only one small piece of the puzzle. When an HTTP request is received it passes through filters, interceptors, HTTP message conversion etc before it reaches your controller. The same is true in reverse when a response is being sent. Without a complete understanding of everything that happens before your controller's called and everything that happens after your controller returns, the documentation is at risk of being inaccurate.
is the Spring RestDocs approach to run your integration tests in a Test environment and then copy the generated docs/snippets into the war so it can be viewed in a Prod environment
Correct. The documentation is generated once at build time and then typically served as static files from your application. Details of how to do this with Spring Boot are included in the documentation.
This approach has the advantage that none of the code that's involved in creating the documentation is running in production. That reduces your application's footprint, and avoids the possibility of the code that's generating the documentation from causing a problem in production. I believe you can take a similar approach with code-first Swagger tools but, in my experience, it's unusual for people to do so.
Swagger is best choice for me. You cannot do make docs with Spring Rest Docs without integration tests. It's good article reviews rest tools
I am currently studying Spring.
While reading a Spring book, I met a part regarding Event.
By using context.publishEvent(..), I could trigger the event.
But I don't know what It's exactly for.
I can use other Method instead of using complicated publishEvent.
Please, tell me. thank you.
Spring Events are used to implement publish-subscribe model (or observer pattern) where two not-related parts of code must be somehow connected.
Think of the analogy of web applications where servlet container creates http sessions and your code is informed about this using javax.servlet.http.HttpSessionListener.
Spring uses this mechanism internally. It's much more visible in Spring Security where several parts of the code are informed about e.g., successfull authentication.
I googled but couldn't find any answer.
I am planning to use GWT. I want to know if I can use spring in my GWT code to use the dependency injection framework? I am not talking about GWT gui interaction with backend spring app.
The reason I am asking is the GWT code gets compiled to JavaScript and this is what gets executed in browser. If I am using spring code in that, then would it work or for that matter any other library like log4j, etc.?
Or the GUI code have to be pure GWT API only?
For example,
public class MyTable {
private Button myButton;
#Autowired
public MyTable(Button aMyButton) {
myButton = aMyButton;
}
}
Guice is supported on GWT using GIN. For Spring-like DI with GWT, check out GWT Toolbox or Rocket GWT.
I believe GIN is a more natural choice for GWT. Not because it's also made by Google, but because using XML for GWT configuration makes absolutely no sense. Everything gets statically compiled into JavaScript so there is no need for externalized configuration. Keep your refactoring tools happy; go for GIN.
To answer your other question, you will not find many SE frameworks that work on GWT. First and foremost, it has no support for reflection or bytecode manipulation (everything is JavaScript), which immediately rules out a lot of frameworks. Log4j, on the other hand, doesn't make sense because there is no file system accessible on the client side, but there are libraries available that do things differently.
The Spring libraries for GWT mentioned above are basically a rewrite of the Spring for GWT. They do not share any code with Spring simply because they can't. Those frameworks work by generating code ("factories") that wire up your components as if you were doing DI manually.
This is also how GIN works, it generates Java factories for your classes, and GWT compiles it into optimized JavaScript (meaning little performance overhead). GIN does use Guice behind the scenes though, to validate configuration at compile time and to inspect modules.
No, you won't be able to do that. The DI logic applies at runtime on the server side, and the GWT code is entirely client-side.
I thought it would be simpler to just create a Spring Controller that invoked the doPost method of the GWT RemoteServlet. A sample is provided here. I know this is a little round about. But this shields you from changes to the GWT implementation if any.. Hope it helps.
I wonder if Guice (the Google DI framework) is supported by GWT?
This might be an alternative.
You can implement a Servlet Service in the server side that retrive objects from a Spring ApplicationContext, rendering to JSon Objects (I did it with http://json-lib.sourceforge.net/apidocs/net/sf/json/JSONSerializer.html) by example.
Then you can have a Singleton Facade Service that make the request from the GWT-client side to our Servlet Service.
In this way you can get a runtime depency injection in the GWT-client side .
Spring ME is capable of helping you out here. Although I partly agree with some of the previous responses, it's nice to have the same programming (and plumbing) paradigm across your client and server code.