Although not yet at 1.0, JVM web applications toolkit Ratpack is steadily nibbling its way into the lexicon of many a Java developer. Originally intended to be a port to Groovy of the popular Ruby framework Sinatra, the project has slowly morphed into an all-guns blazing Java 8 web framework, although it has retained optional support for Groovy. Along the way, it’s found a natural fit in the unfolding microservices story, as well as in the movement towards continuous delivery. In this interview, project developer Luke Daley takes us through the Ratpack story and explains why it’s needed in the industry. We also address the comparisons to other existing frameworks, and what’s on the roadmap ahead.
Voxxed: What are the main problems you’re trying to solve with Ratpack?
Daley: We are trying to be a compelling choice for modern HTTP apps on the JVM. That’s quite a bland and generic statement, but we do have particular aspects in mind when we say “modern”.
The primary aspect is efficiency, which leads to performance. In the cloud era, where we pay for only what use, web apps need to perform well without generous resource allocations. Moreover, any increase in resource allocation should be predictably utilised. This is why Ratpack uses non blocking IO (like Node.js) and is built on Netty. This is fundamentally a better model if you are conscious of resource usage.
However, non blocking doesn’t come for free. There’s no question that the non blocking model presents challenges that aren’t present in synchronous programming. One of Ratpack’s goals is to make non blocking more approachable and safe, reducing the cost of this approach and therefore making its benefits available to a greater range of projects. We do this by building our API to be non blocking from the ground up, as opposed to being a tacked on afterthought, and by providing asynchronous constructs that integrate with our “execution model”, providing simple APIs and determinism.
We aren’t specifically hitching ourselves to the microservice bandwagon, but Ratpack is a natural fit for that style of application. Beyond its non blocking constructs, Ratpack is rather un-opinionated about how to structure an application or about what tools to use. Furthermore, integrating a new library to perform a particular function a certain way is extremely frictionless. A key goal is to allow applications to evolve with the times as new libraries and tools become available, and also as their complexity grows. We do this by largely staying out of the developer’s way. This means a little less hand holding by the framework initially but it pays off when things get serious, which is what matters.
Lastly, we are very “continuous” friendly. You can use whatever build tool you like (we recommend Gradle) with no fuss. Startup time is negligible. We deploy as a standalone process with a light filesystem weight. Testing is fast, comprehensive and easy. There are no pervasive heavy abstractions to fight as you need to evolve your app over time.
What was your motivation for developing it?
In 2012, when the project was started, so called “micro frameworks” were hot. The original Sinatra framework for Ruby was the poster child of this trend. After working on Rails style MVC apps for a while (I’m a JVM guy, so it was Grails), I could immediately see the appeal. Peeling back the abstraction layers and trading off “out of the box productivity” for more control seemed a fundamentally better idea for the next generation of front end heavy HTTP applications.
I wanted to create something that had the appeal of a micro framework but was industrial strength, without being “Enterprise”. That means excellent performance, testing as a first class citizen, no heavy abstractions and a deep experience of freedom.
Why did you choose to avoid a heavily opinionated approach?
In the continuous age, evolvability is king. My experience with heavily opinionated tools was that the projects I was working on always outgrew the opinions. While a tool that uses strong opinions to take care of things for you really helps get something going quickly, when you hit the tipping point where you’re trying to fit your problems into someone else’s opinions you’re in trouble.
There’s a school of thought that says that having to force your problems into pre-canned solutions encourages consistency and saves developers from themselves. Ratpack is for developers who can come to their own designs and opinions.
Who do you think would benefit from plugging it in?
I think we are well suited for smaller, high performing teams building efficient HTTP services in modern Java.
What’s on the roadmap ahead for Ratpack? Is it production ready? If not, when do you expect it will be?
We are aiming to release the first 1.0 release candidate on the 1st of September. There have been Ratpack applications in production doing well for many months now. The 1.0 label is all about the guarantee of API stability, which really comes down to being able to upgrade and benefit from fixes and internal improvements without any rework.
There’s also an O’Reilly book on the way, Learning Ratpack, written by Dan Woods – a core contributor to the project. This will be great resource for people getting started with Ratpack. Our documentation right now is very comprehensive in some areas and sorely lacking in others. After the 1.0 release this will be a strong focus and things will improve quickly, but the book will still be a great resource for anyone wanting a guided tour through what Ratpack has to offer and practical implementation guidance.
Is it open source?
Yes. It’s all up on GitHub at https://github.com/ratpack/ratpack with an Apache 2 license. There’s no commercial licensing or direct financial cost for any kind of usage.
How does it compare to Node.js?
It uses a similar non blocking IO approach, but that’s about where it ends. In that space, I’d say that a comparison with something like Express is more appropriate.
They key difference is the JVM ecosystem, and the stronger typing of the Java language. This means you can use all of the JVM based tooling that matters in production and for real integration, and write, build and test your code with great tools like IntelliJ IDEA and Gradle.
What makes Ratpack different? Does it offer any unique features/ benefits?
It’s the easiest way to implement non blocking, non trivial, HTTP apps in Java. We believe the combination of great performance with just enough support for building your app how you want to build it sets us apart.
Will you be extending support to any other JVM languages, for example Scala?
We already provide first class support for Groovy as an add-on, using the latest strong typing and static compilation features of language. Many of our users implement their apps in Groovy and it’s a great fit. You can seamless mix and match Java and Groovy, which fits the Ratpack ethos well.
Some of our motivated users have posted example apps written in Kotlin, Clojure and even JavaScript (via Nashorn), but we aren’t planning any kind of official support for another language any time soon.
Java still has the best tooling support out of all the languages of the JVM. This, coupled with the new features of Java 8 make it our primary focus.
Why did you choose to take a reactive approach to some of the development?
We are reactive in the Reactive Extensions (a.k.a. Rx) and Reactive Streams sense. In practice, this means that we embrace asynchronous data flow. Non blocking IO demands asynchronous data flow so it’s a natural fit for us. We provide an add-on integration for RxJava and use the Reactive Streams API standard as our native API for dealing with async data streams.
The term “reactive” at a system level means more than this. We aren’t an out of the box solution for a “reactive system” as defined by the Reactive Manifesto. However, Ratpack makes a lot of sense as a part of such a system.
The post Ratpack: A Java 8 Web Framework for Independent Thinkers appeared first on Voxxed.