back
60 comments
Not that speed matters a lot, but it seems they managed to create a new server that is nearly as fast as the fastest C++ server on the techempower benchmarks (https://www.techempower.com/benchmarks/#section=data-r11&hw=...):

  *The low-level HTTP API provides access to the extremely fast Rapidoid HTTP 
  server implemented from scratch on top of Java NIO.*
Thats quite an achievement, considering that Netty is very well optimized. Maybe the off-heap output buffer gives it that edge?
Hi, I am the author of Rapidoid, thanks!

The performance optimization is based on: - using off-heap input and output buffers, - minimizing the number of objects that are created when parsing the input and generating the output, - using object pools to reuse the objects that must be created, - using thread-local helper data structures on the I/O threads to avoid synchronization and object instantiation.

What happens when you have a long database query running? Is it async (which is a bit impossible with JDBC) but does it block one of the threads in worker pool?
Thanks for the explanation! So it looks your efforts were mainly focused on reducing GC pressure - makes sense with those throughput numbers.
Too bad they didnt use DSL JSON instead of Jackson for JSON test. They would probably edge top C ones then.
What's DSL JSON?
dsl-json looks like an interesting tool. " DSL compiler requires Mono/.NET, but only during compilation. There is no runtime Mono/.NET dependency, only JVM. "
>Maybe the off-heap output buffer gives it that edge?

Is this because it allows the GC to be avoided, or because it allows value types to be emulated?

Just goes to show that a lot of the "slowness" in Java, et al, comes down to implementation details.
How the hell did they manage to do this?
How did they manage to write a fast optimized web server?

Lots of people have done so, if you have the skills and determination. It also helps if you focus on that, instead of completeness, like Netty probably does.

By not doing much else?
What do you mean by "not doing much else"? I take netty as benchmark when comes to Java and this is MUCH faster.
Indeed.

(Netty is well-optimized, but quite bloated as well).

Neat!

Rapidoid reminds me a little bit the Spark Framework (not Apache Spark, very unlucky name, though) which I use for fast prototyping and services.

http://sparkjava.com/

Also :

http://jooby.org/

http://www.ninjaframework.org/

But the leader of the recent Java web frameworks really seem to be Vert.x ( http://vertx.io/ ) which I have started to use recently and like a lot so far.

Which is not that surprising since Vert.x is more than just a web framework. It also let's you build distributed applications and to scale your web app horizontally.
And there are others like Ratpack.io, Vert.x and JFry
This looks awesome! I used to use Spark for quick Java web apps, but I will (probably) try Rapidoid next time. That said, I have been using mostly Sinatra (Ruby) and Yesod (Haskell) recently but Rapidoid looks like a winner for Java-land.

I am surprised that I hadn't heard of Rapidoid before. +1 to HN

Ha, I read "Javascript" at first. I guess my brain has a pretty strong pattern for "New web framework for X" at this point
On another note, JAX-RS (a Java API for RESTful API's) is also fairly no-bullshit. It is also mature by now, and is supported by about a dozen implementations, including Jersey, WebLogic and JBoss.
Too bad it doesn't have swagger integration (yet).

Love the easy, clean API - it's great for a reasonably sized project.

Thanks, I created an issue for Swagger integration: https://github.com/rapidoid/rapidoid/issues/39
Would be interesting to try it in Scala
Looks nice, reminds me of Jersey with the annotations but seems to offer more functionality. Good work!
Thanks! :)
The performance and elegance of this is breathtaking but I couldn't find if it has hot reloading built in.

If you have to recompile every time you change something, you're going to have a baaad time.

Hot reloading is not currently available, but it is almost finished. I added https://github.com/rapidoid/rapidoid/issues/38
Interesting framework! looking for a side project just to try it.

Github link https://github.com/rapidoid/rapidoid

Thanks, Fabio! :)
Excellent work. Author truly deserves a lot of credit.
Thanks a lot!
Looks cool. But how do you execute one of those one-liners?
Thanks! You can try adding the one-liners in your "main" method. (You will need Java 8 and rapidoid-http-fast added as dependency).
Great - Got it to work. This should be documented on your site.

You also forgot to mention what I need to import in order to have the "On" object.

Maybe you can include something like this template on your getting started page.

  import org.rapidoid.http.fast.*;
  // wget https://repo.maven.apache.org/maven2/org/rapidoid/rapidoid-http-fast/5.0.7/rapidoid-http-fast-5.0.7.jar
  public class App 
  {
    public static void main (String[] args)
    {
      On.get ("/size").json ("msg", msg -> msg.length ());
    }
  }
Also needed would be a sample pom.xml file. I had a problem with java compiler version being older and unable to complie lambdas.

My sample pom.xml (feel free to use it if you like) is:

  <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.microservices.app</groupId>
    <artifactId>rest-app</artifactId>
    <packaging>jar</packaging>
    <version>1.0-SNAPSHOT</version>
    <name>rest-app</name>
    <url>http://maven.apache.org</url>
    <properties>
      <java.version>1.8</java.version>
      <maven.compiler.source>1.8</maven.compiler.source>
      <maven.compiler.target>1.8</maven.compiler.target>
    </properties>
    <build>
      <plugins>
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-assembly-plugin</artifactId>
          <version>2.6</version>
          <configuration>
            <descriptorRefs>
              <descriptorRef>jar-with-dependencies</descriptorRef>
            </descriptorRefs>
          </configuration>
          <executions>
            <execution>
              <id>assemble-all</id>
              <phase>package</phase>
              <goals>
                <goal>single</goal>
              </goals>
            </execution>
          </executions>
        </plugin>
      </plugins>
    </build>
    <dependencies>
      <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>3.8.1</version>
        <scope>test</scope>
      </dependency>
      <dependency>
        <groupId>org.rapidoid</groupId>
        <artifactId>rapidoid-web</artifactId>
        <version>5.0.5</version>
      </dependency>
    </dependencies>
  </project>
Then I can run the test service using:

  java -cp target/rest-app-1.0-SNAPSHOT-jar-with-dependencies.jar App
Many thanks for this detailed feedback and example.

I totally agree a tutorial like this is needed, and I am going to add such documentation soon...

An excellent piece. The only problem is that it is now 2015, and everybody's moving to Websocket-based backends. Without WS support, new web frameworks are quite doomed.
Web sockets isn't the be all and end all tech. There's still a place for server rendered, simple pages. Not every web app needs to be a single page app.
That's not what they said. Not every web app needs to be a single page app, that's true but it's a non sequitur.

The point was that if a new framework aims to capture enough attention and traction to be a sustainable alternative to the incumbents it has to support websocket .

Where are websockets truly needed for functionality of any application?

The only part I think where websockets enable truly new functionality is displaying of live data and push notifications.

Should you use WS even if you don't need to push data to the client in real-time?
I don't see any negative aspects of exposing the same REST API through WebSockets internally. Public API (if exists) doesn't need to change, private API loses the redundant transfer of headers and cookies.
For webapps, certainly. You'd get much responsive UI, as there is much less overhead in responding to events, which improves end-user experience. Public APIs should stay REST, perhaps.
>everybody's moving to Websocket-based backends

You'd really be surprised. Not everybody moves or even has a use case for a websocket-based backend.

Sometimes it makes sense to ship in 2015 and add shiny features in 2016.
Yes, of course.