It also helps to pass correlationId and traceabilityId and other configurable headers to the next service. It provides methods to get authorization tokens and automatically receives the client credentials token for scopes in API to API calls. Standalone Application/Mobile Application.Http2Client supports both HTTP 1.1 and HTTP 2.0 transparently depending on if the target server supports HTTP 2.0 and is used to call APIs from the following sources: If there are more users interested in this client, I will make it an independent module without depending on the Undertow core so that other people working on other platforms can use it without the extra Undertow core. Others may have concerns, but our argument is that the Undertow core is extremely small, and I don’t think it is an issue for other people to use it outside of light-4j frameworks. It will take a long time to build an independent HTTP 2Client without depending on Undertow, which is OK with us as our server is based on Undertow anyway.
I proposed the idea of implementing a generic HTTP Client to the Undertow community, but it wasn’t interested. Given the above situation, I decided to implement our own Http2Client based on what we have in Undertow. Everybody seems to want to wait for Java 11 to come out, but we cannot use it on production until it is ready. Some provided partial support, while most of them required you to put -Xbootclasspath with a specific version of the jar file per JDK version in the command line for it to work with Java 8. While looking for Java HTTP clients that supported HTTP 2.0, we were stuck as none could support it gracefully. Another big issue was the HTTP 2.0 support as light-4j frameworks support HTTP2 natively, and we want to take advantage of the client-side as well. It was also huge and slow compared to other modern HTTP clients. However, it was designed long ago and was hard to use because of its numerous configurations.
In the early days of light-4j, we had a client module based on Apache HttpClient and Apache HttpAsyncClient, which supported HTTP 1.1 and was very popular in the open-source community. An efficient HTTP client is crucial in a request/response style as the number of interactions between services is high, and extra latency can kill the entire application performance, causing the failure of a microservices application. The service-to-service communication can be done through a request/response style or messaging/event style in a microservices architecture.
0 kommentar(er)
