Add Armeria as a reactive server and client [SPR-17270]

[spring-projects-issues]

Hyangtack Lee opened SPR-17270 and commented

Hello. This is Hyangtack from Armeria team.

We are developing Armeria which is a microservice server framework based on Netty. (https://github.com/line/armeria) 
Is there any chance that we can add Armeria into Spring framework as a reactive server and client?

If Armeria is added to Spring, we think that:

• Armeria can utilize Spring's powerful features which are necessary for building a web application, such as dependency injection, transaction management, AOP, etc.
• Spring can utilize powerful support for Apache Thrift and gRPC provided by Armeria, including the documentation service. (https://line.github.io/armeria/server-docservice.html)
• Both Spring REST services and Armeria RPC services can run on a single server port which supports HTTP/2 on both OpenSSL-based TLS and cleartext connections. The Armeria server also supports PROXY protocol which is interoperable with load balancers such as HAProxy and AWS ELB.

So we think that it would be useful for the developers who use both Spring and Armeria, including ourselves at LINE corporation.
Please check my pull request on Armeria repository, and let us know what you think. Thanks!

line/armeria#1326

 

---

Reference URL: line/armeria#1326

9 votes, 9 watchers

[spring-projects-issues]

Rossen Stoyanchev commented

Thanks for reaching out. Indeed it is useful to run WebFlux on Armeria and leverage its Thrift and gRPC support.

If we leave aside the Boot auto configuration, which would have to target Spring Boot repository, what remains as a potential target for the Spring Framework repository is very little. Running WebFlux on Armeria is comparable to running on Reactor Netty except each provides its own Reactive Streams layer. If we assume the reactive streams integration would always be in the Armeria repository, which makes the most sense in terms of ownership and maintenance, then the remaining adapter code to WebFlux is very thin and trivial.

You might say the same about the Reactor Netty adapter code, and reasonably ask why does that live in the Spring Framework? Reactor Netty is developed in close collaboration with the Spring Framework team, Spring's reactive support requires Reactor (reactor-core) on the classpath, we needed at least one integration for Netty, and Reactor Netty is the default server for WebFlux in Spring Boot. So there is a lot of synergy, co-ownership, and coordination between the two. 

I think it would make more sense for the WebFlux adapter code to be hosted in the Armeria repository. Armeria has other integrations with servers (Tomcat, Jetty) as far as I can see. The one for WebFlux is also very minimal. 

 

 

[spring-projects-issues]

Rossen Stoyanchev commented

One extra comment, I personally look forward to experimenting with this integration and aligning with the Armeria team wherever we find the opportunity. We can include something in the Spring Framework reference docs too so it can be found there. 

[spring-projects-issues]

Hyangtack Lee commented

Thanks for comments. I understood what you think from the maintainer's view. Also it would be thankful if Spring Framework documentation includes how to use Armeria with Spring Framework or at least providing a link to Armeria project web site.

By the way, do you have a plan to provide test suite for 3rd party server/client implementations? When I implemented Armeria server and client, it was painful that there was no way of using upstream's test suite except for hard-forking them. If Spring team provides an official test suite for the web server/client implementations, 3rd party implementations would be more stable and manageable.

[spring-projects-issues]

Rossen Stoyanchev commented

That's a fair point about a test suite. We don't have anything like that currently. I would say you probably don't need to worry too much about testing higher level functionality in WebFlux extensively. The most important thing is the ability to read and write through the request and response. For that the Reactive Streams TCK is probably one to try and incorporate.

[spring-projects-issues]

Trustin Lee commented

More specifically, we forked some of the JUnit test cases in Spring to test our implementations. It'd be nice if those test classes are provided as a public class with some extension points (e.g. specify a custom web server / client impl) in a published test JAR. To list some:

• WebClientIntegrationTests
• Subclasses of AbstractHttpHandlerIntegrationTests

We also have a plan to implement non-reactive server and client implementation for Spring, so it'd be great if non-reactive counterpart of the test classes are also provided in a published test JAR.

[spring-projects-issues]

Rossen Stoyanchev commented

The majority of those tests verify functionality at a higher level which should be independent of the server. It's true that we run with all supported servers, but practically over time those find issues in our code, and not in servers. I think you'd be better off handpicking a sampling of tests to cover a range of scenarios (e.g. GET, POST, SSE, etc) or just having your own. We could consider a TCK but I think a lot of it would come down to Reactive Streams semantics against request and response content.

For example one issue I've noticed is on the writing side, both client and server, there is no back pressure applied. As far as I can see this here will result in a request for Long.MAX_VALUE. I don't think we test specifically for that in our tests, but it's part of Reactive Streams semantics.

 

 

[spring-projects-issues]

Trustin Lee commented

Rossen Stoyanchev, thanks for your advice. As you suggested, we did not have to fork majority of the test cases in the upstream.

We are currently cleaning up our Armeria-based WebServer implementation which is expected to be merged soon. Would you mind taking a quick look at:

• A single page documentation that explains how to enable Armeria-based WebServer and WebClient

  • https://github.com/hyangtack/armeria/blob/feature/spring_web_server/site/src/sphinx/advanced-spring-webflux-integration.rst

• A minimal example project that shows how to switch to Armeria-based WebServer and WebClient

  • https://github.com/hyangtack/armeria/tree/feature/spring_web_server/examples/spring-boot-webflux

and letting us know if you have something to add or update. We'd be happy to accept your suggestions.

I believe our implementation will be useful to some Spring Webflux users who are seeking for:

• HTTP/2 support (including h2c)
• a way to run gRPC and Thrift services in the same port
• ... (I guess Hyangtack Lee mentioned all the benefits already in the issue description. ;))

[spring-projects-issues]

Rossen Stoyanchev commented

Thanks for the links! I submitted a few minor updates for consideration. Overall looks good. One thing that would be very useful to see either directly on that page, or on another page referenced from this one, is a summary of the benefits that you listed here, something like "Why Use Armeria with WebFlux?"

[spring-projects-issues]

Trustin Lee commented

I submitted a few minor updates for consideration.

Thanks for taking a look! Would you mind letting us know where you posted 'a few minor updates'?

summary of the benefits that you listed here, something like "Why Use Armeria with WebFlux?"

Agreed. Will update soon.

[spring-projects-issues]

Rossen Stoyanchev commented

I just hit edit on the above link and it submitted a PR against the that fork/branch.

[spring-projects-issues]

Trustin Lee commented

Oh, great. Would you mind signing the ICLA then? It's almost same with ASF ICLA - https://cla-assistant.io/line/armeria?pullRequest=1326